[PROJ] Problems with last EPSG update in Germany
Javier Jimenez Shaw
j1 at jimenezshaw.com
Sat Apr 29 10:58:04 PDT 2023
Thanks Even.
Yes, I will contact BKG.
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
https://epsg.org/transformation_9703/ETRF2000-PL-to-ETRS89-1.html for
Poland. (https://epsg.org/search/by-name/?query=ETRF2000-PL sounds very
similar to
https://epsg.org/search/by-name?searchedTerms=ETRS89%2FDREF91%2F2016 but
without that "link" to the "old" systems).
What do you think about this? Would it work?
Thanks.
On Sat, 29 Apr 2023 at 19:03, Even Rouault <even.rouault at spatialys.com>
wrote:
> 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, 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 listPROJ at lists.osgeo.orghttps://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/5d44bf5b/attachment.htm>
More information about the PROJ
mailing list