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

Greg Troxel gdt at lexort.com
Tue Mar 31 09:05:35 PDT 2020


Even Rouault <even.rouault at spatialys.com> writes:

> 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.

> 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.

It seems the crucial point is whether one intends

  to refer to a particular CRS, by just the codepoint, and therefore use
  the most precise transform, following modern best practices, or

  to refer sort of to a particular CRS, but with an inline definition of
  it (the towgs84 params) to be used instead of the modern normal way

That second method is not even what I think was ever really intended by
most, but an artifact of how it was intended to be.

So I would be inclined to ignore the towgs84 parameters when reading a
CRS, if the codepoint is in the current database, unless an option has
been given stating they should be used.

I can see what you are saying about insisting that the towgs84 values
are the standard ones in order to ignore them, but it also seems like a
file with a crs codepoint and other towgs84 values is broken.   I would
think it's better to allow it to be edited to change the CRS reference
to note that it's custom, since such a file isn't really using the
stated CRS.

Matching and skipping also feels fragile, rather than not using and
having people that want to use them have to be explicit.


More information about the gdal-dev mailing list