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

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> Greg Troxel <gdt@lexort.com> wrote:
>
>> And, I am not aware of gpsd dealing with datum,
>
> If the GNSS receiver is only sending ECEF coordinates, then gpsd will
> calculate lat/lon/alt and magnetic variation using wmm2015. EGM2008.and
> WMM2015.

Yes, but:

1) ECEF is not fully defined.  That's not a datum, but a representation,
and each WGS84, each ITRF, and most NAD83 can be and are reprsented in
ECEF.  But they have different ideas of the center of the earth,
rotations etc., and are realized by published tables of coordinates of
specific stations.

To see the huge list of datums that can have XYZ values:

https://github.com/jjimenezshaw/crs-explorer
https://jjimenezshaw.github.io/crs-explorer/

Picking someplace mid US:

https://jjimenezshaw.github.io/crs-explorer/?latlng=43.128785,-99.404297&ignoreWorld=false&allowDeprecated=false&authorities=EPSG&activeTypes=GEOCENTRIC_CRS

and they are all ECEF, different datums.


To calculate lat/lon/hae from XYZ you need to know the ellipsoid.
That's part of the datum definition.  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).  But it takes XYZ in some datum and produces lat/lon/hae in
that same datum.

3) WMM, EGM2008 are defined, (EGM2008 is and surely WMM must be --
that's how NGA rolls), in terms of WGS84.  It doesn't make sense to use
them with other datums.  Except that all modern datums are so close
compared to resolution of the models that it's ok anyway.

> gpsd/geoid.c
>
> 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.

>> and while this should all have datum tags, it doesn't seem to in
>> practice.
>
> 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.

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




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.

signature.asc
Description: PGP signature