<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Well. I tried it... and something does not work (probably a silly mistake)</div><div><br></div><div>at the end of data/sql/other_transformation_custom.sql I added this:<br></div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">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);<br>INSERT INTO "concatenated_operation_step" VALUES('PROJ','ITRF2020_TO_ETRS89',1,'EPSG','10573');<br>INSERT INTO "concatenated_operation_step" VALUES('PROJ','ITRF2020_TO_ETRS89',2,'PROJ','ETRS89_TO_ETRF2020');<br>INSERT INTO "usage" VALUES(<br>    'PROJ',<br>    'ITRF2020_TO_ETRS89_USAGE',<br>    'concatenated_operation',<br>    'PROJ',<br>    'ITRF2020_TO_ETRS89',<br>    'EPSG','1289', -- extent<br>    'EPSG','1024'  -- unknown<br>);</span></div><div><br></div><div>And the transformation is this ballpark:<br></div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">PROJ_DATA=../data/ ./projinfo EPSG:9990 EPSG:4258 --spatial-test intersects --bbox 7,42,8,43 -o proj<br>Candidate operations found: 1<br>-------------------------------------<br>Operation No. 1:<br><br>unknown id, Ballpark geographic offset from ITRF2020 to ETRS89, unknown accuracy, World, has ballpark transformation<br><br>PROJ string:<br>+proj=noop</span></div><div><br></div><div>While without that change it is this (just showing the first transformation)<br></div><div><br></div><div style="margin-left:40px"><span style="font-family:monospace">PROJ_DATA=../data/ ./projinfo EPSG:9990 EPSG:4258 --spatial-test intersects --bbox 7,42,8,43 -o proj</span></div><div style="margin-left:40px"><span style="font-family:monospace">Candidate operations found: 4<br>-------------------------------------<br>Operation No. 1:<br><br>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.<br><br>PROJ string:<br>+proj=pipeline<br>  +step +proj=axisswap +order=2,1<br>  +step +proj=unitconvert +xy_in=deg +xy_out=rad<br>  +step +proj=cart +ellps=GRS80<br>  +step +proj=helmert +x=0 +y=0 +z=0 +rx=0.002236 +ry=0.013494 +rz=-0.019578 +s=0<br>        +dx=0 +dy=0 +dz=0 +drx=8.6e-05 +dry=0.000519 +drz=-0.000753 +ds=0<br>        +t_epoch=2015 +convention=position_vector<br>  +step +inv +proj=cart +ellps=GRS80<br>  +step +proj=unitconvert +xy_in=rad +xy_out=deg<br>  +step +proj=axisswap +order=2,1</span></div><div style="margin-left:40px"><span style="font-family:monospace">...</span></div><div><br></div><div>Am I doing anything wrong?</div><div>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.</div><div>It is also surprising that not only it is not finding this concatenated operation, but not finding anyone!<br></div><div><br></div><div>Thanks,</div><div>Javier<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 3 Sept 2024 at 13:21, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    Javier,
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>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.<br>
        </div>
        <div><br>
        </div>
        <div>For instance, this concatenated operation does not mention
          that the second step should be "inverted" (if I understood
          correctly)<br>
        </div>
        <div><span style="font-family:monospace">    ('NKG',
            'ITRF2014_TO_DK', 1, 'EPSG', '8366'), -- ITRF2014 ->
            ETRF2014<br>
                ('NKG', 'ITRF2014_TO_DK', 2, 'NKG',
            'NKG_ETRF14_TO_ETRF2014'),<br>
                ('NKG', 'ITRF2014_TO_DK', 3, 'NKG', 'PAR_2020_DK'),<br>
                ('NKG', 'ITRF2014_TO_DK', 4, 'NKG',
            'DK_2020_INTRAPLATE')</span></div>
        <div><br>
        </div>
        <div>Does it mean that PROJ is finding it automatically?</div>
      </div>
    </blockquote>
    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.<br>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Thanks.<br>
        </div>
        <div><br>
        </div>
        <div>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.<br>
        </div>
      </div>
    </blockquote>
    <p>Maybe try first to see if EPSG wants to add it?</p>
    <br>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div>