Re: [gpsd-dev] ✘wgs84_separation()

[Gary E. Miller]

Yo Greg!

On Wed, 17 Jul 2019 19:04:44 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> > I have been looking at the Altitude calculations in gpsd and
> > they have been sort of random.  I've tried to get all the altitudes
> > to be WGS84 altitudes.  
> 
> (Note that I'm stepping back from being totally pedantic.)

Don't step back too far!

> The words involved in height can be confusing.  I listened to hours of
> NGS webinars....  "Altitude" generally refers to an orthometric
> height, meaning distance from the geoid.

"orthometric beight", or height above the geoid, or Mean Sea Level (MSL).

> I think the word should be "ellipsoidal height".

"ellipsoidal height" is WGS84 altitude or WGS84 height.

>  That's the raw
> measurement GPS makes (well, XYZ and \delta t, but it's straight math
> from that to lat/lon/ellipsoidal_height, with no gravity models).

Yes. ECEF X, Y and Z.  The height computed over the WGS84 ellipsoid.

> People get confused between ellipsoidal and orthometric heights a lot,

Yes, and the gpsd code was also confused.  Randomly mixing the two.
Looking at the older GPS doc, the type of height/altitude is not even
specified by some GPS.

> so I think it's important to avoid using the word altitude to refer to
> an ellipsoidal height.  That at least is what NGS practice seems to
> be.

Except people expect to find "altitude" and when the do not see it they
get angry.

Would you conside changing gpsd to altWGS84 and altMSL?  Or?

> WGS84 specifies a geoid model.

Not to be confused with the WHGS84 ellipsoid.

> I am pretty sure it's now EGM2008 (but
> there are quite a number of WGS84 revisions).

Yes, different versions of WGS84 specify different geoids.  EGM84, EGM96
and EGM2008.  I used to think WGS84 was a constant...

I too believe EGM2008 is current.

Except in the high precision (PPP) GIS world.  They are using ITFR2014!

http://itrf.ensg.ign.fr/trans_para.php

I'm not ready to go there...

> This is used as you say
> to convert an ellipsoidal height to geoidal height, that people expect
> from "altitude", where water always flows toward decreasing altitude.

Agreed.

> This article says the current model is EGM2008.  Interesting (and
> sensible) comment about using EGM96 to convert back if you are given
> an altitude from a GPSr that used EGM96.

Good luck finding a GPS that documents their EGM version.

> But most NMEA speakers seem
> to output the geoid height and that seems best to use.

My testing shows them not to match anything I expect.  The NMEA is
knida sorta MSL, and maybe some sort of geoid separation.

> I would
> expect ublox to output all of ellipsoidal heigth, geoid height, and
> modeled geoid separation.)

But since we have many GPS samples older than 2008 they can't possibly
match today's understanding of MSL.

> https://gis.stackexchange.com/questions/214786/how-does-a-spatial-reference-system-change-the-underlying-geoid-without-having-t

Obsolete when it was written two years ago.  It says EGM96 is current.

> EGM2008 is described and available (fortran!) at
>   https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html
>   https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/

I've been looking at that.  The 1 degree interpolations are maybe more than
we need.  Maybe not.  I'm still hoping to not have to translate FORTRAN.

> As I understand it those coefficients and formulas are the definition
> of the transformation from WGS84 ellipsoidal heights to altitudes.

Agreed.

> > Comparing those results to those from here:
> > https://geographiclib.sourceforge.io/cgi-bin/GeoidEval  
> 
> I have been following the proj list and it's quite clear that the
> geographiclib author is knowledgable, careful, and compulsive about
> accuracy.

Good to know.  That was also my understanding.

> > It appears that wbs84_separation() can be up to 15 meters off!
> >
> > Looks like we been a new geoid calculator.  
> 
> Indeed.  My impression is that any differences between EGM96 and
> EGM2008 are maybe 20 cm.  Nowhere near 15m.

I ran EGM84, EGM96 and EGM2008 for all the tests in test_gpsclient.py.
The new data is in the comments.  They varied by up to 9m!

I can't say if that is real, or an artifact if the GeoidEval code.

> Not that you suggested going there, but (for the US/Canada) there are
> another set of geoid models that convert between NAD83 ellipsoidal
> heights and NAVD88 orthometric heights, which are not equal to WGS84
> ellipsoidal heights or WGS84 geoid heights.

Eventually NAD83 that would be nice, but that would be even more work.

> This is strictly about
> the US National Spatial Reference System and conceptually distinct
> from WGS84.  I'd say surveyors and geodesists care and gpsd users do
> not.

In the Western USA a lot of maps are still NAD83.  So a lot of people
do care.  The advantage to NAD83 is it does not change as much as
WGS84 as the tectonic plates move.

> I know you know this, but for others:
> It seems often GPS receivers have a geoid model and report altitude,
> and some report ellipsoidal height, and some report geoid heights.  So
> presumably gpsd already can cope with getting some subset and
> calculating the rest.

Like gpsd does with all the data it gets from a GPS: grab the data, try
to calculate the rest.

> This page seems really useful, but it's not about heights
> 
> https://confluence.qps.nl/qinsy/latest/en/world-geodetic-system-1984-wgs84-29855173.html

Nice, five different WGS84 versions!  Then the even nerdier ITRF ones.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

pgp9c3_EWzP0M.pgp
Description: OpenPGP digital signature