Re: [gpsd-dev] ✘wgs84_separation()

[Gary E. Miller]

Yo Greg!

On Thu, 18 Jul 2019 16:04:56 -0400
Greg Troxel <address@hidden> wrote:

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

Still a non-sequiter.

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

Led by the USA, but in concert with others.  NATO uses it, QZZSS uses
it.  Centered on the IERS Reference Meridian (so not North American
plate referenced).  So not just a USA 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.

Yes, originally, but that is what EGM2008 is trying to resolve.

> The long-term average of sea level in various places is not at the
> same altitude.

Which is why that has not been the basis for MSL for a LONG time.
The SI people define "sea level" as where gravity equals 9.80665 m/s2

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

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

Why do you keep bringin up NAD83?  NAD83 has no place in gpsd.

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

Ditto Oregon.  But unless you propose adding NAD83 or NAVD88 to gpsd
that is off topic.

It turns out the ORGN system (like CORS) has to start out with WGS84
because it is GPS based.

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

I agree the trend is to obfuscate the term, but there it is.

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

Good.

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

You gotta dig, but it is there.  They do support other datums, but WGS84
is the default.

>  Perhaps they are showing
> maps to the public in WGS84 because that's how web mapping is done.

Or because that is what ESRI sells them.

> But I would be really surprised if their internal GIS databases were
> in other than NAD83 and NAVD88.  MassGIS works in those datums.

Who knows.  Once you have good conversions it does not really matter.

> > And the FAA still uses MSL.
> >
> > https://en.wikipedia.org/wiki/Lowest_safe_altitude  
> 
> That's about pressure altimiters.

Yes, that is how it started, but most autopilots and autoland systems
are now GPS based.  So now more about GPS.  Thus the need to MSL from
GPS.

>  My understanding is that
> aviation-related surveying data is in NAD83/NAVD88.

Better read the authoritative source than guess:

https://aeronav.faa.gov/afd/20jun2019/NW_front_20jun2019.pdf

"All elevations are in feet above/below Mean Sea Level (MSL) unless
otherwise noted.The horizontal reference datum of this publication is
North American Datum of 1983 (NAD83), which for charting purposes is
considered equivalent to World Geodetic System 1984 (WGS 84)."

The FAA considers NAD83 and WGS84 the same at their precisions.

>  NAVD88 can

There you go ogg topic again.  gpsd does not do NAVD88.

> loosely be called height above MSL, and really it's altitude above
> the long-term average of a particular tide gage

We are talking about real MSL (EGM2008), not outdated standards.

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

But how does gpsd know which audience it is talking to?  Some want
altHAE, some 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.

Huh?  The FAA talks all over about MSL altitude.

But being a unique symbol, we can define it as we wish: "height above
the EGM2008 geoid".


> Yes, altHAE is clear to people who understand.

And it matches the doc forom new GNSS.

And we define it in the doc as "height above the WGS84 ellipsoid" for
the pedantic.

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

Good.  I'll move on that then.

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

I guess the FAA is not US government?  See above.

And the USGS must not be either:

https://mrdata.usgs.gov/metadata/quad24.html

    Horizontal_Datum_Name: North American Datum of 1983
    Ellipsoid_Name: Geodetic Reference System 80

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

I already gave you the link to my city maps that are that way.

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

Yes, that is how it is used.  But unrelated to the data itself.

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

See RTKLIB.  But off topic.  We are talking datums, not their usage.
Except when the usage proves the datum is used.

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

Not hostile, simply dismissive of non-authoritative meanderings.  :-)

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

No,  not coordinates, you keep bringing up NAD83 coordinates, not me.

We are talking altitudes.  Stop getting distracted with coordinates.
MSL (EGM2008), as far as the FAA is concerned is basically NAD83 altitude.
Last I looked the FAA considered antyhing accuracy 40 foot or better
to be as good as it gets.  In that pass band MSL is NAD83.

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

No.  WGS84 + MSL.

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

Sigh, stop getting sidetracked by coordinates, we are talking altitudes.

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

And it seems like we agree on:
        altHAE
        altMSL
        geoidSep

That is really all I wanted from the beginning of this discussion.

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

Who brought up NAVD88?  gpsd does not do it, FAA does not use it, USGS
does not use it.  Red herring.

If gpsd users want other datums they have to convert from the gpsd ECEF
or WGS84.

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

With multiple frequency receivers getting cheap, and easily available PPP,
that is not a valid argument for anything.

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

With a single frequency receiver.  I can get down to about 1cm with PPP.
Under a meter with averaging.

But gpsd has to plan to tommorrow, not yesterday.

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

pgp0hVoXWN6Ap.pgp
Description: OpenPGP digital signature