[R-sig-Geo] sp/rgdal workflows with PROJ >= 6 and GDAL >= 3

[Roger Bivand]

Because PROJ >= 6 and GDAL >= 3 change the way that PROJ strings 
(representations of coordinate reference systems) are handled, steps are 
being taken to find ways to adapt sp/rgdal workflows. A current proposal 
is to store the WKT2_2018 string as a comment to CRS objects as defined in 
the sp package.

A draft development-in-progress version of rgdal is available at 
https://r-forge.r-project.org/R/?group_id=884, and for sp at 
https://github.com/rsbivand/sp (this version of sp requires rgdal >= 
1.5-1). This adds the WKT comments to CRS objects on reading vector and 
raster data sources, and uses WKT comments if found when writing vector 
and raster objects (or at least does as far as I've checked, possibly 
fragile).

An RFC with tersely worked cases for using CRS object comments to carry 
WKT strings but maintaining full backward compatibility is online at 
http://rgdal.r-forge.r-project.org/articles/PROJ6_GDAL3.html.

If you have other ideas or concerns about trying to use this mechanism for 
sp CRS objects, please contribute at your earliest convenience.

http://rgdal.r-forge.r-project.org/reference/list_coordOps.html shows the 
beginning of the next step, to query transformation operations to find 
viable coordinate operation pipelines.

I'm assuming that the previous behaviour (transform without considering 
accuracy with whatever is to hand) is not viable going forward, and that 
we will need two steps: list coordinate operations between source and 
target CRS (using the WKT comments as better specifications than the PROJ 
strings), possibly intervene manually to install missing grids, then 
undertake the coordinate operation.

The fallback may be simply to choose the least inaccurate available 
coordinate operation, but this should be a fallback. This means that all 
uses of spTransform() will require intervention.

Is this OK (it is tiresome but modernises workflows once), or is it not OK 
(no user intervention is crucial)?

These behaviours may be set in an option, so that package maintainers and 
users may delay modernisation, but all are undoubtedly served by rapid 
adaptation (GRASS 7.8.1 released yesterday, libspatialite, pyproj, QGIS 
development versions all state that they list candidate coordinate 
operations).

We cannot ship all the grids, they are very bulky, and probably nobody 
needs sub-metre accuracy world-wide. Work in PROJ is starting to create a 
content delivery network for trusted download and mechanisms for 
registering downloaded grids on user platforms. We would for example not 
want Windows users of rgdal and sf to have to download the same grid 
twice.

Comments welcome here and at 
https://github.com/r-spatial/discuss/issues/28 or 
https://github.com/r-spatial/sf/issues/1187

Roger

-- 
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 using nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en