Appendix A — Older R Spatial Packages

A.1 Retiring rgdal and rgeos

R users who have been around a bit longer, in particular before packages like sf and stars were developed, may be more familiar with older packages like maptools, sp, rgeos, and rgdal. A fair question is whether they should migrate existing code and/or existing R packages depending on these packages. The answer is: yes.

Packages maptools, rgdal, and rgeos will retire during 2023. Retirement means that maintenance will halt, and that as a consequence the packages will be archived on CRAN. The source code repositories on R-Forge will remain as long as R-Forge does itself. One reason for retirement is that their maintainer has retired, a more important reason that their role has been superseded by the newer packages. We hold it most unlikely that a new maintainer will take over the R-Forge repositories, in part because much of the code of these packages has gradually evolved along with developments in the GEOS, GDAL, and PROJ libraries, and contains numerous constructs that are outdated and make it forbidding to read.

Before rgeos and rgdal retire, existing ties that package sp has to rgdal and rgeos can and will be replaced by ties to package sf. This involves for example validation of coordinate reference system identifiers, and checking whether rings are holes or exterior rings. Chosen maptools functions may also be moved to sp.

A.2 Links and differences between sf and sp

There are a number of differences between sf and sp. The most notable is that sp classes are formal, S4 classes where sf uses the (more) informal S3 class hierarchy. sf objects are derived from data.frames or tibbles and because of that are more readily interfaceable with much of the existing R ecosystem, especially with the tidyverse package family. sf objects keep geometry in a list-column, meaning that a geometry is always a list element. Package sp used data structures much less strictly, and for instance all coordinates of SpatialPoints or SpatialPixels are kept in matrices, which is much more performant for certain problems but is not possible with a list-column. Conversion from an sf object x to its sp equivalent is done by

library(sp)
y = as(x, "Spatial")

and the conversion the other way around is done by

x0 = st_as_sf(y)

There are some limitations to conversions like this:

sp does not distinguish between LINESTRING and MULTILINESTRING geometries, or between POLYGON or MULTIPOLYGON. For example, a LINESTRING will after conversion to sp come back as a MULTILINESTRING
sp does not have a representation for GEOMETRYCOLLECTION geometries, or sf objects with geometry types not in the “big seven” (Section 3.1.1)
sf or sfc objects of geometry type GEOMETRY, with mixed geometry types, cannot be converted into sp objects
attribute-geometry relationship attributes get lost when converting to sp
sf objects with more than one geometry list-column will, when converting to sp, lose their secondary list-column(s).

A.3 Migration code and packages

The wiki page of the GitHub site for sf, found at https://github.com/r-spatial/sf/wiki/Migrating contains a list of methods and functions in rgeos, rgdal, and sp and the corresponding sf method or function. This may help converting existing code or packages.

A simple approach to migrate code is when only rgdal::readOGR is used to read file. As an alternative, one might use

x = as(sf::read_sf("file"), "Spatial")

however possible arguments to readOGR, when used, would need more care. An effort by us is underway to convert all code of our earlier book Applied Spatial Data Analysis with R (with Virgilio Gómez-Rubio, Bivand, Pebesma, and Gómez-Rubio (2013)) to run entirely without rgdal, rgeos, and maptools and where possible without sp. The scripts are found at https://github.com/rsbivand/sf_asdar2ed.

A.4 Package raster and terra

Package raster has been a workhorse package for analysing raster data with R since 2010, and has since grown into a package for “Geographic Data Analysis and Modeling” (Hijmans 2023a), indicating that it is used for all kinds of spatial data. The raster package uses sp objects for vector data, and terra to read and write data to formats served by the GDAL library. Its successor package terra, for “Spatial Data Analysis” (Hijmans 2023b), “is very similar to the raster package; but […] can do more, is easier to use, and […] is faster”. The terra package comes with its own classes for vector data, but accepts many sf objects, with similar restrictions as listed above for conversion to sp. Package terra has its own direct links to GDAL, GEOS, and PROJ, so, no longer needs other packages for that.

Raster maps, or stacks of them from package raster or terra can be converted to stars objects using st_as_stars(). Package sf contains an st_as_sf() method for SpatVector objects from package terra.

The online book Spatial Data Science with R, written by Robert Hijmans and found at https://rspatial.org/terra details the terra approach to spatial data analysis. Package sf and stars and several other r-spatial packages discussed in this book reside on the r-spatial GitHub organisation (note the hyphen between r and spatial, which is absent on Hijmans’ organisation), which has a blog site, with links to this book, found at https://r-spatial.org/book.

Packages sf and stars on one hand and terra on the other have many goals in common, but try to reach them in slightly different ways, emphasising different aspects of data analysis, software engineering, and community management. Although this may confuse some users, we believe that these differences enrich the R package ecosystem, are beneficial to users, encourage diversity and choice, and hopefully work as an encouragement for others to continue trying out new ideas when using R for spatial data problems, and to help carrying the R spatial flag.

# Older R Spatial Packages {#sec-older} ## Retiring **rgdal** and **rgeos** {#sec-retire} \index{rgdal!retirement} \index{rgeos!retirement} R users who have been around a bit longer, in particular before packages like **sf** and **stars** were developed, may be more familiar with older packages like **maptools**, **sp**, **rgeos**, and **rgdal**. A fair question is whether they should migrate existing code and/or existing R packages depending on these packages. The answer is: yes. Packages **maptools**, **rgdal**, and **rgeos** will retire during 2023. Retirement means that maintenance will halt, and that as a consequence the packages will be archived on CRAN. The source code repositories on R-Forge will remain as long as R-Forge does itself. One reason for retirement is that their maintainer has retired, a more important reason that their role has been superseded by the newer packages. We hold it most unlikely that a new maintainer will take over the R-Forge repositories, in part because much of the code of these packages has gradually evolved along with developments in the GEOS, GDAL, and PROJ libraries, and contains numerous constructs that are outdated and make it forbidding to read. Before **rgeos** and **rgdal** retire, existing ties that package **sp** has to **rgdal** and **rgeos** can and will be replaced by ties to package **sf**. This involves for example validation of coordinate reference system identifiers, and checking whether rings are holes or exterior rings. Chosen **maptools** functions may also be moved to **sp**. ## Links and differences between sf and sp \index{sp!differences from sf} There are a number of differences between **sf** and **sp**. The most notable is that **sp** classes are formal, S4 classes where **sf** uses the (more) informal S3 class hierarchy. **sf** objects are derived from data.frames or tibbles and because of that are more readily interfaceable with much of the existing R ecosystem, especially with the tidyverse package family. `sf` objects keep geometry in a list-column, meaning that a geometry is _always_ a list element. Package **sp** used data structures much less strictly, and for instance all coordinates of `SpatialPoints` or `SpatialPixels` are kept in matrices, which is much more performant for certain problems but is not possible with a list-column. Conversion from an `sf` object `x` to its **sp** equivalent is done by ```{r eval=FALSE} library(sp) y = as(x, "Spatial") ``` and the conversion the other way around is done by ```{r eval=FALSE} x0 = st_as_sf(y) ``` There are some limitations to conversions like this: * **sp** does not distinguish between `LINESTRING` and `MULTILINESTRING` geometries, or between `POLYGON` or `MULTIPOLYGON`. For example, a `LINESTRING` will after conversion to `sp` come back as a `MULTILINESTRING` * **sp** does not have a representation for `GEOMETRYCOLLECTION` geometries, or `sf` objects with geometry types _not_ in the "big seven" (@sec-seven) * `sf` or `sfc` objects of geometry type `GEOMETRY`, with mixed geometry types, cannot be converted into `sp` objects * attribute-geometry relationship attributes get lost when converting to **sp** * `sf` objects with more than one geometry list-column will, when converting to **sp**, lose their secondary list-column(s). ## Migration code and packages \index{sf!migration from sp} The wiki page of the GitHub site for **sf**, found at <https://github.com/r-spatial/sf/wiki/Migrating> contains a list of methods and functions in **rgeos**, **rgdal**, and **sp** and the corresponding **sf** method or function. This may help converting existing code or packages. A simple approach to migrate code is when only `rgdal::readOGR` is used to read `file`. As an alternative, one might use ```{r, eval = FALSE} x = as(sf::read_sf("file"), "Spatial") ``` however possible arguments to `readOGR`, when used, would need more care. An effort by us is underway to convert all code of our earlier book _Applied Spatial Data Analysis with R_ (with Virgilio Gómez-Rubio, @asdar) to run entirely without **rgdal**, **rgeos**, and **maptools** and where possible without **sp**. The scripts are found at <https://github.com/rsbivand/sf_asdar2ed>. ## Package raster and terra \index{raster} \index{terra} Package **raster** has been a workhorse package for analysing raster data with R since 2010, and has since grown into a package for "Geographic Data Analysis and Modeling" [@R-raster], indicating that it is used for all kinds of spatial data. The **raster** package uses **sp** objects for vector data, and **terra** to read and write data to formats served by the GDAL library. Its successor package **terra**, for "Spatial Data Analysis" [@R-terra], "is very similar to the `raster` package; but [...] can do more, is easier to use, and [...] is faster". The **terra** package comes with its own classes for vector data, but accepts many **sf** objects, with similar restrictions as listed above for conversion to **sp**. Package **terra** has its own direct links to GDAL, GEOS, and PROJ, so, no longer needs other packages for that. Raster maps, or stacks of them from package **raster** or **terra** can be converted to `stars` objects using `st_as_stars()`. Package **sf** contains an `st_as_sf()` method for `SpatVector` objects from package **terra**. The online book _Spatial Data Science with R_, written by Robert Hijmans and found at <https://rspatial.org/terra> details the **terra** approach to spatial data analysis. Package **sf** and **stars** and several other r-spatial packages discussed in this book reside on the `r-spatial` GitHub organisation (note the hyphen between `r` and `spatial`, which is absent on Hijmans' organisation), which has a blog site, with links to this book, found at <https://r-spatial.org/book>. Packages **sf** and **stars** on one hand and **terra** on the other have many goals in common, but try to reach them in slightly different ways, emphasising different aspects of data analysis, software engineering, and community management. Although this may confuse some users, we believe that these differences enrich the R package ecosystem, are beneficial to users, encourage diversity and choice, and hopefully work as an encouragement for others to continue trying out new ideas when using R for spatial data problems, and to help carrying the R spatial flag.