<div dir="ltr">All,<br><br>I am working on moving the NKG transformations from the NKG-init file to the PROJ database.<div>So far I have managed to re-create the transformation from ITRF2014 to the Danish realization</div><div>of ETRS89. Broadly, I have done this by <br><br>1. setting up a new datum+CRS called NKG_ETRF00 (used as a hub for<br>   the various transformations defined by the NKG)<br>2. adding a concatenated operation from ITRF2014 to NKG_ETRF00, using<br>   three steps (ITRF2014 -> ITRF2000 -> ETRF2000 -> NKG_ETRF00)<br>3. adding another concatenated operation from NKG_ETRF00 to ETRS89(DK),<br>   this time using two steps (NKG_ETRF00 -> ETRF92@2000.0 -> ETRF92@1994.704)<br>   <br>All of the above can be seen in this changeset:<br><br><a href="https://github.com/kbevers/PROJ/commit/cabea1134d704c4e2cbf968442763565994f1c56">https://github.com/kbevers/PROJ/commit/cabea1134d704c4e2cbf968442763565994f1c56</a><br><br>When querying the database with projinfo we can see that it works<br>as intended:<br><br>  $ PROJ_LIB=./data/ ./src/projinfo -s EPSG:7789 -t EPSG:4936 --area denmark -o PROJ<br>    Candidate operations found: 2<br> -------------------------------------<br> Operation No. 1:<br><br>    unknown id, Inverse of ITRF2000 to ITRF2014 (1) + ITRF2000 to ETRF2000 (2) + ETRF2000 to NKG_ETRF00 + NKG_ETRF00 to ETRF92@2000.0 + ETRF92@2000.0 to ETRF92@1994.704, 1.11 m, Denmark - onshore and offshore.<br><br>       PROJ string:<br>  +proj=pipeline<br>          +step +inv +proj=helmert +x=-0.0007 +y=-0.0012 +z=0.0261 +rx=0 +ry=0 +rz=0<br>                 +s=-0.00212 +dx=-0.0001 +dy=-0.0001 +dz=0.0019 +drx=0 +dry=0 +drz=0<br>                   +ds=-0.00011 +t_epoch=2010 +convention=position_vector<br>          +step +proj=helmert +x=0.054 +y=0.051 +z=-0.048 +rx=0.000891 +ry=0.00539<br>                   +rz=-0.008712 +s=0 +dx=0 +dy=0 +dz=0 +drx=8.1e-05 +dry=0.00049<br>                        +drz=-0.000792 +ds=0 +t_epoch=2000 +convention=position_vector<br>          +step +proj=deformation +t_epoch=2000.0 +grids=eur_nkg_nkgrf03vel_realigned.tif<br>      +step +proj=helmert +x=0.03863 +y=0.147 +z=0.02776 +rx=0.00617753 +ry=5.064e-05<br>                    +rz=4.729e-05 +s=-0.00942 +convention=position_vector<br>   +step +proj=deformation +dt=-5.296 +grids=eur_nkg_nkgrf03vel_realigned.tif<br><br>       -------------------------------------<br> Operation No. 2:<br><br>    unknown id, Ballpark geocentric translation from ITRF2014 to ETRS89, unknown accuracy, World, has ballpark transformation<br><br>   PROJ string:<br>  +proj=noop<br>    <br>Frankly, I am quite pleased about that. What I am not pleased about is that I haven't<br>managed to integrate this completely with the rest of the database. As an example, let's<br>say I want to transform between ITRF2008 and ETRS89(DK) instead:<br><br> $ PROJ_LIB=./data/ ./src/projinfo -s EPSG:5332 -t EPSG:4936 --area denmark -o PROJ<br>    Candidate operations found: 1<br> -------------------------------------<br> Operation No. 1:<br><br>    unknown id, Ballpark geocentric translation from ITRF2008 to ETRS89, unknown accuracy, World, has ballpark transformation<br><br>   PROJ string:<br>  +proj=noop<br>    <br>My expectation was that PROJ would connect the dots between my new transformations and the<br>existing transformation between ITRF2008 and ITRF2014. PROJ of course knows about it as<br>seen here:<br><br>   $ PROJ_LIB=./data/ ./src/projinfo -s EPSG:5332 -t EPSG:7789 --area denmark -o PROJ<br>    Candidate operations found: 1<br> -------------------------------------<br> Operation No. 1:<br><br>    EPSG:7790, ITRF2008 to ITRF2014 (1), 0.01 m, World.<br><br> PROJ string:<br>  +proj=helmert +x=-0.0016 +y=-0.0019 +z=-0.0024 +rx=0 +ry=0 +rz=0 +s=2e-05 +dx=0<br>                 +dy=0 +dz=0.0001 +drx=0 +dry=0 +drz=0 +ds=-3e-05 +t_epoch=2010<br>               +convention=position_vector<br><br><br>My question is, what have I missed? Should I add more records to the database? Or is my<br>expectation of PROJ's abilities completely of the mark? I suspect the problem might be that<div>what I want would require two hub-datums which I assume could be too big of a combinatorial</div><div>task for PROJ to solve in a reasonable time and hence is not happening.</div><div><br>I am trying to avoid adding a bunch of concatenated operations from various ITRFyyyy's<br>to NKG_ETRF00. Ideally I would skip the ITRF2014->ITF2000 step and let PROJ handle that on<br>it's own. Is that even possible?<br><br>/Kristian<br></div></div></div>