Simplest way to convert from ITRF2020 to RGF93 and vice-versa
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 ([email protected] 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 "[email protected]" "[email protected]"
cart: Invalid latitude
* * inf
I had to use the EPSG codes
cs2cs "EPSG:[email protected]" "EPSG:[email protected]"
cs2cs "EPSG:[email protected]" "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
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:[email protected] 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
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 [email protected]) directly. echo 45 1 0 | cs2cs EPSG:[email protected] EPSG:9784 -d 9 1.000000000 45.000000000 0.000000000
However the result is same as input when using EPSG:9784 (RGF93 v2b, locked on [email protected]) directly. echo 45 1 0 | cs2cs EPSG:[email protected] 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.