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

[Even Rouault]

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 <proj-bounces at lists.osgeo.org> De la part de Even Rouault via PROJ
> Envoyé : dimanche 21 juin 2026 18:14
> À : proj <proj at lists.osgeo.org>
> 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
> PROJ at lists.osgeo.org
> 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