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

[Roger Bivand]

And this link explains the CDN proposal for grid distribution:

https://www.spatialys.com/en/crowdfunding/

Roger

On Wed, 13 Nov 2019, Roger Bivand wrote:

> 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