[gdal-dev] gdalwarp and gdaltransform are inconsistent

[Even Rouault]

On lundi 20 avril 2020 01:08:15 CEST jratike80 wrote:
> Hi,
> 
> When it comes to gdalwarp I believe that this part of the documentation
> https://gdal.org/programs/gdalwarp.html is essential
> 
> "Starting with GDAL 2.2, if the SRS has an explicit vertical datum that
> points to a PROJ.4 geoidgrids, and the input dataset is a single band
> dataset, a vertical correction will be applied to the values of the
> dataset."
> 
> Both EPSG:4326 and EPSG:2056 are 2D systems without explicit vertical datum.
> EPSG:4979 is explicit 3D
> http://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4979 and
> the compound crs syntax that you used (-s_srs EPSG:2056+5728) is explicit as
> well.
> 
> I do not know how gdaltransform knows to do the conversion in Z coordinate

As this is with GDAL 2, and likely PROJ 4 or 5, this was a change in ellipsoidal height between 
the WGS84 and Bessel 1841 ellipsoids, but this was highly questionable, and is no longer 
done in GDAL 3 / PROJ >= 6, at least when using 2D codes.

> and how to give the -s_srs and -t_srs right for gdalwarp but I would try
> next with
> -s_srs EPSG:2056+5728 -t_srs epsg:4979

The change in Z done in gdalwarp requires:
- single band dataset
- input CRS is a geographic 3D CRS and output CRS is compound CRS (horizontal CRS + 
vertical CRS) with an explicit +geoidgrids term (or the reverse). The key here would be to 
have a vertical grid for EPSG:5728. I don't see any mentionned in EPSG. 

So provided that such grids is available, EPSG:2056+5728 would have to be replaced by 
"+init=epsg:2056 +geoidgrids=XXXXXX.gtx"

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/20200420/97da3292/attachment.html>