Xavier, (re-adding the list)
Thanks for the hint. I should have looked more closely at the WKT
definition which does indicate the dynamic nature with frameepoch 1989
(and NATRF2022e2020 is a different beast with an *anchor epoch* of 2020)
Even
Le 21/06/2026 à 21:27, Xavier Collilieux a écrit :
Dear colleagues,
Yes, I confirm that ETRFxx are dynamic frames. Indeed, they are derived from
ITRFxx by applying a 14-parameter transformation. As ITRFxx are dynamic,
ETRFxx also are.
Best regards,
Xavier
-----Message d'origine-----
De : PROJ <[email protected]> De la part de Even Rouault via PROJ
Envoyé : dimanche 21 juin 2026 18:14
À : proj <[email protected]>
Objet : [PROJ] Time dependency in ETRFxx to ETRFyy coordinate transformations?
Hi,
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. On the US side
their recent renaming of
NATRF2022 to NATRF2022e2020 (epoch 2020.0) also shows similar confusion.
$ echo 49 2 0 2000 | bin/cs2cs -d 8 ETRF2000 ETRF2020
49.00000061 1.99999942 0.00346292 2000 $ echo 49 2 0 2015 | bin/cs2cs -d 8
ETRF2000 ETRF2020
49.00000065 1.99999955 0.01117636 2015 $ echo 49 2 0 2020 | bin/cs2cs -d 8
ETRF2000 ETRF2020
49.00000067 1.99999960 0.01374751 2020
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. But the ETRF2000
-> ITRF2020 direct transformation we have in PROJ must be the compaction of ITRF2000 ->
ITRF2000 -> ITRF2020)
/me still not having any clue at geodesy ;-)
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
