AlpineQuest & OfflineMaps

Just curious about how elevation is calculated. As I understand it, the data obtained from the satellite signal contains an elevation value in meters, referenced to an imaginary ellipsoid known as GRS80 ellipsoid? On Alpinequest, the elevation is shown as Geoid - in the UK a close approximation to Mean Sea Level. (+0.8m)
How does Alpinequest arrive at the Geoid figure from the raw satellite GRS80 figure? I can look up an SRTM3 elevation for a latitude/longitude from an Alpinequest gpx file, but this value is not the same as displayed on the Alpinequest screen. Shouldn't the SRTM3 value be the same as the Geoid?

Example - 53.3627276,-1.8753069
Elevation in Gpx file - 629 m
Elevation SRTM3 - 568 m (http://www.gpsvisualizer.com/elevation)
Elevation shown on Alpinequest screen as the Geoid value - 579 m

Here we have an 11 m difference, but sometimes the difference is even more - 50 m in one case.

How does Alpinequest model the Geoid? I assume the link above inputs the lat/longitude to a large SRTM3 database and returns the figure. How does Alpinequest manage this?

This isn't a complaint, by the way; I'm just trying to get my head round the bewildering complexities of altitude calculation. Apologies if I've misunderstood some basic concepts.

Hi and thanks for your interest in our application.

You're completely right to ask, I think it's very important to clearly understand all the concepts used in your tools and to know what's going on, instead on blindly relying on the given results...

So concerning your questions, here is how it works in the app and few minor precisions:
- The GPS gives the elevation in a model called "WGS84", using the WGS84 ellipsoid. In practice it's very close to GRS80 ellipsoid (and usually no conversion is done between both). Note that in this UK, the difference between the Geoid elevation and the GPS (WGS84) elevation is actually very high (~50 meters in London);
- AlpineQuest uses a model called "EGM96" to compute the Geoid height from the GPS elevation. In practice, the app includes a grid of elevation shifts to apply based on the location (the exact value for a given location is interpolated);
- In theory, you should get a value very close to what gives the SRTM data, in practice you have small errors at all levels (the GPS vertical error, the EGM96 interpolation, and the SRTM interpolation), so your 10 meters difference is good (but 50 is not so...).

The main advantage of the EGM96 model is that it can be embedded and used offline from the GPS elevation, whereas the SRTM require huge amounts of data to be stored (planned for a future version), or requires a server call via a cell data access. Here is a small comparison:
- Lat/Lon/GPS elevation + EGM96 -> Geoid elevation;
- Lat/Lon + SRTM -> Geoid elevation.

In AlpineQuest, you can click on any location with an elevation, select "Details", and you can get the used EGM96 shift used at that point (see the "(incl. X)").

Here is more info: http://www.alpinequest.net/en/help/1.4/ ... management.

Don't hesitate if something is not clear
Best regards

Thanks that's great. I have it now; that all makes perfect sense.
I've just looked again, and I'm in wrong regarding the 50m error, I was looking at the wrong point in the track! In fact the error was absolutely spot on compared to the trig point. The SRTM3 data for that point is wrong by about twenty meters - its a sharp hill summit, and presumably the 90m grid averages lower.
Thanks for the EGM96 shift tip - that's interesting.
If the location tracker graph could somehow be made zoomable I think that could be useful.

This all stemmed from me acquiring a Suunto altimeter watch, and in trying to understand how to use it I found many gaps in my knowledge. (The Suunto was out by about 14 meters at that point - various reasons for that). I also sometimes use a Garmin Forerunner which displays elevation, but this looks to be WGS84 ellipsoid elevation. Its interesting to see that things which I previously thought of as 'errors' are actually often due to different measurement metrics. Many thanks.

Thanks for the feedback.
Concerning your 50m error, that's a typical case showing the limit of the SRTM data... You need to interpolate the elevation between known points, and cannot detect the case of summits between them...
I'm now working on a major user-interface update, the graphics should be updated and improved just after... But don't hesitate to export your tracks in GPX/KML to display them in Google Earth or any compatible PC software.
Best regards