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

[Grégory Bataille]

Hey Even,

So I can confirm that this is the issue
On Mac
OGRCT: Selecting transformation +proj=pipeline +step +proj=axisswap
+order=2,1 +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000
+y_0=0 +ellps=bessel +step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1 (Inverse of 3-degree Gauss-Kruger zone 4 + DHDN
to WGS 84 (2) + Inverse of Transformation to WGS84)

On my linux docker
OGRCT: Selecting transformation +proj=pipeline +step +proj=axisswap
+order=2,1 +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000
+y_0=0 +ellps=bessel +step +proj=hgridshift +grids=BETA2007.gsb +step
+proj=push +v_3 +step +proj=cart +ellps=WGS84 +step +inv +proj=helmert
+x=598.1 +y=73.7 +z=418.2 +rx=0.202 +ry=0.045 +rz=-2.455 +s=6.7
+convention=position_vector +step +inv +proj=cart +ellps=bessel +step
+proj=pop +v_3 +step +proj=unitconvert +xy_in=rad +xy_out=deg +step
+proj=axisswap +order=2,1 (Inverse of 3-degree Gauss-Kruger zone 4 + DHDN
to WGS 84 (4) + Inverse of Transformation to WGS84)

Now this is a problem to me and I don't quite know what to do with it.

So I have a fully specified dataset, that gives a TOWGS84, that my user has
chosen (properly or not)
Once the dataset is using this representation, I can't have auto projection
because those will/might depend on the application using the dataset.
Currently (most of) my backend processes are in Gdal3 / Proj6 and therefore
(per my understanding), the TOWGS84 might be overriden
However my front end processes only have some proj4 equivalence and will
trust exactly the dataset.

I'm a bit at a loss to know what I should do.
Should I do a gdalwarp step for gdal to "chose" the best projection and get
a new dataset (with another TOWGS84) that I use internally for alignment,
while giving the client the one he has asked for when he wants to get the
raw dataset?

Do you have any ideas/recommandations? Is there a way to disable the PROJ6
auto-selection feature?

Thanks

---
Gregory Bataille


On Fri, Nov 8, 2019 at 12:36 PM Grégory Bataille <gregory.bataille at gmail.com>
wrote:

> 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/20191113/84a22337/attachment-0001.html>