Re: [gpsd-dev] ✘wgs84_separation()

[Greg Troxel]

"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.

(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.)

>> 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".

  MSL is a term no longer used.  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.

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

  height above WGS84 geoid

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

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

>> 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.

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.

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


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.

>> 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.

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

>> 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.

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.

> 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.

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)

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.

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.

>> WGS84 specifies a geoid model.
>
> Not to be confused with the WHGS84 ellipsoid.

indeed

>> 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.

> 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.

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.

>> 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.

True.

>> 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

>> 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.

>> 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.

[trimming stuff there is no need to comment on]

>> 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.

interesting, I'll take a look.   This does not make sense to me.

>> 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.

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

>> 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.

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.


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.

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

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