Re: [gpsd-dev] ✘wgs84_separation()

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

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

I was referring to my talking about NAVD88, which is US/CA only.

(And really, WGS84 is the US standard for a worldwide datum, not a
worldwide standard.)

>>   MSL is a term no longer used.
>
> Really?  I suggest you re-read the NMEA and u-blox ZED doec.s

Well, that's not important to resolve.  Basically the geopotential of
the averages of various tide gages is not the same.  When people say
MSL, they actually mean the agreed-upon zero surface of the geoid.  The
long-term average of sea level in various places is not at the same
altitude.

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

NAD83 does not have orthometric heights, but yes, converted to NAVD88,
the corresponding vertical datum.

As far as I can tell state GIS and engineering departments almost
entirely work in NAD83 and NAVD88.

> 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), "

Well, I guess they do.  I find it surprising given what I've read from NGS.

> How about gpsd calls is "altHAE" ?

I like that a lot.  HAE is really clear, and it's short.  While I'm not
a fan of alt, coupled with HAE there is no confusion.

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

I don't see them explain their height datum.  Perhaps they are showing
maps to the public in WGS84 because that's how web mapping is done.  But
I would be really surprised if their internal GIS databases were in
other than NAD83 and NAVD88.  MassGIS works in those datums.

> And the FAA still uses MSL.
>
> https://en.wikipedia.org/wiki/Lowest_safe_altitude

That's about pressure altimiters.  My understanding is that
aviation-related surveying data is in NAD83/NAVD88.  NAVD88 can loosely
be called height above MSL, and really it's altitude above the long-term
average of a particular tide gage (Father's Point, Rimouski, Quebec) at
the time the datum was defined.  And then carried forward relative to
physical marks, some of which have vertical velocities...

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

For those people, then, they should basically only be given height above
the geoid, what you call altMSL.

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

It's not that I'm wrong, it's that the term has no real definition.

Yes, altHAE is clear to people who understand.

> Which is why gpsd needs to give them all three:
>       altHAE
>       altMSL
>       geoidSep
>
> Until recently gpsd gave them only "altitude" which was just random.

That seems like a reasonable compromise between proper usage and being
usable by normals.

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

Almost every single modern careful map from the US (civil) government or
a state government has elevations in NAVD88.

It would be interesting to see a (non-military) government-published map
that has WGS84 "height above geoid" specified and really does mean
that.

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

The shift in the first revision was big. That's why I said "are now".
The pre-1994 WGS84 definition is now irrelevant to gpsd, as we are not
processing people's legacy data. And any GPS data from before the end of
SA is low accuracy anyway

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

What I meant is that when doing PPP, you get raw data from the receiver,
and then you get precise orbits and clock information, and then you run
a program (or use a web service to do this).

Are you saying there are receivers that have on-board PPP where you are
getting this orbit data from someplace and squirting it in?  And then
get the PPP solution out?

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

OK - hopefully the decent receivers are ok, and the messy ones, well,
they will be messy.

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

You are free to be gratuitously hostile :-)

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

do what?  Are you saying that people can do

  set their GPSr to NAD83, and use gpsd, and get NAD83 coordinates out?

  leave the GPSr in native WGS84, and tell gpsd to transform to NAD83
  (and heights to NAVD88)?

I realize the first might more or less work but it's tricky business.
If that gets the user NAD83, is their datum labeling carried through, or
is the user just given numbers that are said to be WGS84 but are
actually NAD83?

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

I don't want to throw them away and never said that.  I merely was
asking that they be labeled as ellipsoidal height vs heig above geoid,
which you don't disgree with.

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

NAVD88 and WGS84 orthometric heights are close.  I'm not sure exactly
but would guess within 2m, ish.

GPS vertical errors for nav solutions on single-frequency receivers, is
much more than 2m.  Even with WAAS, 2m seems really optimistic.

But yes, with dual-frequency receivers and real-time corrections from a
close base, or things like that, 2m starts to matter.

What kind of rms errors are you seeing in reported altitude from a
stationary receiver over days?