• sp evolution status
  • Use ofsp affected functions and methods
  • Possible difficulties
  • Why notterra?

[view rawRmd]

Summary:

This is the fourth report on the R-spatial evolution project and isaddressed to maintainers of packages and workflows usingsp classes,methods and functions. The project involves the retirement (archiving)ofrgdal,rgeos andmaptools during 2023. Thefirstreport set out themain goals of the project. Thesecondreport coveredprogress so far, steps already taken, and those remaining to beaccomplished. Thethird gavedetailed guidance for maintainers of packages using the retiringpackages.

From June 2023, the internal evolution status setting ofsp will bechanged from “business as usual” to “usesf instead ofrgdal andrgeos”. Packages depending onsp may need to addsf to their weakdependencies, and to monitor any changes in output.

The final step will occur during October 2023, in five months,rgdal,rgeos andmaptools will be archived on CRAN, and packages withstrong dependencies on the retiring packages must be either upgraded tousesf,terra or other alternatives or work-arounds by or beforethat time. Making all required changes in the period from now to theJunesp change will mean just one round of adaptations rather than tworounds.

Thisspreadsheetlists methods and functions in retiring packages andsp found bypkgapi. They are listed by function name as used by packages, and theanalogous list by package may be found of functions ishere.

sp evolution status

Repeating from the second and third blogs:

As mentioned in our first report,sp on CRAN has been provided withconditional code that preventssp calling most code inrgdal orrgeos. This can be enabledbefore loadingsp by setting e.g.:

options("sp_evolution_status"=2)library(sp)

for checking packages under status

• 0: business as usual,
• 1: stop ifrgdal orrgeos are absent, or
• 2: usesf instead ofrgdal (currently no use ofrgeos isconsidered)

or alternatively can be set as an environment variable read whensp isloaded, e.g. when running checks from the command line by

_SP_EVOLUTION_STATUS_=2 R CMD check

This construction should permit maintainers to detect potential problemsin code.devtools::check() provides theenv_vars= argument, whichmay be used for the same purpose.

Fromsp 1.6.0 published on CRAN 2023-01-19, these status settings mayalso be changed whensp is loaded, usingsp::get_evolution_status()returning the current value, andsp::set_evolution_status(value),where value can take the integer values0L,1L and2L.

Use ofsp affected functions and methods

Under evolution status2, which will become the default in June 2023,no use is made ofrgdal insp::CRS,sp::is.projected, andsp::spTransform, rather usingsf to accessPROJ throughGDAL. Awarning is given ifsf is not available. This is similar to behaviourunder legacysp and evolution status0 with regard to the use ofrgdal to accessPROJ.

sp::CRS is used by the following packages (pkgapi May 2, 2023):

adehabitatHR adehabitatHS adehabitatLT adehabitatMA AFM AGPRIS angstromsanimaltracker anipaths antaresViz aqp AquaBEHER atakrig ausplotsR bamlss bfsMaps biogeo bioRad biosurvey birdring birdscanR bivariatemaps bRacatus briskaR canadianmaps changeRangeR chronosphere cleangeo cmsafops cmsafvis ConR CoordinateCleaner cruts ctmm dartR DEPONS2R dggridR dismo dispeRse DRHotNet dtwSat dynamAedes dynamicSDMecospat elevatr EMbC epitweetr fasterize FIESTAutils FLightR FRK GapAnalysis gDefrag gdistance GeNetIt GeoAdjust GeodesiCL geodiv geofacet geogrid geojsonio geomerge geoviz gfcanalysis ggOceanMaps gmGeostats googletraffic GPSeqClus grainscape graticule gwer gwfa hero Hmsc hydroTSM iccTraj inlabru INLAspacetime intamap intSDM IsoriX itcSegment kehra lakemorpho leaflet letsR lgcp loa macroBiome mapedit MapGAM mapmisc mapview MEDITS meteo meteoForecast meteoland micromapST MinBAR momentuHMM morphomap move nodiv oceanic OpenStreetMap OSMscale phyloregion places plotKML prevR PWFSLSmokeQRAGadget quadmesh quickmapr quickPlot RAC raster rasterVis rbgm rcanvec rCAT RCGLS RchivalTag rcrimeanalysis ReadDIM red RgoogleMaps riverdist rleafmap rosm rpostgis RSIP rtop RWmisc sdm sdStaf SeerMapper seg shadow SimSurvey soilassessment SongEvo spacetimeSpaDES.tools SpatialEpi spatialfusion SpatialGraph spatsoc spatsurv spbabel spdep sperich spex spgwr stppSim stxplore SUNGEO SurfaceTortoise SWTools tiler track2KBA TrajDataMining trajectories trip uavRmp vec2dtransf waver WEGE wildlifeDI wkb wux zoon

sp::is.projected is used by:

GapAnalysis GeNetIt intkrige ptools riverdist surveillance track2KBA trip

andsp::spTransform by:

AGPRIS antaresViz biosurvey bivariatemaps canadianmaps chronosphere CoordinateCleaner ctmm elevatr epitweetr fastmaRching FLightR GeoAdjust GeodesiCL geoviz ggOceanMaps icosa inlabru INLAspacetime loa macroBiome mapedit mapview micromapST MinBAR momentuHMM mregions quickmapr raster rcanvec rcrimeanalysis reproducible RgoogleMaps riverdist rosm rpostgisSeerMapper shadow SUNGEO track2KBA uavRmp

Reverse dependency checks of May 4, 2023 showed only 2 packages failingCMD check under_SP_EVOLUTION_STATUS_=2, and their difficulties arementioned below (github issues have been raised offering maintainersmitigations). The salient reasons are given below so that others facingsimilar apparent intractible problems in workflows can perhaps benefit.Since other packages passedCMD check, there are no strong reasons notto flipsp’s evolution status in June 2023 fromrgdal tosf.

Possible difficulties

One possible source of difference is that the strings (WKT2_2019,Proj4) returned fromrgdal came straight fromPROJ, butsfaccessesPROJ throughGDAL.

Another source of difference is thatrgdal usedsp S4 classes withinheritance, butsf uses S3 classes which do not (seem to) treatinheritance in the same way. So workflows usingsp and classes, socoercion tosp classes beforesp::spTransform is required, andreconstruction of the classes extendingsp classes after return isprobably required.

A further potential cause of confusion is that round-tripping bycoercion tosf perhaps applying an operation, and returning tospmay break rarely usedsp methods, such as:

library(sp)getMethod("$", "SpatialPoints")Method Definition:function (x, name) {    if (name %in% coordnames(x))         return(x@coords[, name])    if (!("data" %in% slotNames(x)))         stop("no $ method for object without attributes")    x@data[[name]]}<bytecode: 0x5581566f5a68><environment: namespace:sp>Signatures:        x              target  "SpatialPoints"defined "SpatialPoints"

which accesses columns by name no longer in thedata.frame in the dataslot through the column names of the matrix of points:

data(meuse)names(meuse) [1] "x"       "y"       "cadmium" "copper"  "lead"    "zinc"    "elev"    [8] "dist"    "om"      "ffreq"   "soil"    "lime"    "landuse" "dist.m" coordinates(meuse) <- ~ x + ynames(meuse) [1] "cadmium" "copper"  "lead"    "zinc"    "elev"    "dist"    "om"      [8] "ffreq"   "soil"    "lime"    "landuse" "dist.m" colnames(slot(meuse, "coords"))[1] "x" "y"str(meuse$x) Named num [1:155] 181072 181025 181165 181298 181307 ... - attr(*, "names")= chr [1:155] "1" "2" "3" "4" ...

So far so good, but round-tripping changes the column names of thematrix of points:

meuse_rt <- as(sf::st_as_sf(meuse), "Spatial")names(meuse_rt) [1] "cadmium" "copper"  "lead"    "zinc"    "elev"    "dist"    "om"      [8] "ffreq"   "soil"    "lime"    "landuse" "dist.m" colnames(slot(meuse_rt, "coords"))[1] "coords.x1" "coords.x2"

Consequently, code using this legacy short cut may be a source ofdifficulty.

Why notterra?

The reason for choosing to replacergdal bysf for these threemethods has been the absence of an independent object for coordinatereference systems matching"CRS" insp and"crs" insf.

It would be possible to create an empty"SpatVector" object and assigna coordinate reference system, coerce tosp, and extract the"CRS"object:

v <- terra::vect(matrix(c(0, 0), nrow=1), crs="OGC:CRS84")library(raster)slot(as(v, "Spatial"), "proj4string")Coordinate Reference System:Deprecated Proj.4 representation: +proj=longlat +datum=WGS84 +no_defs WKT2 2019 representation:GEOGCRS["unknown",    DATUM["World Geodetic System 1984",        ELLIPSOID["WGS 84",6378137,298.257223563,            LENGTHUNIT["metre",1]],        ID["EPSG",6326]],    PRIMEM["Greenwich",0,        ANGLEUNIT["degree",0.0174532925199433],        ID["EPSG",8901]],    CS[ellipsoidal,2],        AXIS["longitude",east,            ORDER[1],            ANGLEUNIT["degree",0.0174532925199433,                ID["EPSG",9122]]],        AXIS["latitude",north,            ORDER[2],            ANGLEUNIT["degree",0.0174532925199433,                ID["EPSG",9122]]]]

but this seems somewhat forced. If there is substantial demand for analternative mechanism usingterra andraster in place ofsf, thena well-tested pull request would be considered. It is understandablethat Windows or macOS users who otherwise would not need to installsf, and who are already usingterra might prefer to stay withterra insidesp, but input to the evolution project would be neededto take any action. It may rather be simpler for users with suchworkflows to migrate toterra instead of sustaining a mixedsp,raster vector combination whenterra can probably cover all needs.