Simplest way to convert from ITRF2020 to RGF93 and vice-versa

[y3nd]

Hello,

I don't know where to post this, maybe it could be nice to open the GitHub discussions section... Sorry if it's not the right place.

I need to convert ITRF2020 points with known epoch to RGF93 (ETRF2000@2019.0 or RGF93 v2b).
The pipeline system seems way too overkill to do this so I went with the cct or cs2cs tool.

First I tried this command
cct "ITRF2020 to ETRF2000 (1)" with geocentric coords
But the corresponding ETRF2000 seems to be on epoch 2015.0 in the transform.

Then I tried with cs2cs to be able to set the source and target epochs
First it didn't take the geocentric coordinates

cs2cs "ITRF2020@2024.6751" "ETRF2000@2019.0"
cart: Invalid latitude
*       * inf

I had to use the EPSG codes
cs2cs "EPSG:9988@2024.6751" "EPSG:7930@2019.0"
cs2cs "EPSG:9988@2024.6751" "EPSG:9780"

But I either get the same input coordinates or an error when using --no-ballpark

Rel. 9.5.0, September 15th, 2024
<cs2cs>:
cannot initialize transformation
cause: (null)
program abnormally terminated

[jjimenezshaw]

A better place for this kind of question is the mailing list
https://proj.org/en/stable/community/channels.html#mailing-list

With PROJ 9.6.0 it works for me:

$ echo 45 1 0 | cs2cs EPSG:9989@2024.6751 EPSG:7931 -d 9
44.999994176	0.999991915 -0.011097970

$ echo 45 1 0 | cs2cs EPSG:9989 EPSG:7931 -d 9
44.999995600	0.999994283 -0.006438389

[y3nd]

okay thanks

I got the same result from PROJ 9.5.0, no issue with EPSG:7931 without epoch. With epoch the result is the same with any decimal year value, maybe because EPSG:7931 is marked as static CRS ? ETRF2000 is not a fixed CRS

However the result is same as input when using EPSG:9784 (RGF93 v2b, locked on ETRF2000@2019.0) directly.
echo 45 1 0 | cs2cs EPSG:9989@2024.6751 EPSG:9784 -d 9
1.000000000 45.000000000 0.000000000

[jjimenezshaw]

However the result is same as input when using EPSG:9784 (RGF93 v2b, locked on ETRF2000@2019.0) directly.
echo 45 1 0 | cs2cs EPSG:9989@2024.6751 EPSG:9784 -d 9
1.000000000 45.000000000 0.000000000

PROJ is limiting the heuristics of the datum transformations to two steps. In this case it would need three:
ITRF2020 -> ETRF2000 -> ETRS89 -> RGB93 v2b

(Is there any better transformation chain with the data defined in EPSG?)

Due to that limitation, it is making a ballpark transformation.

In the future EPSG will introduce all the realizations in the ETRS89 datum ensemble.