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 <[email protected]> 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 <[email protected]> > 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. > >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
