<div dir="ltr">Hey Even,<div><br></div><div>So I can confirm that this is the issue</div><div>On Mac</div><div>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)</div><div><br></div><div>On my linux docker</div><div>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)<br></div><div><br></div><div>Now this is a problem to me and I don't quite know what to do with it.</div><div><br></div><div>So I have a fully specified dataset, that gives a TOWGS84, that my user has chosen (properly or not)</div><div>Once the dataset is using this representation, I can't have auto projection because those will/might depend on the application using the dataset.</div><div>Currently (most of) my backend processes are in Gdal3 / Proj6 and therefore (per my understanding), the TOWGS84 might be overriden</div><div>However my front end processes only have some proj4 equivalence and will trust exactly the dataset.</div><div><br></div><div>I'm a bit at a loss to know what I should do.</div><div>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?</div><div><br></div><div>Do you have any ideas/recommandations? Is there a way to disable the PROJ6 auto-selection feature?</div><div><br></div><div>Thanks<br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div><font color="#999999">---</font></div><div><font color="#999999">Gregory Bataille</font><br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 12:36 PM Grégory Bataille <<a href="mailto:gregory.bataille@gmail.com">gregory.bataille@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">That’s a problem for us. With gdal 3 we started to force values for the towgs84 so that proj would not decide.</div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I’ll check what you mentioned (on Monday though I think)</div><div dir="auto"><br></div><div dir="auto">Thanks for having a look</div><div dir="auto"><br></div><div dir="auto">Greg</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Nov 2019 at 12:30, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On vendredi 8 novembre 2019 08:18:11 CET Grégory Bataille wrote:<br>
> Hey all,<br>
> <br>
> So I have a strange issue that I somewhat isolated, but I don't know how to<br>
> move further.<br>
> I have dataset in EPSG 31468-15949<br>
<br>
I would check if that wouldn't be related to availability of the BETA2007.gsb <br>
grid. osgeo/gdal:alpine-normal-3.0.2 has it. Does your MAC install have it ?<br>
<br>
That said, your TIFF file has a hardcoded TOWGS84=598.1,73.7,418.2,0.202           <br>
,0.045,-2.455,6.7 . When using<br>
<br>
gdalwarp Investigation_tile_alignment/ClippedProject.tif out.tif -overwrite -<br>
t_srs EPSG:4326 --debug on<br>
<br>
I see locally that BETA2007.gsb is used. This is not so bad, but a bit <br>
unexpected since I'd thought that forced TOWGS84 would have take the <br>
precedence.<br>
<br>
Checking further in ogrct.cpp, I see that as the GeoTIFF has also the EPSG:<br>
31468 code, and when instanciating the PROJ coordinate transformation, this is <br>
the preferred initializer, and thus the hardcoded TOWGS84 is ignored. So this <br>
explains what I observe. I'm not completely clear of what would be the desired <br>
behaviour here. In some use cases, one might prefer to honour the possibly <br>
suboptimal TOWGS84 from the geotiff info (the simple fact of doing <br>
gdal_translate -a_srs EPSG:31468 hardcodes it. Even with GDAL 3, which is <br>
probably no longer a good idea...). In other cases, just trust PROJ to use the <br>
best transformation method.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div></div>-- <br><div dir="ltr">Greg</div>
</blockquote></div>