AlpineQuest & OfflineMaps

Hi,

I am importing a gpx file from a track recorded with another GPS application --- MotionX - GPS

(first lines of the gpx file)

<gpx xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd" creator="MotionXGPSFull 21.1 Build 4789R">
<trk>
<name>PR3 FF set2013</name>
<desc>14/09/2013 12:30 pm</desc>
<trkseg>
<trkpt lat="40.2092356" lon="-8.8930495">
<ele>25.857</ele>
<time>2013-09-14T11:30:27.347Z</time>
</trkpt>
<trkpt lat="40.2092451" lon="-8.8930459">
<ele>26.778</ele>
<time>2013-09-14T11:30:28.242Z</time>


AlpineQuest doesn't read time information and elevation values reported are "wrong" (compared to real ones).

I have been searching on the gpx 1.1 syntax and standards adopted for time and elevation but I couldn't find answers to:

1) the number of decimal places on time field? It seems that AlpineQuest hopes to find always 2.

2) the elevation field value is? -> a) elevation above the ellipsoid “WGS84” earth shape
or b) elevation corrected for geoid shape.

It seems that AlpineQuest assumes that elevation field values on the gpx imported files are the ones above ellipsoid.

Thanks in advance
Rac

Hi and thanks for your report.
I have checked your gpx file extract in AlpineQuest.
You're right that the time field is not read, due to the fraction of seconds part. Even if counting milliseconds is not really useful (and consume space), it should be read as it is in your file. I'll make a fix so it's handled correctly.

Concerning the elevation part, the GPX format is quite clear about that, it's said that:

GPX uses the following conventions: all coordinates are relative to the WGS84 datum. All measurements are in metric units.

(see at the beginning of the definition here)
It also has an extra field "<geoidheight>" dedicated to store the difference between the WGS84 ellipsoid and the geoid shape, which can be exported by AlpineQuest based on your request.
So that's why AlpineQuest convert all elevations read from GPX files to a geoid height, and unfortunately there is no way to detect if the stored elevations are already a geoid based ones.
Note that some online tools like http://www.visugpx.com/ can automatically correct elevations (based on SRTM elevations).
Best regards

Hi,

Thanks for your quick and detailed explanation.

I will appreciate the fix.

Best regards
Rac