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