[PROJ] Problems with last EPSG update in Germany
Even Rouault
even.rouault at spatialys.com
Sat Apr 29 10:03:02 PDT 2023
Javier,
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:
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.');
Either you locally patch your proj.db to set the deprecated flag of
EPSG:9925 and EPSG:9926 back to 0.
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.
Even
Le 29/04/2023 à 18:32, Javier Jimenez Shaw a écrit :
> Hi
>
> When doing transformations from WGS84 (or ETRS89) to "DHDN + DHHN2016
> height" in PROJ 9.2.0 (using a German geoid file), it works fine.
> However in master it is only doing the vertical part, producing an
> error of more than a hundred meters horizontally.
>
> I was going to open an issue, but then I realized that EPSG was
> recently updated, and maybe that is the reason.
>
> 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.
>
> (Note: BKG is working on releasing the German geoid model free. Let's
> see when it finally happens and the license they use.)
>
> In PROJ 9.2.0, the pipelines obtained with projinfo make sense to me,
> including both, horizontal and vertical operations:
> 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
>
> -------------------------------------
>
> However The pipelines in master do use the vertical or horizontal
> transformation, but not both:
> 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; Mecklenburg-Vorpommern; Sachsen;
> Sachsen-Anhalt; 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
>
>
> 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 ETRS89/DREF91/2016+ DHHN2016 height (1)'. I
> have not found any transformation from WGS84 or ETRS89 to
> ETRS89/DREF91/2016, only 'ETRS89/DREF91/2016 to ETRF2000 (1)', that is
> not very useful I guess. The PRs that update the DB:
> https://github.com/OSGeo/PROJ/pull/3643/files ,
> https://github.com/OSGeo/PROJ/pull/3646/files
> (I don't know why I cannot find the transformation EPSG:9925 in
> epsg.org <http://epsg.org>, asking to include deprecated entries)
> What can I do to perform the transformation from EPSG:4979 to
> EPSG:31468+7837 as in PROJ 9.2.0?
> Thanks.
> .___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... .... ._ .__
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20230429/9f3ee563/attachment-0001.htm>
More information about the PROJ
mailing list