[gdal-dev] Discrepancy when tiling on MAC and Linux

[Grégory Bataille]

That’s a problem for us. With gdal 3 we started to force values for the
towgs84 so that proj would not decide.
This is wanted because our front end will place markers and it does
coordinates transform. Without access to proj 6. Meaning it needs to have
the transform Value.

I’ll check what you mentioned (on Monday though I think)

Thanks for having a look

Greg

On Fri, 8 Nov 2019 at 12:30, Even Rouault <even.rouault at spatialys.com>
wrote:

> On vendredi 8 novembre 2019 08:18:11 CET Grégory Bataille wrote:
> > Hey all,
> >
> > So I have a strange issue that I somewhat isolated, but I don't know how
> to
> > move further.
> > I have dataset in EPSG 31468-15949
>
> I would check if that wouldn't be related to availability of the
> BETA2007.gsb
> grid. osgeo/gdal:alpine-normal-3.0.2 has it. Does your MAC install have it
> ?
>
> That said, your TIFF file has a hardcoded TOWGS84=598.1,73.7,418.2,0.202
>
> ,0.045,-2.455,6.7 . When using
>
> gdalwarp Investigation_tile_alignment/ClippedProject.tif out.tif
> -overwrite -
> t_srs EPSG:4326 --debug on
>
> I see locally that BETA2007.gsb is used. This is not so bad, but a bit
> unexpected since I'd thought that forced TOWGS84 would have take the
> precedence.
>
> Checking further in ogrct.cpp, I see that as the GeoTIFF has also the EPSG:
> 31468 code, and when instanciating the PROJ coordinate transformation,
> this is
> the preferred initializer, and thus the hardcoded TOWGS84 is ignored. So
> this
> explains what I observe. I'm not completely clear of what would be the
> desired
> behaviour here. In some use cases, one might prefer to honour the possibly
> suboptimal TOWGS84 from the geotiff info (the simple fact of doing
> gdal_translate -a_srs EPSG:31468 hardcodes it. Even with GDAL 3, which is
> probably no longer a good idea...). In other cases, just trust PROJ to use
> the
> best transformation method.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-- 
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191108/c1c03603/attachment.html>