Elevation ambiguity

[gdt]

This is sort of a bug report, sort of a feature request; the entire situation is messy.

I observed a displayed elevation that looked like orthometric height. (I'm in an area with geoid separation roughly -30m, so I can tell.) It was labeled as elevation, so that's more or less expected. However:

• First, note that receivers actually compute HAE, and then apply a geoid model to get orthometric height. NMEA shows orthometric height and geoid separation.
• receivers have bad geoid models. Even the F9P seems like 15 degree EGM96. Recent WGS84 realizations specify EGM2008 and implicitly the 1 degree model (at least, and I have been hearing about a newer EGM coming soon). I have observed roughly 4m difference between the receiver's model and the full EGM2008 model.
• If one's receiver is not in WGS84, because of RTK with a national datum, then taking e.g NAD83 HAE and adding an offset which is "WGS84 orthometric height - WGS84 HAE" is nonsensical. One would want to use an NGS-published hybrid geoid model to transform from NAD83 HAE to NAVD88, probably. The details differ by country but the concepts are similar.
• It's unclear to me if ITRF has any concept of orthometric height. So GPS when operating with SBAS is on theoretically shaky ground, except that recent WGS84 == recent ITRF, so it's ok.

When collecting data, I record HAE, and expect to later process this (with proj and grids, perhaps via gdal or qgis) to get NAVD88. Or to transform back to ITRF and use EGM2008 if I want WGS84 orthometric height.

• It's an interesting question how the other 3 constellations handle the concept of orthometric height.
• It's an interesting question how a receiver is combining data in 4 different frames when computing multi-contellation solutions.

So, I'd like PyGPSClient to display HAE in addition to "elevation".

There's a further complexity of knowing what datum the receiver is operating in, and suppressing elevation as conceptually invalid if not WGS84/ITRF.

Probably PyGPSClient does not wish to cross the line into linking proj and dealing with all of this.

[semuadmin]

@gdt

We're getting into slightly esoteric territory here with vertical datums but, in simple terms, we have:

1. ellipsoid height (HAE)
2. geoid height, which generally coincides with Mean Sea Level MSL (local vertical datum-related anomalies notwithstanding!)
3. orthometric height, which for most practical purposes is referred to as Height Above Mean Sea Level HMSL, or more colloquially 'altitude' or 'elevation'

As you say, the NMEA GGA or GNS sentence provides the following 'height' attributes:

• alt - representing HMSL
• sep - representing the difference between ellipsoid and geoid height

The UBX NAV-PVT message, on the other hand, provides:

• hMSL - representing HMSL
• height - representing height above ellipsoid HAE

So, using the attribute names above:

• alt + sep = height
• height - hMSL = sep

If you concur with this treatment, I can happily add HAE to PyGPSClient's top banner, alongside 'alt' aka 'hMSL'. I can endeavour to get this into RC 1.4.27 this month.

[gdt]

Yes, I broadly concur. It might be nice to also show "N" being geoid separation, or geoidsep if using the standard abbreviation would be confusing, as I suspect it would be to many. That would make it easier to look up the right value of geoidsep and compare (well, to compare).

I'm ok with "alt" being HMSL, although there isn't really such a thing as MSL and instead we mean relative to some defined equipotential value (U_0 or W_0, variously, generally with the same value), when using modern vertical datums (such as "WGS84 Orthometric Height").

Thanks for listening and adding HAE!

[semuadmin]

Yes, I broadly concur. It might be nice to also show "N" being geoid separation, or geoidsep if using the standard abbreviation would be confusing, as I suspect it would be to many. That would make it easier to look up the right value of geoidsep and compare (well, to compare).

I think most people can handle HAE - hMSL = N themselves, provided they understand the definitions 😄

I'm ok with "alt" being HMSL, although there isn't really such a thing as MSL and instead we mean relative to some defined equipotential value (U_0 or W_0, variously, generally with the same value), when using modern vertical datums (such as "WGS84 Orthometric Height").

Clearly MSL is an abstract concept, but in the interests of general sanity I think we can live with hMSL.

[gdt]

Sure, hMSL as a label for "the receiver says this is orthometric height" is fine. Understood about N. While I'd like to see it, I get it that some find it clutter, and of course your call.

I just meant that while "global MSL" is theoretically valid, it is not accessible (but rather estimates of it are a valid subject for research papers), and "average of tide gauge readings at station X" is not going to be the same value as the average at station Y, due to (or defined as) "sea surface topography". Modern definitions of height avoid it, even though it is how 1-1E-6 of the people understand it. In fact, the US "Sea Level Datum of 1929" was renamed "National Geodetic Vertical Datum of 1929" many many years ago.

[gdt]

I like 'hmsl' instead of alt. While I realize it's a fair argument that altitude is an orthometric height, I also feel that altitude is often used in contexts without an understanding of what it really means, and seeing 'msl' and guessing h means height, makes it unambiguous.
Separately from this feature request, i encourage you to look up your N using https://geographiclib.sourceforge.io/cgi-bin/GeoidEval and compare it to the -48.5m your receiver has output.

[semuadmin]

[gdt]

So 3.09m off from EGM2008. If you are using non-RTK, then that may be in the noise. With RTK, it's egregious.

[semuadmin]

I'm in a cafe under an office block with a $10 NEO-M8N, so I'm not gonna sweat it 😉

[semuadmin]

Delivered in version 1.4.27 now available on PyPi