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
