[gdal-dev] Changes in SRS handling w.r.t TOWGS84

[Even Rouault]

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