Re: DTM sentence and Russian datums in US phones (yes, that's clickbait!)

[Gary E. Miller]

Yo Greg!

On Thu, 17 Jun 2021 07:18:56 -0400
Greg Troxel <gdt@lexort.com> wrote:

> "Gary E. Miller" <gem@rellim.com> writes:
> 
> > On Wed, 16 Jun 2021 21:29:25 -0400
> > Greg Troxel <gdt@lexort.com> wrote:
> >  
> >> Over at GPSTest (and Android program for telling you what your GNSS
> >> chip is doing), people report that some phones have strange
> >> elevations, and digging in there appear to be be two notable
> >> oddities:
> >> 
> >>   geoid models that are wrong to a degree even more surprising than
> >>   u-blox's reporting of -33m when it should be -29m.  
> >
> > Different geoid models differ from each other by up to 200m.  Before
> > you ccan compare geoids you need to know which geoid.  WGS84 is not
> > a geoid, it is a framework for geoids.  You also need to know the
> > year of the WGS84 data set.  Like WGS84-1984, WGS84-2004, etc.  
> 
> WGS84 is a datum,

No, it is a model for datums.  WGS84 changes every few years.  
Like WGS84-1984, WGS84-2004, etc.  

> but in incorporates by reference a geoid model
> EGM2008 which defines "WGS84 orthometric height".

Yes, one of many slightly different WGS84.

>  What I am saying
> is there there is a right answer for EGM2008, and that receivers
> which should be producing EGM2008 geoid offsets are getting that
> wrong in the -29m/-33m sense, and some others way worse.

Of course.  Without 40MB of data you can not propperly conpute EGM2008.

> >> an example is:
> >> 
> >>   $GNDTM,P90,,0.000021,S,0.000002,E,0.989,W84*57,,,,,,,,,,,,
> >> 
> >> explained, sort of, at:
> >> 
> >>   
> >> https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_GPDTM.html
> >>  
> >
> > And here: https://gpsd.io/NMEA.html#_dtm_datum_reference  
> 
> Which also doesn't explain what it means when "local datum" field has
> the code P90 but the datum field is W84.

Oh, you need to read the copy restricted NMEA 0183 doc!

Field 1 (Local Datum), set to P90, is how the following lat/lon,alt is
calcualted.  Followed by the offsets from the reference dataum, which is WG84.

So you sentence says your lat/lot/alt will be P90, and that is 0.000021 S
or the same lat in WGS84.


> I also haven't found anything saying if PZ-90 has an
> associated-by-definition geoid model and notion of orthometric height
> (vs HAE which it straightforwardly does).

https://en.wikipedia.org/wiki/PZ-90

PZ-90 also has more than one version.

http://www.unoosa.org/pdf/icg/2014/wg/PZ-90.11_2014.pdf

Conceptually close to WGS84, but the Russians use constants that are
closer to "actual" at hight lattitudes than WGS84.

> 
> > Usually WGS84, the NMEA default.  From the gpsd regression tests:
> >
> > test/daemon//saab-r4.log:$GPDTM,W84,C*52  
> 
> So that has only 1 field, but there are many more in all the
> descriptions.

You asked what I have seen.  That is what I have seen.

>  I see that as "WGS84" in the "local datum" code, and
> the rest are missing/null.  But that's the default expectation anyway.

Since WGS74 has zero offset from WGS84, no need to include the
offsets.

> >> Certainly, I'd expect that if one put a Garmin into NAD27,
> >> you'd have the transform.  
> >
> > gpsd does no transforms.  That gets ugly fast.  
> 
> Sure, but if you put a Garmin in NAD27, it does transform.  I used to
> use that to look up points on paper topo maps in the 90s.

I said gpsd does no transforms, of course the reeceiver does.  But
without the large database, only to an approximation of true.

> >> But today, that seems unusual (unless
> >> navigating in a country with a local datum that isn't more or less
> >> ITRFF2008), using local maps.  Even in the US, which has a national
> >> datum, people navigate with their phones in WGS84.  
> >
> > Except USA maps are not WGS84!  They are NAD84 and altitude in MSL.
> >  
> 
> There is no "USA maps" and there is no MSL.  There are maps from the
> USGS and the National Map, which are NAD83 with heights in NAVD88.
> There are older USGS maps in NAD27 and heights in NGVD29.

Which as I said, are not WGS84.

Everything the FAA does, which is a lot of maps, is MSL.

https://www.3dr.com/wp-content/uploads/2020/02/Chart-legend-01.png

> But when people navigate with phones, they are using maps from
> Openstreetmap, Google, or Apple.

Which are marginal.

> OSM is defined to be in WGS84, and
> Google's TMS tiles appear to be in WGS84 (and they might even document
> that).  I find Google/Apple to be opaque about metadata.

Yup.  No way to tell what they do.

> And, in New England at least NAD83/WGS84 is only ~1m different in
> horizontal and NAVD88 and WGS84/EGM2008 are similarly close.

Yeah, becuase you are near the national sea level reference point on
the St. Lawrence seaway.  By the time you get to the west cosst the errors
are much larger.  Actually, amazingly small considering the tech they
ahd.  

You get to Hawaii, and they are way off.  Party due to the rapid
graivtational changes nearby.

> It takes
> RTK to perceive that difference, and it takes really accurate maps.

All I have to do is take my receiver to a local USGS benchmark
to see the difference.  Or compare my different receivers.


> >> What's funny is that PZ90.11 is so close to ITRF2008 that unless
> >> you are playing at the 10 cm level or better it can be treated ~=
> >> ITF2008 != WGS84(G1762).  
> >
> > And what about the other WGS84 that are > 10 cm from WGS84(G1762).  
> 
> It's only the older ones that are that far off (TRANSIT and G730),

I suggest you look at the USGS error maps for the PNW.  > 10 cm.

> >> I do not believe that the frame being odd and the bad geoid model
> >> are logically related, but they may both be in the same chip out
> >> there.  
> >
> > Since the geoids change rapidly, the geoid baked into any firmware
> > will diverge from what other receivers have.  
> 
> EGM96 and EGM2008 are different, but when I looked them up to compare
> to what the receiver had, the differences among model updates were
> tiny compared to the unexplained errors.  For Boston, we're talking
> 30cm going all the  way back to EGM84:
>   
> https://geographiclib.sourceforge.io/cgi-bin/GeoidEval?input=42+-71&option=Submit
> 
> and NW, only 1m to EGM84 and much less from EGM96.

See above about the St. Lawrence benchmark.

> yet I am seeing -33 in a recent receiver.  That's not explainable as
> using the previous version of the model.

But explainable by approximating the geoid in the receiver.  Down
the full geoid model and play with it.  The geoid is no at flat as
people expect.

> > The receivers that do multi-GNSS have to convert frames, more or
> > less. The current WGS84 table is now over 40MB, so do not exepct
> > any receiver to get it right.  
> 
> I don't know what you mean about "WGS84 table and 40 MB".

To get a proper WGS84 height, you need a huge loolup table.  You can
not mathmatically calculate it.

This is for EGM2008, the newer ones are much bigger.

http://bgi.obs-mip.fr/data-products/grids-and-models/egm2008-global-model/

> They don't have to convert; they can assume equivalence.

Yeah, they can assume, any differenet receivers assume differently, and
do not agree with the charts.

> And, it
> seems like all 4 global GNSS system frames are equivalent to a cm or
> so, and that therefore, applications other than geodetic surveying,
> it's sensible to treat them as equivalent.

Nope.  Take a look at the DTM that you mention above.  The offsets are
there!

> >>  My working hypothesis is
> >> that one can't really detect any errors from assuming equivalence
> >> in a navigation solution  
> >
> > My experience, and what you saw with P90, says otherwise.  
> 
> Can you explain the experiment to detect?

Your DTM above is all you need.  The offsets are there.
Or flip the datum on your GPS around and watch your position jump.

The practical effect that I see is that GLONASS gets kicked out of
sat solutions due to it archituctural sloppiness.

>  Navigation solutions *with
> no differential* have errors that are vastly more than a cm, and
> almost always multiple meters.  What do you compare to what, and how
> do you then say that it's because two frames that have a non-null
> cm-level transform skipped that cm-level transform?

I was simply comparing the database tables to see the changes in
WGS84 between years.

> What I think people are seeing with the P90 DTM sentence is:
> 
>   inexplicable buggy behavior in choice of or reprorting of datum,
> which has not been shown to cause a perceptible error

Buggy I buy, but very explixable.

> >> and that once you do RTK you are in the reference
> >> stations frame anyway.  
> >
> > Once you post process it is out of the hands of gpsd or the
> > receiver.  
> 
> Some receivers do RTK onboard.

True, then, as you say, referenced to a local base, not absolutley
accurate.  For best accuracy you need PPP.

> But it's not about post process, it's about a differential solution.

Now WAY off the subject of DATUMS.

> They never do but I don't think that has anything to do with assuming
> frame equivalnce when merging multiple constellations.

No assumptions needed.  All constellations use Earth Centered Inertial
coordinates derived from Kepler parameters.  Those are all converted to
ECEF so they can all be used in computing one solution.  Only after an
ECEF solution is computed is that transformed to a datum.

>  In my
> experience, adding constellations makes things better, not worse.

Depends on the constellation.  Galileo now helps a GPS solution.  GLONASS
not.


RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp4Hc7bfGguw.pgp
Description: OpenPGP digital signature