[gdal-dev] gdalwarp and gdaltransform are inconsistent

[Pillio Zoltan]

Thank you for all your quick answer. So the conclusion is I need a geogrid
file to do it.

Even Rouault <even.rouault at spatialys.com> ezt írta (időpont: 2020. ápr.
20., H, 12:06):

> 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.
>

We checked with GDAL 3, and you rignt. And the reason why gdaltransform
result was close to the right value is because CHGeo2004 geoidal separation
was close to 0 at the checked point.


>
> > 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200420/332ce82d/attachment.html>