dependency on retiring spatial infrastructure packages

[rsbivand]

You will be aware, for example from:
https://r-spatial.org/r/2022/04/12/evolution.html,
https://r-spatial.org/r/2022/12/14/evolution2.html,
https://r-spatial.org/r/2023/04/10/evolution3.html and
https://rsbivand.github.io/csds_jan23/bivand_csds_ssg_230117.pdf and
perhaps view https://www.youtube.com/watch?v=TlpjIqTPMCA&list=PLzREt6r1NenmWEidssmLm-VO_YmAh4pq9&index=1
that rgdal, rgeos and maptools will be retired this
year, in October 2023.

spatsoc imports 'rgeos' using rgeos::gArea rgeos::gBuffer rgeos::gIntersection rgeos::gIntersects as found by pkgapi, not in NAMESPACE, in R/group_lines.R and R/group_polys.R. From https://r-spatial.org/r/2023/04/10/evolution3.html and linked documents, you can see that sf and terra offer alternatives, and coercion methods to and from sp classes. Please fix best by June, latest October 2023.

[robitalec]

Thank you.

spatsoc has a direct dependency on rgeos, and indirect dependencies on maptools and rgeos through adehabitatHR. I'm grateful the developer of adehabitatHR has recently removed its dependencies on these deprecated spatial packages (ClementCalenge/adehabitatHR@5c5c4ad). I will update this issue as soon as possible with progress on replacing rgeos with functions from sf.

[rsbivand]

@robitalec See also https://r-spatial.org/r/2023/05/15/evolution4.html. Please take urgent steps to resolve this issue. No positive changes appear in the repository. Less than three months remain to retain this package on CRAN.

[robitalec]

Searching the repository for sp, we find a dependency on functions sp::CRS, sp::SpatialLines, sp::Lines, sp::Line, sp::rbind.SpatialLines, sp::SpatialPointsDataFrame, and sp listed under Depends in the DESCRIPTION, as well as mentions throughout the vignette and documentation.

Click to expand

$ ag -w sp 
NEWS.md
23:* updated tests, man and vignettes following new handling of projections in sp ([PR 31](https://github.com/ropensci/spatsoc/pull/31), [R spatial information](https://r-spatial.org/r/2020/03/17/wkt.html))

man/group_polys.Rd
30:\code{sp::CRS}. For example, for UTM zone 36S (EPSG 32736),

man/group_lines.Rd
26:\code{sp::CRS}. For example, for UTM zone 36S (EPSG 32736),
43:created with the sp package. If a spLines object is provided, groups cannot

man/build_lines.Rd
20:\code{sp::CRS}. For example, for UTM zone 36S (EPSG 32736),

man/build_polys.Rd
22:\code{sp::CRS}. For example, for UTM zone 36S (EPSG 32736),
113:library(sp)

vignettes/faq.Rmd
81:* `sp`
200:be passed to `sp::CRS`. For example, for UTM zone 36S (EPSG 32736), the projection
213:This warning is explicitly verbose, to ensure we are considering the updated use of CRS [in `sp`](https://r-spatial.org/r/2020/03/17/wkt.html#crs-objects-in-sp) and other spatial packages.  
242:passed to `sp::CRS`. For example, for UTM zone 36S (EPSG 32736), the projection
255:This warning is explicitly verbose, to ensure we are considering the updated use of CRS [in `sp`](https://r-spatial.org/r/2020/03/17/wkt.html#crs-objects-in-sp) and other spatial packages.  

vignettes/intro-spatsoc.Rmd
214:Package dependencies for `spatsoc` are `sp`, `rgeos`, `igraph`, `adehabitatHR` and `data.table`. `data.table` provides efficient methods for manipulating large (or small) datasets. As a result, input `DT` for all `spatsoc` functions must be a `data.table` and if it isn't, you can simply use `data.table::setDT(df)` to convert it by reference. 

DESCRIPTION
28:    sp,

codemeta.json
139:      "identifier": "sp",
140:      "name": "sp",
147:      "sameAs": "https://CRAN.R-project.org/package=sp"

R/build_lines.R
152:      proj4string <- sp::CRS(projection)
154:        sp::SpatialLines(list(sp::Lines(sp::Line(
161:      return(do.call(sp::rbind.SpatialLines, l))

R/group_lines.R
73:#'   created with the sp package. If a spLines object is provided, groups cannot

R/build_polys.R
55:#' \code{sp::CRS}. For example, for UTM zone 36S (EPSG 32736),
86:#' library(sp)
179:    spPts <- sp::SpatialPointsDataFrame(
181:      proj4string = sp::CRS(projection),

Searching the repository for rgeos, we find a dependency on functions rgeos::gIntersects, rgeos::gBuffer, rgeos::gIntersection, rgeos::gArea and rgeos listed under Depends in the DESCRIPTION, as well as mentions throughout the vignette and documentation.

Click to expand

$ ag -w rgeos 
NEWS.md
9:* fix proportions outside 0-1 due to differences in default units from rgeos::gArea 

vignettes/faq.Rmd
83:* `rgeos`

vignettes/intro-spatsoc.Rmd
214:Package dependencies for `spatsoc` are `sp`, `rgeos`, `igraph`, `adehabitatHR` and `data.table`. `data.table` provides efficient methods for manipulating large (or small) datasets. As a result, input `DT` for all `spatsoc` functions must be a `data.table` and if it isn't, you can simply use `data.table::setDT(df)` to convert it by reference. 
216:In addition, since the `rgeos` package is used in most functions (`group_lines` and `group_polys`) the input `DT`'s coordinate system is important. `rgeos` expects planar coordinates and this requirement is carried forward for `spatsoc`. Since `rgeos` is used, system dependencies include `GEOS`. 

README.md
86:`spatsoc` depends on `rgeos` and requires

DESCRIPTION
29:    rgeos,

codemeta.json
151:      "identifier": "rgeos",
152:      "name": "rgeos",
159:      "sameAs": "https://CRAN.R-project.org/package=rgeos"

README.Rmd
73:`spatsoc` depends on `rgeos` and requires [GEOS](https://trac.osgeo.org/geos/) installed on the system. 

R/group_lines.R
184:        inter <- rgeos::gIntersects(spLines, spLines, byid = TRUE)
186:        buffered <- rgeos::gBuffer(spLines, width = threshold,
188:        inter <- rgeos::gIntersects(spLines, buffered, byid = TRUE)
215:          inter <- rgeos::gIntersects(spLines, spLines, byid = TRUE)
217:          buffered <- rgeos::gBuffer(spLines, width = threshold, byid = TRUE)
218:          inter <- rgeos::gIntersects(spLines, buffered, byid = TRUE)
268:              inter <- rgeos::gIntersects(spLines, spLines, byid = TRUE)
270:              buffered <- rgeos::gBuffer(spLines, width = threshold,
272:              inter <- rgeos::gIntersects(spLines, buffered, byid = TRUE)

R/group_polys.R
131:        inter <- rgeos::gIntersects(spPolys, spPolys, byid = TRUE)
146:          rgeos::gIntersection(spPolys, spPolys, byid = TRUE)
206:              inter <- rgeos::gIntersects(spPolys, spPolys, byid = TRUE)
253:              inters <- rgeos::gIntersection(spPolys, spPolys, byid = TRUE)
254:              areas <- rgeos::gArea(inters, byid = TRUE)

build_lines and build_polys will be modified to use sf instead of sp first, then changes to documentation and functions that use these functions internally (group_lines and group_polys) next.

Will link relevant PRs to this issue.

[robitalec]

Removed dependencies on retired spatial packages

• dependency on retiring spatial infrastructure packages #50 (Fix/rm sp build polys #52, Fix/rm sp build lines #53, Fix/rm sp group lines #54, Fix/rm sp group polys #55)
  • spatsoc now depends on sf, units instead of rgeos and sp
  • build_lines now returns an sf LINESTRING object
  • build_polys now returns an sf POLYGON/MULTIPOLYGON object
  • group_lines now accepts an input sf LINESTRING object (argument "sfLines")
    and internally uses sf::st_intersects, sf::st_buffer, etc instead of rgeos functions
  • group_polys now accepts an input sf POLYGON/MULTIPOLYGON object (argument "sfPolys")
    and internally uses sf::st_intersects, sf::st_area, etc instead of rgeos functions.
    group_polys now returns area and proportion of overlap when area = TRUE with
    respective units using the units package
  • tests, vignettes, manual updated
  • added temporary package startup message until October 2023

Thank you @rsbivand, on its way to CRAN.