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