Re: [gpsd-dev] ✘wgs84_separation()

[Gary E. Miller]

Yo Greg!

On Thu, 18 Jul 2019 09:23:23 -0400
Greg Troxel <address@hidden> wrote:

> "Gary E. Miller" <address@hidden> writes:
> 
> >> "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!  
> 
> Sort of a joke.

What?  No smiley?  :-)

> (Also, this post is US centric, because that's what I know best.  More
> or less, all other countries have similar vertical datums that serve
> the same purpose, with the exact same issues, and I won't keep saying
> that.)

NAD83 would be USA centric.  WGS*$ is the "World Geodetic System".

> >> 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).  
> 
> Right.  Except that:
> 
>   height above geoid is ambiguous about orthometric vs dynamic or
>   normal, and this is beyond almost everyone, so I'm fine with "height
>   above geoid".

I'm sure we could get really picky, but after re-reading all the docs
on the various GPS models, those that specify say "height above geoid".

>   MSL is a term no longer used.

Really?  I suggest you re-read the NMEA and u-blox ZED doec.s

>  The "Mean Sea Level Datum of 1929"
> was renamed the "National Geodetic Vertical Datm of 1929" for multiple
>   reasons including that mean sea level at various places is
> different. NGVD29 is no longer used.   The current US vertical datum
> is NAVD88, and that used one tide gage for the zero.

Now you really are getting US centric.  I'm referring to the
world standard EGM2008.  That is then converted to local datum, like
NAD83, as required.

Even the paper annoucing EGM2008 calls it MSL:

https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2011JB008916

"elevation‐related quantity, such as heights above and depths below
Mean Sea Level (MSL), "


> So I interpret "height above MSL" as a fuzzy statement and that when
> someone says that these days they probbably mean one of

Not fuzzy when the hard scientists define it.

>   height above WGS84 geoid

How about gpsd calls is "altHAE" ?

>   height in NAVD88 (or whatever the official national vertical datum
> is in the country they are in)

gps officiall discorages setting your GPS to anything but WGS84.  Maybe
that should be louder in the doc.

> and I think we  should entirely avoid MSL in code and docs to align
> with current geodetic pracice.

Except we can't as that is what NMEA, u-blox, etc. tell us that is
what they are giving u.

> >> I think the word should be "ellipsoidal height".  
> >
> > "ellipsoidal height" is WGS84 altitude or WGS84 height.  
> 
> not really altitude.  It's height above the eillipsoid, and is the
> right term.  WGS84 defines a geoid model and thus also provides geoid
> heights.

So, how about gpsd calls it "altHAE"?

> Aside from the tiny fraction of people that can follow this
> conversation, everyone treats "height" as something like orthometric
> height, height in their national vertical datum, height above sea
> level.

Uh, certainly not my city and county.  They converted to WGS84, as default,
many years ago.

https://www.bendoregon.gov/services/mapping-services/interactive-city-map

And the FAA still uses MSL.

https://en.wikipedia.org/wiki/Lowest_safe_altitude

> And everybody who really understand will immediately know from
> "ellipsoidal height" what it means.

Which is not the gpsd audience.  Our audience is people flying airplanes
and using city maps.

> If I were to see "WGS84 altitude", I would be suspicious, but judge it
> more likely that it meant height above the geoid, using the WGS84
> geoid model.

Which would be totally wrong.  So how about "altHAE"?

> >> 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.  
> 
> I assume you mean "older GPSr doc" and receivers.  The actual GPS ICD
> I suspect has always been clear.

red herring.  The GPS ICD says zero about datums:

https://navcen.uscg.gov/pdf/gps/IS_GPS_200K.pdf


> On Android, the system API specifies ellipsoidal height.   However,
> some phones return height above geoid.   osmand, satstat, gpstest
> have been dealing with this.

And since they depend, sometimes, on gpsd (see the new gpsd Android
port), we gotta be clear what we give them.

> >> 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.  
> 
> If what they have is ellipsoidal height, I think it's far better for
> them to be upset that they do not have altitude than for them to be
> misled.

Which is why gpsd needs to give them all three:
        altHAE
        altMSL
        geoidSep

Until recently gpsd gave them only "altitude" which was just random.

> My point is that from my viewpoint, more or less nobody who understand
> height would choose to use the word altitude to describe an
> ellipsoidal height.

Still not addressed my suggestion from last email.  How about:
        altHAE
        altMSL
        geoidSep


> > Would you conside changing gpsd to altWGS84 and altMSL?  Or?  
> 
> This prompted me to download the ICD from
>   https://www.gps.gov/technical/icwg/
> but it doesn't talk about height.

And yet, earlier in thei email you said it did...

> If you read the WGS84 specification (albeit an old one), linked from
> 
>   https://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html
> 
> on page 7-4 the terms are
> 
>   h = N + H
> 
>   h = geodetic height (height relative to the ellipsoid)
> 
>   N = geoid height
> 
>   H = orthometric height (height relative to the geoid)
> 
> Now, those are pedantic geodesy terms, and our goal is to pick words
> that
> 
>   people that understand geodesy will find 1) not confusing and 2) not
>   at all wrong
> 
>   people that don't understand will not get the wrong idea
> 
> I would call them
> 
>   ellipsoidal_height_WGS84 (or ellipseh_WGS84 if that's too long)
> 
>   altitude_WGS84
> 
>   geoid_height_WGS48 (or geoidh_WGS84 if too long)

Too long, too confusing.  It does not match what most maps and charts
use.  They use MSL or WGS altitude.

> People that don't understand will look at alitude which is what they
> want, and they will end up with a value that means what they think it
> means, even if they have no idea there is an ellipsoid.

So we give them two, and make them ponder a moment.

> Geodesy people will say "but altitude should be labeled orthometric
> height", but when they see those three will immeidately understand
> that the altitude term is an accomodation for normals.

And yet the EGM2008 authors used MSL.

> >> 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...  
> 
> Big discussion on proj list now.  WGS84 sort of refers to the set in
> aggregate.  But I think gpsd doesn't need to worry about this.  Also,
> the differences between successive revisions of WGS84 are now cm
> level.

cm in the latest revisions.  The first revisions were closer to meter
level.  I agree that gpsd need not rais that distinction since NONE
of the GPS documents which they use.

> > 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...  
> 
> Agreed we should not.  However, that is a computation from raw
> observables, and not something you get out of a receiver.

Uh, no.  To be accurate you need raw observables, but it is a
good and valid datum in its own right.

> Also, the difference between WGS84(g1762) and ITRF2008 is basically
> zero, and ITRF2008 to ITRF2014 are very close.  I think they are now
> changing by a few mm.

Which is beyond gpsd dynamic capability, for now.

> >> 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 am remembering the old garmin GPS II+, which I realize is ancient
> history.   I remember that the "altitude" that came out was plausibly 
> orthometric height and I remember a number around -29m for geoid
> height, which checks reasonably with geographiclib for boston

That process is what I have been doing for a few weeks.  Trying to figure
out what each altitude in gpsd means.  If you  look you will find more
confusion in gpsd, please report it if you find it so it can get tweaked.

> >> 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.  
> 
> Today's geoid model.  Today we understand there is no MSL.

Except the EGM2008 authors disagree with you.  I'll side with those
smart guys.

> 
> >> 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.  
> 
> That's the question.  The answer explains that it's EGM2008.

I still say useless.

> > 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.  
> 
> interesting, I'll take a look.   This does not make sense to me.

Look in test_lienthelprs.py.  There I documented my tests and results.

> >> 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.  
> 
> I think a very reasonable position is that gpsd does WGS84 period,
> matching the realization used by GPS, and that if you want something
> else you can run proj.

Then every pilot that uses gpsd directly, or indirectly hates us.  Not
gonna do it.

> Plus in 20022 the US (and jointly with Canada I think) are getting new
> horizonal and vertical datums.

Which will differ by much less than a consumer GPS can measure.  The
20 m MSL differences you want to throw away mean life or death to a pilot.

> > 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.  
> 
> Sure, for horizontal it matters, at the 2m level.  I meant that for
> people using gpsd witha navigation solution, the vertical accuracy you
> get is much worse than the difference between NAVD88 and WGS84
> orthometric heights.

Only worse because gpsd calculates it wrong.  Not beccause a GPS
can not measure it well.

> So I think if there are the three fields above, and they are taken
> from the GPSr if reported and calculated otherwise, things will be
> good.

So, how about:
        altHAE
        altMSL
        geoidSep

> For display to users for actual use, I think they basically want
> orthometric height.  For test clients, both is a good plan, clearly
> labeled.

Maybe what they want, but when they look at their maps and charts that
term is not there.  orthometic height is for the doc, not the display.

> Also, once theere is both "ellipsoidal height" and "altitude"
> displayed, it's obvious to those who get it.

It needs to be obvious to those that do NOT get it.

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

pgpxB6k_3IF9w.pgp
Description: OpenPGP digital signature