[PROJ] Transformations in ITRF2020

Even Rouault even.rouault at spatialys.com
Tue Sep 3 04:21:39 PDT 2024


Javier,
>
> In the DB, the operation registered is ETRS89_TO_ETRF2020, so it has 
> to be "inverted". However, I do not see any way to indicate that in 
> the concatenated operation.
>
> For instance, this concatenated operation does not mention that the 
> second step should be "inverted" (if I understood correctly)
>     ('NKG', 'ITRF2014_TO_DK', 1, 'EPSG', '8366'), -- ITRF2014 -> ETRF2014
>     ('NKG', 'ITRF2014_TO_DK', 2, 'NKG', 'NKG_ETRF14_TO_ETRF2014'),
>     ('NKG', 'ITRF2014_TO_DK', 3, 'NKG', 'PAR_2020_DK'),
>     ('NKG', 'ITRF2014_TO_DK', 4, 'NKG', 'DK_2020_INTRAPLATE')
>
> Does it mean that PROJ is finding it automatically?
Unfortunately yes, PROJ has to figure out the direction of operations, 
and it is an awful and error prone job, especially when one of the step 
is a conversion which lacks explicit source and target CRS. I complained 
about that to IOGP to ask to add a direction (forward/inverse) column in 
the coordinate_step table, but I wasn't apparently sufficiently convincing.
>
> Thanks.
>
> PS Should I add the concatenated operation (ITRF2020->ETRS89) to PROJ 
> in a PR? There are different "paths" from ITRF2020 to ETRS89. All 
> apparently equivalent, but probably not exactly the same.

Maybe try first to see if EPSG wants to add it?


-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240903/a664cb1b/attachment.htm>


More information about the PROJ mailing list