gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Troxel
Subject: Re: ✘Here comes North American Terrestrial Reference Frame of 2022 (NATRF2022)
Date: Thu, 03 Feb 2022 09:50:21 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

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

> Yo All!
>
> Think you know datums?  See if this makes sens to you:
>
> https://geodesy.noaa.gov/library/pdfs/NOAA_TR_NOS_NGS_0062.pdf
>
> NAD 83 (2011) will be replaced by North American Terrestrial Reference
> Frame of 2022 (NATRF2022). And that is just the 1st paragraph.

Yes it makes sense.  Trying to simplify without getting it wrong; of
course those who don't want simplification can read the hundreds of
pages in all 4 documents.

NAD83's origin is not at the earth's center of mass, and while NAD83 is
related to ITRF now, the plate rotation estimate was a bit off so
crust-fixed stations have mm/year type velocities in NAD83.  However
~everybody uses 2010.0 coordinates anyway.  So this is really just
"technology has advanced to the point where we can do a lot better",
just as 27->83 was triggered by technology improvements.

Other significant bits:

  There will be a new definition of height, replacing NAVD88.  Height
  will be realized by ellipsoidal coordinates and a geoid model, in
  comparison to height currently being defined by leveling and passive
  marks.  I think this is conceptually a far bigger change than the new
  3D geodetic datum itself.

  There will be an intraframe velocity model, which is more or less
  about stations formally having coordinates at an epoch and velocities.
  Even though we are (except for some unstable Californians ;-) on a
  plate, we can now measure well enough that it is not being treated as
  fully rigid.  Besides earthquakes, places near plate boundaries,
  etc. there is subsidence (sinking, e.g. Lousiana) and glacial
  isostatic adjustment (land rising due to removal of ice mass,
  e,g. Alaska south coast).  I think that all of this is going to be
  modeled.

  It remains to see how surveyors and state GIS are going to deal with
  this.  The convention around me is to use epoch 2010.0 coordinates,
  which works because relative motion of (< 100km anyway) stations is
  very close to zero, and is convenient because stations do not have
  veloicities (by definition).

  NATRF2022 is not going to be released in 2022.  Latest I have heard is
  hoping for 2025.

All that said, I think only people using carrier-phase GPS observations
will be able to tell the difference between NAD83(2011) epoch 2010.0
coordinates and NATRF2022 coordinates, because I think the intent is to
keep coordinate values similar.  But I am not really sure about that.

(Note that only carrier phase users can tell the difference between
WGS84 and NAD83, and between NAVD88 and WGS84 orthometric heights,
except perhaps by very long averaging.)


And, I am not aware of gpsd dealing with datum, and that's not a
criticism of gpsd but more the nature of GPS receivers.  From a receiver
(same receiver at different times) one can get (US view; substitute your
SBAS and national datums):

  WGS84(current realization): navigation solution with no differential
  corrections

  Whatever frame WAAS uses, probably ITRF2008, in whatever epoch they
  use (2005.0?), when you use WAAS.  Probably same for EGNOS but it is
  also hard to find out what reference frame they use.

  Some NAD83, when using USCG differential beacons (historical only now).

  NADS83(2011) epoch 2010.0, when doing RTK with a reference
  station/network in that frame.

and while this should all have datum tags, it doesn't seem to in
practice.

So another big question about NATRF2022 is:

  When will RTK networks, e.g. MassDOT's, change to NATRF2022?

  When will state and federal GIS data change?

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]