[Android/GPS driver] Orthometric heights (H) being reported as geoid EGM2008 appear skewed

[vkbellis]

Describe the bug Orthometric heights (H) being reported as geoid EGM2008 appear to actually be ellipsoid heights (h).

To Reproduce Examine the displayed height on Stats_screen under the heading 'ELEVATION', or any of the vertex elevations in the exported GPX or KML files, and then compare with actual surveyed values.

Technical information

• Device: Samsung Galaxy SM-A716U
• OS: Android 11
• Platform 30

The field test was conducted holding my smartphone face up, approximately 1.1 meter above and parallel with the ground during the entirety of the 4.83 km walk. The exported line feature (GPX file) was then brought into Global Mapper in a new workspace, geographic projection, WGS84, and then individual vertices were extracted on their own layer. Next, a new layer with the copied point features was created during a performed calculation to adjust the GPX heights by 1.1 meters to more closely align with the Earth surface. This adjusted layer was exported in LAS format so as to enable Global Mapper to then be able to profile these points.

For context, a digital elevation model (DEM) predicated upon LiDAR flown 2010-2011 was translated from NAD83 into the WGS84(G1762) frame and orthometric heights (H) were translated from Geoid09 into EGM2008 using Geographic Calculator 2020 SP1.

The known benchmark (PID: BBBF03) was along the chosen path of my walk and when abreast of it, a screenshot of OpenTracks was captured while walking; I didn't stop walking for any of the screen captures.

The published orthometric (H) and ellipsoid (h) heights for BBBF03 were transformed into EGM2008 ortho height (H) and WGS84(G1762) ellipsoid height (h) for comparison with its nearest vertex from the adjusted GPX point feature height, i.e., vertex number 399. Its value is within reasonable range of being consistent with the WGS84(G1762) ellipsoid height (h).

[dennisguse]

Let me rephrase this:

1. You took a hike and walkted by BBBF03
2. You took a screenshot showing EGM2008 with -16m
3. You exported the full track as GPX and figured out that vertex 399 is the closest trackpoint to BBBF03
4. for BBBF03: the WGS84 ellipsoid height is -22.665m
5. for BBBF03: the EGM2008 ortho height is 2.645m

And you expected OpenTracks to show 2.645m + 1.1m (height of the device above ground) while recording.

Is this correct? PS: I am an absolute newbie in this domain :)

[vkbellis]

@dennisguse - Yes. Spot on.

Kind regards,

Kelly

[dennisguse]

Next (bad) question: any suggestions?

My thoughts:

1. Phone is broken (that's the "some else's fault" excuse)
2. GPS returned invalid height values? Might have been inaccurate - usually only a problem in dense areas + fast moving (aka cycling). Could you just wait for some time and see what happens at this location?
3. EGM2008 adjustment is broken Good thing: I implemented it myself, so might be really broken :sunglasses:

And would it be helpful to also export the EGM2008 values (I could provide a custom version for you).

[dennisguse]

Next step for me: check a local GPS reference point. https://de.zxc.wiki/wiki/Liste_geod%C3%A4tischer_Referenzpunkte_in_Deutschland

[vkbellis]

@dennisguse - 1. No question is bad

2. No, the ellipsoid (h) values are consistently in a reasonable range of values (given smartphone's GNSS receiver and poor GNSS antenna).
3. Implementation of geoid model needs examination. Consider a small separate app for only testing geoid models. Nothing fancy, just bare bones, and focused on static observations over known (published) vertical benchmarks. EGM2008 is a good model to start with and the tiling schema that Sean mentioned could later be tested in such an application.
4. Yes, by all means, look for your closest vertical control monument with published coordinates and that is away from buildings, trees, etc., with an open view of the sky.

[vkbellis]

@dennisguse - After looking at your link for public geodetic reference points and then mapping the ones listed in the greater Berlin area, I see they're quite sparse.

Public Geodetic Reference Points.zip contains KML file for Google Earth, GIS, etc.

The Deutsche language is a barrier for me, but there has to be more survey marks than just these 4, ones that local surveyors use day to day. I'll keep looking, but I think you'll have some luck finding geodetic vertical and horizontal control monuments closer to where you live, maybe with help from: https://www.geoportal.de/ https://www.gdi-de.org/ https://www.bkg.bund.de/

Maybe you know folks at the university that can give you some help? https://www.gfz-potsdam.de/en/geodesy/

[dennisguse]

@vkbellis I am planning to check the one close to Berlin main station. And Berlin is kind of flat, so I guess there is not that much need to for GPS reference points ;)

By the way: I have a Etrex 30. Do you know, if there is something I need to know about the reported altitude? So far, I did not care too much :)

[vkbellis]

@dennisguse I thought that you would be using your Android smartphone, not your Garmin.

Regarding your currently chosen control point for tests and the information pamphlet that I downloaded from your provided link: https://de.zxc.wiki/wiki/Liste_geod%C3%A4tischer_Referenzpunkte_in_Deutschland

(I'm using Google to help translate) Reference point Berlin-Mitte Ludwig-Erhard Shore, Spreebogenpark, Near main station

Coordinates and height: Reference system ETRS89 / WGS84 Geographical: 13 ° 22,6013 'L 52 ° 31,3551 'B UTM: 33U 389525.8 E 5820410.0 N

height ELIPSOIDIC: 79.8 m Normal height (NHN): 40.5 m above sea level.

You should already have chosen ahead of time which Android apps you want to use for logging your static position. At a minimum, the app should allow logging NMEA sentences. If you have multiple Android devices to test, cloud storage might make things easier if you care to share your logs in this manner; otherwise, post the results here.

This article I wrote will help understanding those NMEA sentences of interest: What's Up with Android's Heights.pdf

As for which apps to use; there's so many! If I had to choose only one, I think GPSTest would be it, but also I think it's better using multiple/ different apps rather than just one app when studying data.

For your test, place your smartphone directly on the metal plate and step away so as to not block any GNSS signals. Collect data for a couple of minutes and grab a screenshot of the app's displayed location before closing the log. It would be helpful to also grab screenshots from your phone's About phone and About software to compare with the headers in the logs as this information will help in identifying details related to the GNSS chipset.

The ellipsoid height (h) published for this mark (79.8 m) should be reasonably close to your smartphone's display, often referred to as 'Alt' or Altitude.

If the app supports it, the orthometric height (H) may also be shown and may be referred to as 'Alt MSL', NHN, or in OpenTrack's case, 'ELEVATION'. Here is where you may see something noticeably different from the published orthometric height (H) and what you see on your phone.

There are multiple things to consider beginning with the specific reference frame and specific geoid model upon which the metal plate sits, but for this first test, we'll save those questions for later because any differences will be small and unable to be measured using these types of devices. For example, the geoidal separation (N) value indicated by the published coordinates is 39.3 m (N = h - H) is within 0.2 to 0.5 m of an expected prediction; e.g., GeoidEval.

Horizontal concerns shouldn't be ignored, but here again, for the first geoid model tests, we'll save those questions for later because the impact will be small and unable to be measured using these types of devices.

The geoid model tests must first consider validation of the geoidal separation (N) information that is being reported by the device. The NMEA logs will help to make make such an evaluation. Based upon a very small dataset as of this date, I can say that the errant N values appear to vary for a single given location based on the specific Android device being tested.

Data from VKB's Surveyed Control Point: 17U Manufacturer: samsung, Model: SM-A716U, GNSS HW Year: 2019, Platform: 11, API Level: 30 $GNGGA,215300.00,4432.673982,N,06825.027815,W,1,12,0.6,66.7,M,-45.0,M,,*7B Reported N: -45 m EGM2008 Surveyed N: -24.95 m @ Epoch 2010.0 EGM2008 Predicted N: -25.31 m EGM96 Predicted N: -25.27 m EGM84 Predicted N: -24.28 m

Manufacturer: samsung, Model: SM-T970, GNSS HW Year: 2016, Platform: 10, API Level: 29 $GPGGA,174820.96,4432.667082,N,06825.033167,W,1,10,1.6,56.5,M,-29.1,M,,*6B Reported N: -29.1 m EGM2008 Surveyed N: -24.95 m @ Epoch 2010.0 EGM2008 Predicted N: -25.31 m EGM96 Predicted N: -25.27 m EGM84 Predicted N: -24.28 m

Manufacturer: motorola, Model: Moto E (4) Plus, GNSS HW Year: 2016, Platform: 7.1.1, API Level: 25 $GPGGA,181709.011,4432.6833,N,06825.0227,W,0,0,,36.3,M,-30.4,M,,*4A Reported N: -30.4 m EGM2008 Surveyed N: -24.95 m @ Epoch 2010.0 EGM2008 Predicted N: -25.31 m EGM96 Predicted N: -25.27 m EGM84 Predicted N: -24.28 m

Data from Sean Barbeau Samsung Galaxy S21+ (SM-G996U1) with Android 11 Build RP1A.200720.012.G996U1UES3AUE3 $GNGGA,181848,2804.275656,N,8225.599375,W,1,12,0.5,9.1,M,-24,M,,*4B Reported N: -24 m EGM2008 Predicted N: -26.76 m EGM96 Predicted N: -27.08 m EGM84 Predicted N: -26.28 m

Pixel 5 with Android 11 Build RQ3A.210605.005 $GNGNS,165422,2804.28021,N,8225.598206,W,AAANNN,20,0.6,18.1,-24,,,V*24 Reported N: -24 m EGM2008 Predicted N: -26.76 m EGM96 Predicted N: -27.08 m EGM84 Predicted N: -26.28 m

The other thing to think about is the resolution of the gridded geoid model's surface; e.g., spaced at every 1.66666666666666664E-002 degree of arc vs 5 minutes of arc. The resolution of the models used by the device irrespective of whether it's representative of EGM84, EGM96, EGM2008, EGM2020, GM2022, etc., will likely remain undisclosed by the GNSS chip manufacturer and the OEM.

All of this helps to underscore the need for app developers working on precise locations (decimeter level) to consider using an open modern geoid model broken into regions with practical resolutions. It also helps to illustrate that GNSS chipset manufacturers and OEMs are not to be relied upon for their reported orthometric heights (H) until otherwise demonstrated.

[dennisguse]

Today I went to:

Geographical: 13 ° 22,6013 'L
52 ° 31,3551 'B
UTM: 33U 389525.8 E
5820410.0 N

with four devices:

• etrex 30
• Nexus 7 2013 / LTE
• GT-I9505
• Pixel 1

with the following results using Openacks (v3.19.5 slightly modified):

• original GPS altitude ca. 75-85m
• EGM2008 corrected: ca 35-45m

Modifications to OpenTracks:

• altitude with one decimal point
• as the displayed altitude is only updated when a new location is stored: the minimum required distance was set to 0m to the previous location
• either original altitude or EGM2008 corrected altitude was shown

I had no time to dig deeper into the NMEA sentence.

PS: I was actually impressed by the Pixel1; while not moving there was almost no horizontal movement reported while the GT-I9505 did.

[vkbellis]

@dennisguse - Thank you for sharing.

Based on these observations, it appears my original idea was wrong; i.e., "Orthometric heights (H) being reported as geoid EGM2008 appear to actually be ellipsoid heights (h)", I'm therefore revising the title of this issue to: Orthometric heights (H) being reported as geoid EGM2008 appear skewed

To help in discussing, I've named your photos A and B. I see in Photo A where OpenTracks displays ellipsoidal height (h) WGS84 only on the Samsung and no other devices in either photos. All 3 Android devices display orthometric height (H) EGM2008:

• Pixel: 35.6 m; 4.9 m lower than published (H)
• Samsung: 48 m; 7.5 m lower than published (H)
• Nexus: 38 m; 1.5 m lower than published (H)

It's worth noting Samsung's ellipsoid height (h) WGS84 is only 1.8 m lower than it's published value.

What remains to be seen is an accounting of the skewed orthometric height (H) EGM2008 being reported originally in comment #1. For example, is it tied to the device's reported geoidal separation (N)? Really hard to say without NMEA sentences and further testing.

[dennisguse]

On the one hand, great that this is not an issue regarding the EGM2008 implementation. On the other hand, well that somehow sucks - as we cannot really account for this kind of

The upcoming version of OpenTracks will add the functionality to record all reported GPS locations (https://github.com/OpenTracksApp/OpenTracks/pull/865), so if one can remain stationary to give the GPS time to improve accuracy. Also, we need to implement this: https://github.com/OpenTracksApp/OpenTracks/issues/866 (at least show the most recent altitude even if the location is not stored).

1. iis it worth the effort to allow users to decide to use the original altitude (as reported by device / what we currently would label WGS84) and EGM2008/5deg? Is this helpful for testing? Yesterday, I just used my laptop to compile OpenTracks again on site; not really practical, but nerd style.

2. Should we show altitude with one decimal (we store it anyhow)? Or is this only useful for testing?

@vkbellis Thanks for bringing up this topic! Now at least I am actually sure that the correction is implemented correctly (and I learned how to verify it) :partying_face:

[vkbellis]

Adding a tool to record stationary (static) observations will be very helpful indeed! See my comments at: https://github.com/OpenTracksApp/OpenTracks/pull/865#issuecomment-874151185

1. It's worth the effort if there are users comparing OpenTracks display of orthometric heights (H) with published or known elevations at mountain summits, benchmarks, etc. Yes, it would be very helpful for testing OpenTracks as well as other apps purporting to correctly display orthometric heights (H)
2. I think that at present, displaying decimeter values is appropriate. I also think that recorded height values should be to the nearest centimeter for: geoidal separation (N), orthometric heights (H), and ellipsoid heights (h).

@dennisguse - Many thanks to you for listening and for your willingness to consider implementation of a reliable geoid model. I can't thank you enough! As for the correctness of the implementation, it will be evidenced when there is clearer data to study, void of any biases introduced by errant geoidal separation values baked in by the chip makers and/or OEMs.

Kind regards,

Kelly

[vkbellis]

I had originally planned on repeating this experiment on all 3 Android devices using Andrzej Bieniek's Mapit Spatial; however, as best as I could determine, his app doesn't record orthometric heights (H) for line features' (in the geopackage file), only ellipsoid heights (h). Mapit Spatial does offer several gravity models to choose from. I've reached out to him, but have not heard back from Andrzej yet.

[barbeau]

FYI, for anyone who wants to see a reliable first-class Android API to get the H and N values directly from the platform (vs parsing NMEA sentences or bundling your own geoid model), please star my feature request to Google here: https://issuetracker.google.com/issues/195660815

[dennisguse]

@vkbellis is this still an issue for you?

[vkbellis]

@dennisguse - Hi Den, thanks for asking. In answer to your question, I've no idea if this issue is still present. I stopped testing your app (v3.18.5) specifically, and other apps purported to display ortho heights, and cell phone geoid models 2021-07-06 or thereabouts.

[dennisguse]

@vkbellis Then I would just close this ticket as there seems to be no immediate problem :)

If we need to do some updates (i.e., upgrading to something else than EGM2008), please drop us a message!

[dennisguse]

@ValZapod You might be able to this. Just change the file and also update the hardcoded indices. Only problem: the APK size might be limited, but we copy the data into it.

But why should you do this? The 5x5 should be sufficient for almost all use cases. You can also apply the EGM2008 afterwards as OpenTracks actually exports WGS84.