<div dir="ltr"><div>Thanks Even.</div><div><br></div><div>Yes, I will contact BKG.</div><div><br></div><div>I was thinking on another option: defining a Helmert transformation between ETRS89/DREF91/2016 and ETRS89, (probably with 0,0,0 params) and some (in)accuracy, to "connect" the new system with the old ones. Otherwise the "new" systems and the "old" ones are disconnected and only ballpark transformations are possible. Something like <a href="https://epsg.org/transformation_9703/ETRF2000-PL-to-ETRS89-1.html">https://epsg.org/transformation_9703/ETRF2000-PL-to-ETRS89-1.html</a> for Poland. (<a href="https://epsg.org/search/by-name/?query=ETRF2000-PL">https://epsg.org/search/by-name/?query=ETRF2000-PL</a> sounds very similar to <a href="https://epsg.org/search/by-name?searchedTerms=ETRS89%2FDREF91%2F2016">https://epsg.org/search/by-name?searchedTerms=ETRS89%2FDREF91%2F2016</a> but without that "link" to the "old" systems). <br></div><div>What do you think about this? Would it work?</div><div><br></div><div>Thanks.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 29 Apr 2023 at 19:03, 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">
<div>
<p>Javier,</p>
<p>I believe PROJ behaves as best as it can given what it has in the
database. The related change record in the postgreSQL dump is:<br>
</p>
<p>INSERT INTO epsg_change (change_id, report_date, date_closed,
reporter, request, tables_affected, codes_affected,
change_comment, action) VALUES (2023.006, '2023-01-24',
'2023-03-01', 'Martina Sacher; BKG, for AdV', 'Add Germany DREF91
2016 realization.', 'Coordinate Reference System; Datum;
Coordinate Operation', '4647 5649 5650 5651 5652 5653 7837 8395
9924; 1170; 9925 9926', 'National realization of ETRS89. Extends
DHHN2016 from onshore to onshore and offshore. Continued in change
requests 2023.007 and 2023.008.', 'Added datum 1353, CRSs
10282-10291 and 10293, CTs 10292 and 10294-10295. Deprecated CRSs
8395 and 9924 and CTs 9925 and 9926. For CRSs 4647 and 5649-5653,
added supersession trail. For datum 1170, amended origin
information and changed extent code from 3339 to 1103. For CRS
7837, amended remarks and changed extent code from 3339 to
1103.');<br>
</p>
<p>Either you locally patch your proj.db to set the deprecated flag
of EPSG:9925 and EPSG:9926 back to 0.</p>
<p>Or more future proof, try to coordinate with IOGP and/or BKG/AdV
so they undeprecate them, possibly with an (in)accuracy greater
than the 2cm one that probably only applies to ETRS89/DREF91/2016
to DHHN2016, but not to generic ETRS89 to DHHN2016.</p>
<p>Even<br>
</p>
<div>Le 29/04/2023 à 18:32, Javier Jimenez
Shaw a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi</div>
<div><br>
</div>
<div>When doing transformations from WGS84 (or ETRS89) to "DHDN
+ DHHN2016 height" in PROJ 9.2.0 (using a German geoid file),
it works fine.</div>
<div>However in master it is only doing the vertical part,
producing an error of more than a hundred meters horizontally.</div>
<div><br>
</div>
<div>I was going to open an issue, but then I realized that EPSG
was recently updated, and maybe that is the reason.</div>
<div><br>
</div>
<div>I have a "proper" German geoid mode grid file. For this
example I just copied the EGM2008 tif file into GCG2016.txt,
and put it next to proj.db. The accuracy of the vertical
component is not important in this case.</div>
<div><br>
</div>
<div>(Note: BKG is working on releasing the German geoid model
free. Let's see when it finally happens and the license they
use.)</div>
<div><br>
</div>
<div>In PROJ 9.2.0, the pipelines obtained with projinfo make
sense to me, including both, horizontal and vertical
operations:
<div dir="auto">
<pre>PROJ_NETWORK=ON projinfo -o proj --spatial-test intersects -s EPSG:4979 -t EPSG:31468+7837
Candidate operations found: 10
-------------------------------------
Operation No. 1:
unknown id, Inverse of ETRS89 to WGS 84 (1) + ETRS89 to DHHN2016 height (1) + Inverse of DHDN to ETRS89 (8) + 3-degree Gauss-Kruger zone 4, 1.92 m, Germany - onshore - states of Baden-Wurtemberg,
Bayern, Berlin, Brandenburg, Bremen, Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Sachsen, Sachsen-Anhalt, Schleswig-Holstein, Thuringen.
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +inv +proj=vgridshift +grids=GCG2016.txt +multiplier=1
+step +inv +proj=hgridshift +grids=de_adv_BETA2007.tif
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
Operation No. 2:
unknown id, Inverse of ETRS89 to WGS 84 (1) + ETRS89 to DHHN2016 height (1) + Inverse of DHDN to ETRS89 (2) + 3-degree Gauss-Kruger zone 4, 4.02 m, Germany - states of former West Germany onshore -
Baden-Wurtemberg, Bayern, Bremen, Hamburg, Hessen, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Schleswig-Holstein.
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +inv +proj=vgridshift +grids=GCG2016.txt +multiplier=1
+step +proj=push +v_3
+step +proj=cart +ellps=GRS80
+step +inv +proj=helmert +x=598.1 +y=73.7 +z=418.2 +rx=0.202 +ry=0.045
+rz=-2.455 +s=6.7 +convention=position_vector
+step +inv +proj=cart +ellps=bessel
+step +proj=pop +v_3
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
</pre>
However The pipelines in master do use the vertical or
horizontal transformation, but not both:<br>
<div dir="auto">
<pre>PROJ_NETWORK=ON projinfo -o proj --spatial-test intersects -s EPSG:4979 -t EPSG:31468+7837
Candidate operations found: 5
-------------------------------------
Operation No. 1:
unknown id, Inverse of Ballpark geographic offset from ETRS89/DREF91/2016 to WGS 84 + ETRS89/DREF91/2016 to DHHN2016 height (1) + Inverse of Ballpark geographic offset
from DHDN to ETRS89/DREF91/2016 + 3-degree Gauss-Kruger zone 4, unknown accuracy, Germany - onshore and offshore., has ballpark transformation
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +inv +proj=vgridshift +grids=GCG2016.txt +multiplier=1
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
Operation No. 2:
unknown id, Inverse of Transformation from DHHN2016 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of
DHDN to WGS 84 (4) + 3-degree Gauss-Kruger zone 4, unknown accuracy, Germany - onshore - states of Baden-Wurtemberg, Bayern, Berlin, Brandenburg, Bremen,
Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Sachsen, Sachsen-Anhalt, Schleswig-Holstein, Thuringen., has ballpark transformation
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +inv +proj=hgridshift +grids=de_adv_BETA2007.tif
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
Operation No. 3:
unknown id, Inverse of Transformation from DHHN2016 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of
Ballpark geographic offset from DHDN to WGS 84 + 3-degree Gauss-Kruger zone 4, unknown accuracy, World, has ballpark transformation
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
Operation No. 4:
unknown id, Inverse of Transformation from DHHN2016 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of
DHDN to WGS 84 (2) + 3-degree Gauss-Kruger zone 4, unknown accuracy, Germany - states of former West Germany onshore - Baden-Wurtemberg, Bayern, Bremen, Hamburg, Hessen,
Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Schleswig-Holstein., has ballpark transformation
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=push +v_3
+step +proj=cart +ellps=WGS84
+step +inv +proj=helmert +x=598.1 +y=73.7 +z=418.2 +rx=0.202 +ry=0.045
+rz=-2.455 +s=6.7 +convention=position_vector
+step +inv +proj=cart +ellps=bessel
+step +proj=pop +v_3
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
-------------------------------------
Operation No. 5:
unknown id, Inverse of Transformation from DHHN2016 height to WGS 84 (ballpark vertical transformation, without ellipsoid height to vertical height correction) + Inverse of
DHDN to WGS 84 (3) + 3-degree Gauss-Kruger zone 4, unknown accuracy, Germany - states of former East Germany - Berlin, Brandenburg<span>;</span> Mecklenburg-Vorpommern<span>;</span> Sachsen<span>;</span>
Sachsen-Anhalt<span>;</span> Thuringen., has ballpark transformation
PROJ string:
+proj=pipeline
+step +proj=axisswap +order=2,1
+step +proj=unitconvert +xy_in=deg +xy_out=rad
+step +proj=push +v_3
+step +proj=cart +ellps=WGS84
+step +inv +proj=helmert +x=612.4 +y=77 +z=440.2 +rx=-0.054 +ry=0.057
+rz=-2.797 +s=2.55 +convention=position_vector
+step +inv +proj=cart +ellps=bessel
+step +proj=pop +v_3
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel
+step +proj=axisswap +order=2,1
</pre>
<pre><span style="font-family:arial,sans-serif">I think that the reason is that they deprecated the transformations EPSG:9925 'ETRS89 to DHHN2016 height (1)' and EPSG:9926 'ETRS89 to ETRS89 + DHHN2016 height (1)',
creating instead EPSG:10294 'ETRS89/DREF91/2016 to DHHN2016 height (1)' and EPSG:10295 'ETRS89/DREF91/2016 to </span><span style="font-family:arial,sans-serif">ETRS89/DREF91/2016</span><span style="font-family:arial,sans-serif"> + DHHN2016 height (1)'.
I have not found any transformation from WGS84 or ETRS89 to </span><span style="font-family:arial,sans-serif">ETRS89/DREF91/2016, only 'ETRS89/DREF91/2016 to ETRF2000 (1)', that is not very useful I guess.
The PRs that update the DB: <a href="https://github.com/OSGeo/PROJ/pull/3643/files" target="_blank">https://github.com/OSGeo/PROJ/pull/3643/files</a> , <a href="https://github.com/OSGeo/PROJ/pull/3646/files" target="_blank">https://github.com/OSGeo/PROJ/pull/3646/files</a></span></pre>
<pre><span style="font-family:arial,sans-serif">(I don't know why I cannot find the transformation EPSG:9925 in <a href="http://epsg.org" target="_blank">epsg.org</a>, asking to include deprecated entries)
</span></pre>
<pre><span style="font-family:arial,sans-serif">What can I do to perform the transformation from EPSG:4979 to EPSG:31468+7837 as in PROJ 9.2.0?
</span></pre>
<pre><span style="font-family:arial,sans-serif">Thanks.
</span></pre>
</div>
</div>
</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>.___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ...
.... ._ .__</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
PROJ mailing list
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a>
</pre>
</blockquote>
<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>