[PROJ] Problems with last EPSG update in Germany

Javier Jimenez Shaw j1 at jimenezshaw.com
Tue May 2 09:45:29 PDT 2023


Hi

When I was going to add the Helmert transformation, I realized that there
is already something similar in proj.db:
PROJ:ETRS89_TO_ETRF2000 "ETRS89 to ETRF2000" , with all zeros.

However, if I try to go from ETRS89 (via ETRF2000) to "DHDN + DHH2016
height" it has the same output: horizontal (to DHDN, that is the big chunk)
or vertical, not both.
(There is already a transformation in proj.db: EPSG:10292
'ETRS89/DREF91/2016 to ETRF2000 (1)')

PROJ_NETWORK=ON projinfo -s EPSG:4937 -t EPSG:4314+7837 -o proj
--spatial-test intersects
Candidate operations found: 11
-------------------------------------
Operation No. 1:

unknown id, Inverse of Ballpark geographic offset from ETRS89/DREF91/2016
to ETRS89 + ETRS89/DREF91/2016 to DHHN2016 height (1) + Inverse of Ballpark
geographic offset from DHDN to ETRS89/DREF91/2016, 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=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 2:

unknown id, Inverse of Null geographic offset from ETRS89 (geog2D) to
ETRS89 (geog3D) + ETRS89 to ETRF2000 + Inverse of Conversion from ETRF2000
(geocentric) to ETRF2000 (geog2D) + Inverse of ETRS89/DREF91/2016 to
ETRF2000 (1) + Inverse of Conversion from ETRS89/DREF91/2016 (geog3D) to
ETRS89/DREF91/2016 (geocentric) + ETRS89/DREF91/2016 to DHHN2016 height (1)
+ Inverse of Ballpark geographic offset from DHDN to ETRS89/DREF91/2016,
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 +proj=cart +ellps=GRS80
  +step +inv +proj=helmert +x=0 +y=0 +z=0 +rx=0.000658 +ry=-0.000208
+rz=0.000755
        +s=0 +convention=position_vector
  +step +inv +proj=cart +ellps=GRS80
  +step +inv +proj=vgridshift +grids=GCG2016.txt +multiplier=1
  +step +proj=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 3:

unknown id, Inverse of Transformation from DHHN2016 height to ETRS89
(ballpark vertical transformation, without ellipsoid height to vertical
height correction) + Inverse of DHDN to ETRS89 (8), 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=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------


If I use directly ETRF2000 instead of ETRS89, similar. It is not applying
vertical and horizontal transformations together.

PROJ_NETWORK=ON projinfo -s ETRF2000 -t EPSG:4314+7837 -o proj
--spatial-test intersects
Candidate operations found: 11
-------------------------------------
Operation No. 1:

unknown id, Inverse of Ballpark geographic offset from ETRS89/DREF91/2016
to ETRF2000 + ETRS89/DREF91/2016 to DHHN2016 height (1) + Inverse of
Ballpark geographic offset from DHDN to ETRS89/DREF91/2016, 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=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 2:

unknown id, Inverse of Conversion from ETRF2000 (geocentric) to ETRF2000
(geog3D) + Inverse of ETRS89/DREF91/2016 to ETRF2000 (1) + Inverse of
Conversion from ETRS89/DREF91/2016 (geog3D) to ETRS89/DREF91/2016
(geocentric) + ETRS89/DREF91/2016 to DHHN2016 height (1) + Inverse of
Ballpark geographic offset from DHDN to ETRS89/DREF91/2016, 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 +proj=cart +ellps=GRS80
  +step +inv +proj=helmert +x=0 +y=0 +z=0 +rx=0.000658 +ry=-0.000208
+rz=0.000755
        +s=0 +convention=position_vector
  +step +inv +proj=cart +ellps=GRS80
  +step +inv +proj=vgridshift +grids=GCG2016.txt +multiplier=1
  +step +proj=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------
Operation No. 3:

unknown id, Inverse of Transformation from DHHN2016 height to ETRF2000
(ballpark vertical transformation, without ellipsoid height to vertical
height correction) + Inverse of ETRS89 to ETRF2000 + Inverse of DHDN to
ETRS89 (8), 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=unitconvert +xy_in=rad +xy_out=deg
  +step +proj=axisswap +order=2,1

-------------------------------------

I was not expecting that. Am I missing anything?

Thanks,
Javier


On Sat, 29 Apr 2023 at 20:31, Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 29/04/2023 à 19:58, Javier Jimenez Shaw a écrit :
> > 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?
>
> Yes that also crossed through my mind. I believe it should work (but
> beware of the limitations of PROJ inference logic of guessing at most a
> single intermediate CRS, but for doing WGS84 -> ETRS89 ->
> ETRS89/DREF91/2016, that should work). You might simulate that
> beforehand by creating such a Helmert transformation.
>
>
> --
> 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/20230502/620957d9/attachment.htm>


More information about the PROJ mailing list