[gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

[Roger Bivand]

On Thu, 7 Nov 2019, Nyall Dawson wrote:

> On Wed, 30 Oct 2019 at 06:16, Even Rouault <even.rouault at spatialys.com> wrote:
>>
>>> I realise this too, but to permit legacy results to be replicated,
>>
>> Some legacy behaviour was just plain wrong/inaccurate. Trying to 
>> replicate it in PROJ would be heartbreaking, an extra maintaince 
>> burden, and a confusion for PROJ users because depending on the path 
>> they take, they would get different results.
>>
>> Not-so-random example with GDAL 2.4/PROJ 5 with GDA94 to GDA2020
>>
>> You get a ~1.5 metre shift to the north east as expected.
>
> This thread has been bouncing around in my mind for the last week. 
> Forgive me if I'm misinterpreting the situation, but wouldn't you 
> explicitly want legacy results NOT to be reproducible in cases where 
> proj 6's more accurate transformation capabilities have affected these 
> results?

Thanks for contributing! In research reproducibility, being able now to 
get the same results as when the research was conducted using the same 
software is basic. However, when the "same software" - including calls to 
metadata like EPSG descriptions - is no longer the "same", we need to be 
careful. I agree that wanting to flag and accept situations in which 
subsequent versions of apparently the same software yield different and 
more "precise" outcomes is reasonable.

A specific issue with GDAL 3 using PROJ 6 is that exportToProj4() drops 
keys like +datum=. In R packages, Proj4 strings have been used since the 
beginning (early 2000s) to attach CRS information to spatial objects. When 
(justifiably) +datum= is deprecated, users suddenly and without warning go 
from legacy precision to ballpark only, so worse by two orders of 
magnitude on transformation (because the source object CRS description is 
degraded).

We are now scrambling to add WKT2_2018 as a string representation on read 
and for write, because unlike exportToProj4(), exportToWkt() does preserve 
datum specifications. For those interested, the rgdal package on R-Forge 
(development, unstable) now piggy-backs WKT2 as a comment on sp CRS 
objects for reading or writing vector and raster files, using WKT2 rather 
than Proj4 strings if available. Next steps are to adapt coordinate 
operations to use WKT2 CRS descriptions rather than Proj4 strings for 
coordinate operations, including adding choices of pipelines and 
on-the-fly downloading of grids further ahead.

>
> If a particular study isn't affected by relatively small shifts such as 
> the 1.5m shift in the GDA2020 situation, then the results should remain 
> reproducible even if this shift is corrected. But if a particular study 
> IS affected by distances of this magnitude then I'd argue that it would 
> be vital that the older proj behavior can't be reproduced exactly, and 
> accordingly the previous study/results are invalidated as a direct 
> result..!

The negative outcomes are rather because say +datum= did a reasonable job 
before GDAL 3, but with GDAL 3 and the deletion of tags (+datum= is gone, 
+towgs84= and +init= are vulnerable and should be avoided), outcomes in 
GDAL3/PROJ6 are much worse (justifiably so) than GDAL2/PROJ5.

I think adaptation of R packages to modern PROJ/GDAL is feasible, and 
enough progress has been made to make me a bit more comfortable. See also 
coments by Markus Metz for GRASS and Mike Sumner (R, special interest in 
the Antarctic); I've benefitted also from reading the Cython code in 
pyproj (Alan Snow has posted here too - thanks!).

Roger

>
> Nyall
>
>
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en