Preparing CRAN for the retirement of rgdal, rgeos and maptools

evolution Preparing CRAN for the retirement of rgdal, rgeos and maptools The functionality of “rgdal”, “rgeos” and “maptools” has been largely superse

Information

Category: Python / Data Visualization
Watchers: 8
Star: 6
Fork: 0
Last update: Jan 9, 2022

Resource links

https://github.com/r-spatial/evolution

README
Issues 5

evolution

Preparing CRAN for the retirement of rgdal, rgeos and maptools

The functionality of “rgdal”, “rgeos” and “maptools” has been largely superseded by other, more modern packages like “sf”, “stars” and “terra”. Roger Bivand, co-applicant of this proposal, has retired early 2021. Roger currently maintains “rgdal”, “rgdal” and “maptools” but will stop maintaining these packages by the end of 2023. Simply withdrawing these packages from CRAN will have a strong effect on other CRAN package, as they have a large number of reverse dependencies. The Problem addressed in this ISC proposal is to make it possible for Roger Bivand to retire from maintaining “rgdal”, “rgeos'' and “maptools” while minimizing the disruption of CRAN packages and existing R scripts using these packages. This affects a large number of CRAN package maintainers, and a large number of users of all packages depending directly or indirectly on “rgdal”, “rgeos” or “maptools”. It simplifies maintenance of the “R Spatial stack”, and by that makes the CRAN ecosystem more robust.

1 Open More issues

Open

rgeos retirement

Hello,

First of all thanks a lot for creating and maintaining this package all these years. I'd appreciate it if you can guide me about alternative options for my case described below: I'm using sp package to define polygons, which are the boundaries around the cluster of points in 2D, and then gIntersects, gDifference,gBuffer, gUnion from rgeos mainly to do polygon manipulation (i.e., union, subtraction and intersection of two polygon), extracting the coordinates of the polygon from these functions, and then using point.in.polygon from sp to get indices of point inside the polygon.

I have part of my code here as well.

#filter1 and filter 2 are matrices of 2D coordinates
  poly1 <- sp::SpatialPolygons(list(sp::Polygons(list(Polygon(filter1)), ID=c("c"))))  
  poly2 <- sp::SpatialPolygons(list(sp::Polygons(list(Polygon(filter2)), ID=c("c"))))
  if(rgeos::gIntersects( poly1, poly2)){
    temp <-tryCatch(rgeos::gDifference(poly1,poly2), error=function(ex) return(1))
    if (mode(temp)=="numeric")
    {
      temp <- rgeos::gDifference(poly1,rgeos::gBuffer(poly2))
    }
    
    filter<[email protected][[1]]@Polygons[[1]]@coords
 }

Since I'm working with biological data, reproducibility is really important, and I'd like to avoid any discrepancy while moving from rgeos/sp to another package, so any help would be very much appreciated

opened Apr 24, 2022 by mehrnoushmalek 4

Open

Policy update?

In https://github.com/r-spatial/mapview/issues/418#issuecomment-1100818133, I suggest that:

It is likely that retirement will mean archiving the three packages at the latest ultimo 2023. Creating masking sequel packages creates more maintenance, so unless sp methods are involved, especially sp::spTransform(), the best solution is hard retirement. We'll know more by August this year.

Is this reasonable @edzer @rhijmans ?

I'd like to ask whether the next sp release should be from my evolution branch (by PR to the main repo)?

I'd also like to add deprecation to everything exported by maptools, rgeos and rgdal. However, the base::.Deprecated() function is not a good fit, so might it make sense to add a customised function to sp since maptools, rgeos and rgdal all depend on sp? The base function moves all the help pages to for example rgdal-deprecated, which seems too invasive at this stage. A deprecation note is more in-your-face than the package startup messages, but isn't yet a full warning triggering CRAN problems when warnings are converted to errors.

The results in #3 don't cover examples, vignettes, tests or demos, so adding output might add the required noise.

I'm also considering a blog based on the adaptations in the https://github.com/rsbivand/sf_asdar2ed repo; would this make sense?

opened Apr 19, 2022 by rsbivand 1

Open

Thread on finding functions used by revdep packages

https://stat.ethz.ch/pipermail/r-package-devel/2019q1/003590.html

using pkgapi.

opened Jan 31, 2022 by rsbivand 4

Open

PROJ/GDAL different treatment of deprecated CRS

see https://github.com/r-spatial/sf/issues/1885

opened Jan 14, 2022 by rsbivand 1

Open

Other connected repos

Some files moved from maptools: https://github.com/rsbivand/sp/tree/retiring and rgdal/rgeos/maptools removed from DESCRIPTION: currently broken, work-in-progress.

https://github.com/rsbivand/sf_asdar2ed ASDAR code to run without proxy but with sp retired branch, using sf instead of rgdal/rgeos/maptools, work-in-progress and needs sp::spTransform() to be rewritten to use sf::st_transform(), sp::CRS() to use sf::st_crs(). Much use of sf::st_as_sf() and coercion from "sf" to "Spatial". With comments suggests how sp workflows might continue without immediate full sf conversion.

One note for stars: coercion from multiband "stars" to "Spatial"seems to need tocbind()` each coerced array slice band separately.

Loose question - what about spacetime?

opened Jan 7, 2022 by rsbivand 2