library(sp)
= as(x, "Spatial") y
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
and the conversion the other way around is done by
= st_as_sf(y) x0
There are some limitations to conversions like this:
- sp does not distinguish between
LINESTRING
andMULTILINESTRING
geometries, or betweenPOLYGON
orMULTIPOLYGON
. For example, aLINESTRING
will after conversion tosp
come back as aMULTILINESTRING
- sp does not have a representation for
GEOMETRYCOLLECTION
geometries, orsf
objects with geometry types not in the “big seven” (Section 3.1.1) sf
orsfc
objects of geometry typeGEOMETRY
, with mixed geometry types, cannot be converted intosp
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
= as(sf::read_sf("file"), "Spatial") x
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.