edzer / sp

Classes and methods for spatial data
http://edzer.github.io/sp/
127 stars 27 forks source link

Sp210 ready for submission shortly #138

Closed rsbivand closed 1 year ago

rsbivand commented 1 year ago

This strips out rgdal, rgeos and maptools, leaving exported get/set_evolution_status as noops (needed by several packages that use them https://github.com/r-spatial/evolution/blob/main/pkgapi_230811.csv lines 97 and 138 (inlabru plus some not seen by pkgapi)).

For present CRAN packages, CoordinateCleaner and LabourMarketAreas fail. CoordinateCleaner is https://github.com/ropensci/CoordinateCleaner/issues/78 and the new_spatial branch pass CMD check with this 2.1-0 with or without retiring packages on the library path. LabourMarketAreas is harder, I've been in email contact, but it pkgapi-uses: maptools::unionSpatialPolygons rgdal::readOGR rgdal::writeOGR rgeos::gArea rgeos::gIntersection. Last email 26 July: "this is a little update on the situation of the package LabourMarketAreas w.r.t. spatial packages. We have updated the package but, before uploading it to Cran, we would like to update the vignette as well. This will be done after the holydays. I will let you know as soon as the upload has been finalised."

In addition, Iñaki would like 2.1-0 on CRAN (well) before 3 October, "I believe there's margin to land sp 2.1 in the final freeze (Oct 3)" (for F39). Then F39 will have sp released from rgdal etc., and will drop retiring packages.

R-universe https://github.com/r-universe-org/help/issues/286#issuecomment-1684884655 should be OK, but I'll declare specific dates when we know them.

Debian will be problematic, but there isn't too much we can do about that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049438

I've also added GridsDatums to sp/data to keep it around when rgdal is gone.