[PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations?

[Greg Troxel]

Even Rouault via PROJ <proj at lists.osgeo.org> writes:

> I was reading
> https://lists.osgeo.org/pipermail/qgis-user/2026-June/056346.html
> where Greg mentions "Also use command-line proj:  $ projinfo -s
> ETRF2000 -t ETRF2020 which returns a lot of operations that surprise
> me, being time-dependent transforms with non-zero rates".
>
> Indeed PROJ does that transformation using a ITRF2020 pivot, which is
> in line with the EUREF technical note 1
> (http://etrs89.ensg.ign.fr/pub/EUREF-TN-1-Mar-04-2024.pdf). But the
> consequence of using such time-dependent transforms is that the
> results depends *and change* on a coordinate epoch.  So ETRFxx frames
> are not "static" ? From a number of things seen in past years, it
> looks to me that this opposition of static vs dynamic frames is still
> very fuzzy and perhaps is not relevant at all.

I think we're suffering from increased measurement accuracy.

As I understand it, a static datum is one where stations (of stable
physical monuments) have coordinates and do not have velocities.  This
is a definitional choice rather than a physical reality.  Traditional
plate-fixed datums (NAD27, original NAD83, probably ED50) are like this.

A dynamic datum is where the datum definition assigns both coordinates
and velocities to monumented stations.  It seems the velocities can be
per station, or there can be a plate motion model.

NAD83(2011) is defined in terms of ITRF and a rotation, intending to
make it plate fixed.  But it's not quite, we now know, super roughly 2
mm/y station velocities vs 20 mm/y velocities in ITRF.  Thus, static
carrier phase solutions and RTNs operate in "epoch 2010.0" which is
truly static because it is defined that way.

As I understand ETRS89 (a system not a datum?), there is similarly a
defined rotation from ITRF.   One then has two choices:

  - 1) say that the coordinates will evolve with some no net motion
    constraint over all of Eurasia
  - 2) say that the system is forever that rotation from ITRF

and I believe it is 2 that was chosen (but I am fuzzy on ETRS).

Thus, ETRFnnnn are not truly static, they are close-to-static, and I
think this is in exactly the same sense as NAD83(2011) is
close-to-static (but perhaps with a lower velocity).

Unlike NAD83(2011), there are multiple and continuing ETRF realizations,
and ETRS/ETRF* is conceptually much more like NATRF2022 than
NAD83(2011).

I find it surprising (that's a comment about me, not EU choices!)  and
interesting that official guidance goes through ITRF.  There's a big
question of whether time transformation of ITRF coordinates is according
to a plate motion model, implying that a monument is being transformed,
vs a more abstract coordinate location not fixed -- and that's where I
start feeling unclear.

> On the US side their recent renaming of NATRF2022 to NATRF2022e2020
> (epoch 2020.0) also shows similar confusion.

I just looked at
  https://beta.ngs.noaa.gov/NATRF2022/
and don't see this mentioned.

NATRF2022 includes an "intra-frame velocity model", which more or less
is "stations have coordindates at the epoch and a velocity", except that
there are individual station velocities; this is especially important in
deformation zones between the NA and PA plates where it's messy and
can't be modeled by a rotation.  I am not aware of this part of the "new
datums" changing.

While geodesists and researchers want the full complexity, surveyors and
highway departments don't.  They want a static datum that covers their
area of work.  NAD83(2011) epoch 2010.0 served that need (and still
does), and I think NATRF2022e2020 is exactly the same concept: an RTN
might operate so that users get the epoch 2020.0 coordinates.  I would
thus consider this CRS a static datum, even though that's a little funny
in terms of definitions.

As an example, if I go to a passive control and use an RTN in
NAD83(2011) epoch 2010.0 for each of January 1-5, 2020 and record
points, and do it again in January 1-5, 2026, I expect all 10 points to
cluster and show no drift from the 1st 5 to the 2nd 5.

With EPSG:6319, it's ambiguous if it means the dynamic datum NAD83(2011)
or the static datum NAD83(2011) epoch 2010.0.  My take is that 99.9% of
actual uses of the codepoint mean the static/2010.0 version.


It's amazing how good low-cost equipment (ublox F9P, Mosaic X5) with a
decent ($100ish) antenna is, with a professsonal RTN.  A friend measured
a passive control something like 4 times over 2 days, and I plotted the
4 values and those from an OPUS solution produced by a professional
surveyor with MassDOT.  I visualized these in qgis and zoomed in.  Of
course, any distribution looks like it is 2/3 the screen width!  The
human can note the scale and be careful, but it's hard to perceive.  My
friend then plotted the coordinates on metric graph paper (which nerds
in the US can get :-) at 1:1 scale.  It was trimmed to about 2cm by 2 cm
and the cluster was mostly about 1 cm in diameter.  This was a
completely different impression than looking at the screen; errors that
seemed, well, 2/3 of the screen, were seen to be thumb sized.  I think
this is a large part of why the larger community is considering more and
more frames to be dynamic, because 2 mm/y * 10 years is easily 2
standard deviations for the measurement error, and would be the dominant
error if not corrected.

> The good news is that while playing with the online  ETRF/ITRF
> Coordinate Transformation Tool (ECTT)  tool
> (https://epncb.oma.be/_productsservices/coord_trans/index.php#results),
> both this tool and PROJ agree at the tenth of millimeter on a few
> random points I tried, and when checking the " show intermediate
> steps" tick box, one can also see they use a ITRF2020 intermediate
> (actually they do ETRF2000 -> ITRF2000 -> ITRF2020 -> ETRF2020 at the
> specified epoch.

That's great things are so close!  This week, I see 0.1 mm as totally
acceptable rounding/etc. error.  1 mm is probably actually ok but
socially unacceptable and 1 cm is IMHO a real problem.

> But the ETRF2000 -> ITRF2020 direct transformation we have in PROJ
> must be the compaction of ITRF2000 -> ITRF2000 -> ITRF2020)

Interesting; ever more things to understand....