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.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
