Re: [gpsd-dev] ✘wgs84_separation()

[Greg Troxel]

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

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

No, it's a model of where the geoid is, which is an equipotential
surface.  That surface is chosen to be more or less sea level in a fuzzy
sense, but the real point of EGM2008 and other similar things is to
describe a precise equipotential surface relative to the ellipsoid.

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

Sure.  That's why I was saying that Mean Sea Level is not really what it
sounds like.  Hence the geodesy trend to not use the word; if you mean
the geoid of some standard gravity, then say that, not something that
gives the wrong idea.

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

I was replying to you!  But you are talking about NAD83 having heights
above sea level.  It does not.  It is strictly a horizontal datum (with
ellipsoidal heights), and does not relate to gravity at all.  That's
important to understand if you use it at all.

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

Not true.  When you do double differential carrier phase, and have
orbits in some datum (eg. IGS08 or ITRF2014) and station coordinates in
the same datum, you can and do completely ignore WGS84, and get
solutions in the orbit/station datum.  And that's what people do.  Look
up the CORS pages, and you'll see coordinates published in IGS08 and
NAD83.  Not in WGS84.  At least that's what I found for WES2 within the
last few days.

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

I can totally believe that.

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

Which means they are blowing off 1-2m in horizontal.  From a serious
geodesy point of view, defining something as feet above MSL is hard to
believe these days.  It seems pretty clear given the NSRS definition
that they must 1) mean NAVD88 and 2) not really understand what they
mean, or be choosing to be sloppy to avoid confusing people.

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

NAVD88 is not outdated, but merely kind of old; it is the current United
States "National Spatial Reference System" for heights.  It is simply a
different thing from WGS84/EGM2008.  (The US (and maybe CA) is adopting
a new height system based on gravity models, but not until 2022.  Then,
NAVD88 will be outdated.)

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

Which is what I meant, the height above geoid computed from ellipsoidal
height and a geoid model.

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

That's horizontal, not vertical.  Before GPS, horizontal datums and
vertical datums were pretty disconnected.  Maps from USGS that have
NAD83 as the horizontal datum have NAVD88 as the vertical datum (for
contour lines and spot elevations).

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

I don't follow "unrelated".  When you take raw observables and do PPP
with ITRFxx orbits, you are not working in WGS84.

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

But you said that aviation people wanted something other that WGS84,
which in the use mus be NAD83.  You are being increasingly hard to
follow.  If you don't want NAD83 brought up, then 100% of users are
perfectly ok with WGS84 coordinates (lat, lon, height above geoid, maybe
also heigh above ellipsoid).  Is that what you mean?

> We are talking altitudes.  Stop getting distracted with coordinates.

altitude is one coordinate of a 3d system.  My point is that people in
the US (other than those doing geodetic surveying) almost always want

  wgs84 horizontal coordinates, and height above wgs84 geoid

  nad83 horizontal coordinates, and height in navd88

> MSL (EGM2008), as far as the FAA is concerned is basically NAD83 altitude.

There is no such thing as nad83 orthometric height.  The vertical datum
for orthometric height that is used with nad83 is navd88.

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

I believe that WGS84 height above geoid is within a meter or two of
NAVD88.

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

So you agree that all gpsd users need WGS84, and only WGS84, and there
is no reawson for gpsd, or any gpsd user, to ever need NAD83?  (I was
pretty sure that's not what you meant before.)

> And it seems like we agree on:
>       altHAE
>       altMSL
>       geoidSep
>
> That is really all I wanted from the beginning of this discussion.


Yes, that's good enough to stop arguing.

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

Untrue.  It is the legal definition of height in the US.  USGS
definitely uses it.   I don't believe the notion that  the FAA doesn't
use it.  I do believe that they are sloppy and talk about MSL when they
really mean NAVD88.

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

That's interesting that PPP is that good.  I'll have to find some
Copious Spare Time to try it.