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.roua...@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.
>
>
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
