[gdal-dev] Source SRS is a compound CRS but lacks +geoidgrids

Even Rouault even.rouault at spatialys.com
Tue Jun 16 14:44:59 PDT 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200616/028e32ff/attachment.html>


More information about the gdal-dev mailing list