[gdal-dev] Dealing with "default" TOWGS84 values

[Stephen Woodbridge]

Even,

Would it make sense to add an option to GDAL like -ignore-bound-towgs84 
or -use-bound-towgs84 depending on what the default behavior is set to?

This would allow the user to choose which is best for their data.

-Steve W

On 3/31/2020 10:21 AM, Even Rouault wrote:
>
> Hi,
>
> I wanted to get opinions on a topic related to TOWGS84 7-parameter 
> transforms. In the GDAL 1.x/2.x & PROJ 4.x/5.x era, having TOWGS84 
> values attached to CRS definitions was critical to get correct datum 
> transformation.
>
> Now, in the GDAL 3 + PROJ 6.x/7.x era, there are more an annoyance 
> than anything else, since they can prevent more accurate 
> transformations to be used.
>
> Some data formats such as GeoTIFF files written by GDAL 1.x/2.x encode 
> the TOWGS84 value of the CRS definition that was built when importing 
> the EPSG dataset. E.g 
> TOWGS84[446.448,-125.157,542.06,0.15,0.247,0.842,-20.489] for 
> EPSG:27700 OSGB 1936 / British National Grid
>
> In GDAL 3, when such file is read, a BoundCRS object is returned, that 
> is a CRS that has a base CRS (potentially with a EPSG code attached. 
> e.g EPSG:27700) + the definition of its transformation to WGS84 (which 
> corresponds to the transformation with larger area of use). Software 
> like QGIS will then use this BoundCRS (since that's what GDAL returns 
> for the dataset CRS) when reprojecting to a target CRS, which will 
> cause the TOWGS84 parameters from the file to be used (PROJ >= 6 will 
> honour the TOWGS84 parameters of a BoundCRS when transforming 
> from/into it), rather than potentially more accurate transformations 
> (typically grid based transformations) from the base CRS to the target 
> CRS.
>
> Whether this behaviour is a bug or a feature, and where this bug 
> belongs to, has been a debate in a number of tickets:
>
> https://github.com/OSGeo/gdal/issues/2219
>
> https://github.com/qgis/QGIS/issues/34993
>
> I wanted to have broader opinions regarding if we should do something 
> about that, and what.
>
> One possibility would be for GDAL to ignore the TOWGS84 value 
> associated with a base CRS if we detect that this TOWGS84 value is the 
> default one that was written by GDAL 1.x/2.x for this base CRS, and 
> thus to return just the base CRS, letting PROJ figure out all 
> potential transformations when transforming to a target CRS. This 
> could potentially be the default behaviour, with a configuration 
> option that could be set to opt for the current behaviour (that is 
> return the BoundCRS). This would have to be implemented per driver 
> (logic would be similar). I guess GeoTIFF, GPKG, Spatialite could be 
> candidates.
>
> The potential downside of this is if the user relied on those exact 
> default TOWGS84 values to be used when reprojecting to WGS84 (or when 
> using WGS84 as the pivot)
>
> I'd note that GDAL 3, in the OGRCoordinateTransformation code, 
> implements partially this logic, but only in the transformation code 
> (not impacting the CRS actually returned by the dataset), and with 
> limitations. That is when transforming from/into a BoundCRS whose 
> which has a unique Helmert transformation to WGS84 that matches the 
> transformation of the BoundCRS, it uses by default only the BaseCRS 
> (can be disabled with OSR_CT_USE_DEFAULT_EPSG_TOWGS84=YES). But this 
> is for example not sufficient for EPSG:27700, because it has several 
> Helmert transformations. So as suggested in 
> https://github.com/OSGeo/gdal/issues/2219, a broader fix would be for 
> the PROJ database to have a GDAL2 authority that would store the 
> TOWGS84 parameters historically used by GDAL 2.
>
> 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