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.

Unless someone steps up to volunteer maintaining packages maptools, rgdal and rgeos, the plan is to retire packages by the end of 2023. Retirement means that maintenance will halt, and that as a consequence the packages will sooner or later disappear from CRAN. One reason for retirement is that their maintainer has retired, another that their role has been superseded by the newer packages. We hold it not for very likely that a new maintainer will take over, in part because much of the code of these packages has over a few decades gradually evolved along with developments in the GEOS, GDAL and PROJ libraries, and now contains numerous constructs that are no longer necessary and make it hard 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 only involves validation of coordinate reference system identifiers, and checking whether rings are holes or exterior rings. Theoretically one could replace rgdal and rgeos with packages that would call into sf for their ties to the GEOS, GDAL and PROJ libraries but that would involve a major effort.

A.3 Migration code and packages

The wiki page of the GitHub site for sf, found at

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 Gomez-Rubio, Bivand, Pebesma, and Gomez-Rubio (2013)) to run entirely without rgdal, rgeos and maptools and where possible without sp. The scripts are found at .

A.4 Package raster and terra

Package raster has been a workhorse package for analysing raster data with R since 2010, and has since then grown into a package for “Geographic Data Analysis and Modeling” (Hijmans 2022a), indicating that it is used for all kinds of spatial data. The raster package uses sp objects for vector data, and rgdal to read and write data to formats served by the GDAL library. Its successor package terra, for “Spatial Data Analysis” (Hijmans 2022b), “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. Migration from raster to terra may become more important once rgdal is no longer easily installable (Section A.1).

The online book “Spatial Data Science with R”, written by Robert Hijmans and found at 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 .

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, emphasizing 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.