Re: ✘Here comes North American Terrestrial Reference Frame of 2022 (NATRF2022)

[Gary E. Miller]

Yo Greg!

On Thu, 03 Feb 2022 15:54:31 -0500
Greg Troxel <gdt@lexort.com> wrote:

> Yes, but:
> 
> 1) ECEF is not fully defined.  That's not a data
> representation,

Yes, like lat/lon, it only makes sense when you specify the datum:
IS-GPS-200F, the GPS standard, specifies that the ECEF datum to use is
the IERS (International Earth Rotation and Reference Systems Service).
That uses a defined Reference Pole (IRP) and IERS Reference Meridian
(IRM).

"Section 20.3.3.4.3.3.1 ECEF Coordinate System" looks pretty well
defined to me.

Since I am talking GPS, the ECEF datum is well defined.

Sadly the IERS does move around a lot over time.  So few receivers are
using a current version.

> But, the conversions gpsd is
> doing are in practice independent of datum because pretty much all
> datums in use the same ellipsoid (GRS80, or a
> hard-to-tell-it's-different variant in WGS84).

For practical purposes, yes.  But GLONASS specifies a different
ellipsoid than GPS, and the new standard will use yet another one.

geographicLib provides 3 ellipsoids, some of which differ by many
meters.

EGM84: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84#tab_egm84
EGM96: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84#tab_egm96
EGM2008: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84#tab_egm2008

Tha last of which is time variant.

> > Some of that comes from a precalculated grid of valuse from the
> > geographiclib package.  I have toyed with allowing gpsd to inegrate
> > more directly with that package.  
> 
> That would be interesting.   And/or proj.

geographicLib is way more than proj.  But proj would be an improvement.
geographicLib uses the large tables from the feds.

Because gpsd gets embedded, adding libs has been done with caution.


> > And the more modern datums have time varying companents, so you also
> > need to know the date that the firmware used for it internal
> > tables.  
> 
> What you really need to do is to carry positions with a time component
> so that transforming to other times can use velocities.

Which gpsd can allow externally.  Doing so internally requires large
databases (40M+).

> >> I think we will be able to avoid dealing with those questions for
> >> several years, at least those of us that don't work in those
> >> agencies.  
> >
> > We already worry about 2038 rollover, this will be sooner.  BUt, as
> > you said, hardly anyone will really notice the small changes.  
> 
> Right now receivers output in varying datums depending on the
> reference frame of the corrections or reference data service.

And as far as I know, they are all pretty sloppy.  relatively.

> For
> me, it's either WGS84(latest) which is essentially recent ITRF when
> not doing RTK, and it's NAD83(2011) 2010.0 when doing RTK.  As far as
> I can tell the receiver does not output this, and gpsd has no idea.
> So it won't notice NATRF2022 either when the RTK network switches.

Which is why so many users have gpsd emite raw and/or ECEF, so the
daum can be done better.

> GPS receivers do (did?) have  way to transfrom from WGS84 to some
> other datum, like NAD87.  But they don't seem to have a way to label
> the solution as being in some other datum.

Some, maybe most, revievers allow datum to be queried.  BUt as a rule,
gpsd does not care, up to the user to confirm his receiver is set to a
usefull datum.

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

pgpV5th87UTsl.pgp
Description: OpenPGP digital signature