Hi, Following a number of exchanges on the PROJ mailing list, related to PROJ 6 integration in QGIS, I've prepared a pull request changing a bit how we deal with the 'early-binding' TOWGS84 term in https://github.com/OSGeo/gdal/pull/2113
""" When importing from EPSG, GDAL 3.0.0 to 3.0.2 followed the scheme used in GDAL 1.x and GDAL 2.x, that is they tried to attach a TOWGS84 transformation. While the intent was to have some sort of backward compatibility, this may be a pain for the future. So do the following changes: - importFromEPSG(): no longer attach a TOWGS84 transformation, unless the user set the OSR_ADD_TOWGS84_ON_IMPORT_FROM_EPSG=YES configuration option Add a OGRSpatialReference::AddGuessedTOWGS84() to attach such a transformation, when possible (note: this will do it in a more prudent way than GDAL 1.x/2.x, that is only if a transformation is found for the whole area of use of the CRS) - exportToProj4(): if the SRS has no transformation to WGS84, attach a +towgs84 if the SRS has a EPSG code and AddGuessedToWGS84() succeeds. Can be disabled with the OSR_ADD_TOWGS84_ON_EXPORT_TO_PROJ4 = NO configuration option - exportToWkt() with WKT1 format: Add a OSR_ADD_TOWGS84_ON_EXPORT_TO_WKT1 = YES/NO configuration option, which defaults to NO. If set to YES, then a transformation to WGS84 using AddGuessedToWGS84() logic is researched to add a TOWGS84[] node. """ The aim is to avoid the propagation of potentially suboptimal TOWGS84 terms by default (except when exporting to PROJ4 string as we don't have a more expressive way of encoding datum information), which can be the source of later problems (not using grids when available due to this towgs84 being strictly honoured). I've a backport of this for the 3.0 branch ready, to go in the 3.0.3 release. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
