[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