[PROJ] Problems with last EPSG update in Germany
Javier Jimenez Shaw
j1 at jimenezshaw.com
Mon May 8 02:50:54 PDT 2023
Thanks Even
Finally I am patching the db to "undeprecate" the transformation EPSG:9925,
with a worse accuracy. It produces the same outputs as 9.2.0.
Let's see what can we conclude with BKG/AdV about it.
Cheers,
Javier
On Tue, 2 May 2023 at 19:12, Even Rouault <even.rouault at spatialys.com>
wrote:
> 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/20230508/d0957eba/attachment.htm>
More information about the PROJ
mailing list