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 <[email protected]> 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 <[email protected]> > 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 >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
