[PROJ] Transformations in ITRF2020

[Even Rouault]

Javier,

Inspecting with "projinfo -k operation PROJ:ITRF2020_TO_ETRS89", you got 
the extent code wrong, it should be EPSG:4755 (using the same one as ETRS89)

The magic in the instantiation of concatenated operations also takes 
care of inserting the appropriate geographic<-->geocentric conversion 
steps. Cf 
https://github.com/OSGeo/PROJ/blob/master/src/iso19111/operation/concatenatedoperation.cpp#L554-L571

Once fixed, "projinfo ETRS89 ITRF2020" (only) reports that transformation.

Even

Le 03/09/2024 à 16:35, Javier Jimenez Shaw a écrit :
> Well. I tried it... and something does not work (probably a silly mistake)
>
> at the end of data/sql/other_transformation_custom.sql I added this:
>
> INSERT INTO "concatenated_operation" 
> VALUES('PROJ','ITRF2020_TO_ETRS89','ITRF2020 to 
> ETRS89','Time-dependent transformation from ITRF2020 to ETRS89 based 
> on EPSG:10573','EPSG','9990','EPSG','4258',0.1,NULL,0);
> INSERT INTO "concatenated_operation_step" 
> VALUES('PROJ','ITRF2020_TO_ETRS89',1,'EPSG','10573');
> INSERT INTO "concatenated_operation_step" 
> VALUES('PROJ','ITRF2020_TO_ETRS89',2,'PROJ','ETRS89_TO_ETRF2020');
> INSERT INTO "usage" VALUES(
>     'PROJ',
>     'ITRF2020_TO_ETRS89_USAGE',
>     'concatenated_operation',
>     'PROJ',
>     'ITRF2020_TO_ETRS89',
>     'EPSG','1289', -- extent
>     'EPSG','1024'  -- unknown
> );
>
> And the transformation is this ballpark:
>
> PROJ_DATA=../data/ ./projinfo EPSG:9990 EPSG:4258 --spatial-test 
> intersects --bbox 7,42,8,43 -o proj
> Candidate operations found: 1
> -------------------------------------
> Operation No. 1:
>
> unknown id, Ballpark geographic offset from ITRF2020 to ETRS89, 
> unknown accuracy, World, has ballpark transformation
>
> PROJ string:
> +proj=noop
>
> While without that change it is this (just showing the first 
> transformation)
>
> PROJ_DATA=../data/ ./projinfo EPSG:9990 EPSG:4258 --spatial-test 
> intersects --bbox 7,42,8,43 -o proj
> Candidate operations found: 4
> -------------------------------------
> Operation No. 1:
>
> unknown id, Conversion from ITRF2020 (geog2D) to ITRF2020 (geocentric) 
> + ITRF2020 to ETRF2020 (2) + Conversion from ETRF2020 (geocentric) to 
> ETRF2020 (geog2D) + Inverse of ETRS89 to ETRF2020, 0.1 m, Europe - 
> onshore and offshore - ETRF extent - approximately 16°W to 33°E and 
> 33°N to 84°N.
>
> PROJ string:
> +proj=pipeline
>   +step +proj=axisswap +order=2,1
>   +step +proj=unitconvert +xy_in=deg +xy_out=rad
>   +step +proj=cart +ellps=GRS80
>   +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.002236 +ry=0.013494 
> +rz=-0.019578 +s=0
>         +dx=0 +dy=0 +dz=0 +drx=8.6e-05 +dry=0.000519 +drz=-0.000753 +ds=0
>         +t_epoch=2015 +convention=position_vector
>   +step +inv +proj=cart +ellps=GRS80
>   +step +proj=unitconvert +xy_in=rad +xy_out=deg
>   +step +proj=axisswap +order=2,1
> ...
>
> Am I doing anything wrong?
> I guessed that EPSG:10573 is a transformation between geocentric 
> systems, while PROJ:ETRS89_TO_ETRF2020 is between geographic 2D. So 
> there could be a missing geocentric->geographic2D in between. But I 
> don't know how to set it.
> It is also surprising that not only it is not finding this 
> concatenated operation, but not finding anyone!
>
> Thanks,
> Javier
>
> On Tue, 3 Sept 2024 at 13:21, Even Rouault 
> <even.rouault at spatialys.com> wrote:
>
>     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.
>
-- 
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/151bf15a/attachment.htm>