[PROJ] Problems with last EPSG update in Germany
Even Rouault
even.rouault at spatialys.com
Tue May 2 10:12:59 PDT 2023
Javier,
so for doing ETRF2000 <--> DHDN + DHHN2016 height
What exists as relevant transformations in proj.db:
ETRF2000 <--> ETRS89/DREF91/2016: Helmert
DHHN2016 height <--> ETRS89/DREF91/2016: grid
but nothing for ETRS89/DREF91/2016 <--> DHDN
I'm not sure if having such transformation would help (I guess so though)
The "ETRS89 to ETRF2000" null Helmert transformation inserted by PROJ
from the definition of the ETRS89 datum ensemble cannot help here,
because, yes, we can do the horizontal and vertical steps with:
ETRF2000 --> ETRS89/DREF91/2016 --> DHHN2016 height
ETRF2000 --> ETRS89 --> DHDN
but when combining them, we're stuck because the intermediate datum
(ETRS89/DREF91/2016 for vertical, ETRS89 for horizontal) isn't the same
(I guess having a known transformation could help, but I'm not sure)
And even if that worked, I don't think that could be used to do ETRS89
<--> DHDN + DHHN2016 height because of the too many inference steps
required.
Even
Le 02/05/2023 à 18:45, Javier Jimenez Shaw a écrit :
> 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.
>
--
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/80e4b0dc/attachment-0001.htm>
More information about the PROJ
mailing list