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

[Patrick Young]

Thanks Even, really helpful!

Patrick

On Tue, Jun 16, 2020 at 3:45 PM Even Rouault <even.rouault at spatialys.com>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200616/36d5debe/attachment-0001.html>