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.
