[PROJ] Transformations in ITRF2020

Tue Sep 3 08:30:12 PDT 2024

Thank you!
It connects now with the transformation to CH1903+

I was not expecting that having the same bbox, different extents were
producing different results.

Cheers.
Javier.

On Tue, 3 Sept 2024 at 17:04, Even Rouault <even.rouault at spatialys.com>
wrote:

> 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/db142dcb/attachment-0001.htm>