Thanks Even, really helpful! Patrick
On Tue, Jun 16, 2020 at 3:45 PM Even Rouault <[email protected]> wrote: > On mardi 16 juin 2020 15:17:54 CEST Patrick Young wrote: > > > Is this a special case for EPSG:5773, or is it a bad idea to express the > > > vertical datum via EPSG codes in general? > > > > This could go in a lengthy geodesy lesson, but bascially a CRS definition > and its transformation to another one are two separate concepts. PROJ < 6 > tended to blend them together, by including the transformation to WGS84 in > the CRS definition. For number of cases, this is accurate enough, but this > systematic use of WGS84 pivot is more and more wrong in a number of > situations, hence this is no longer used systematically in PROJ 6. PROJ < 6 > behaviour was a "early binding" (to WGS84), while PROJ 6 uses a "late > binding" approach where it might use a WGS84 pivot, or another one, or a > direct transformation when available > > > > Some details about that in: > > > http://download.osgeo.org/proj/presentations/PROJ%20CRS%20revamp%20(FOSS4G%202019).pdf > > > > So by adding +geoidgrids=egm96_15.gtx you force the geoid to be referenced > to WGS84. Which makes sense in this particular case, since indeed EGM96 > height has a transformation to WGS84, but not in the general case. > > > > The current approach used by gdalwarp to do those height correction is a > bit of a "hack". A more generalized approach would use PROJ capabilities to > compute the Z difference without GDAL to have to explicitly use the > geoidgrid. > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
