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

[Roger Bivand]

Even,

Thanks!

On Tue, 29 Oct 2019, Even Rouault wrote:

> Roger,
>
>> In looking at ways to adapt R packages rgdal and sf to current GDAL and 
>> PROJ, I have run into a problem. Many existing vector files (I have not 
>> yet looked at raster) include a datum declaration, which is still 
>> present internally in the OGRSpatialReference object, but is dropped in 
>> the output of exportToProj4().
>> [...]
>> Using GetAttrValue("DATUM"), I can alert users who bother to see 
>> warnings that something has happened requiring their attention, but am 
>> I missing a CPL option or other remedy already in place?
>
> No, you don't miss anything. PROJ 6 makes less efforts than previous 
> verions to export a +datum= string. This is more or less intended so 
> that people move away from PROJ strings to represent CRS because they 
> suffer from a number of limitations (its hardcoded list of datums is 
> very limited compared to what is available in EPSG, axis order issues, 
> etc.). That particular use case could potentially be improved as 
> +datum=OSGB36 is known of PROJ on the import side, but you'd get anyway 
> into troubles with other datums.

That was what I thought. Both sp (and rgdal which uses sp classes) and sf 
use proj strings to encode the CRS, but sf can alternatively use EPSG 
codes. I need to modify the sp class representation in a 
backwards-compatible way to let objects also have a CRS string such as 
"EPSG:4326", which then takes over responsibility.

But we need to provide pathways for other package developers depending 
on sp (about 500 packages) and sf (200), and packages using transformation 
(about 80), to feed through the need for end users to intervene manually. 
They'll need themselves to identify the URN or EPSG codes corresponding to 
the proj strings they are used to seeing, and add them to objects in the 
workflows. At least I have GetAttrValue("DATUM") to test whether a datum 
is being discarded.

The underlying problem is that users may face silent degradation in 
workflows as they upgrade sf and rgdal to PROJ >= 6 and GDAL >= 3 if they 
are not prompted to take remedial steps themselves. I realise that users 
have become too comfortable, but user guidance will be essential to avoid 
too much noise on SO, twitter, etc.

> If you use directly the WKT representation from this .prj file with PROJ 
> functions that deal with coordinate transformations (or the 
> OGRSpatialReference object with GDAL functions), things should work 
> smoothly.

WKT is not an option really, though users may wish to look at the WKT2 of 
an EPSG code. My attempts to feed WKT into importFromWkt() have failed so 
far, but that could be string handling (I'm treating the whole WKT block 
as a single text string).

>
>> Optional interpolation from GDALs gt_datum.csv or similar would perhaps 
>> help, inserting a +towgs84 tag, but I do not have a clear view how to 
>> make the migration process for users easier.
>
> The towgs84 concept is also a fragile and a limited one. There might be 
> several potential towgs84 transformations and this assumes you 
> transforms from/to WGS84. That said the method 
> OGRSpatialReference::importFromEPSG() will use internally 
> proj_crs_create_bound_crs_to_WGS84() to try finding a TOWGS84 transform. 
> But this will only work if there's a single candidate. In case of 
> multiple candidates, it will not select an artibtrary one like previous 
> GDAL / PROJ versions did.

I realise this too, but to permit legacy results to be replicated, it may 
be necessary to guide from +datum= to +towgs84= where +nadgrids= is not 
available. Grid handling may help, but we're likely to see trouble with 
dropped datum strings for some time (as long as R FAQ 7.31 [1]?), people 
do re-use older files.

Roger

[1]https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f

>
> Even
>
>

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