options("sp_evolution_status" = 2) # use sf instead of rgdal and rgeos in sp
library(sp)Upcoming changes to popular R packages for spatial data: what you need to do
posts
rstats
The issue
Three popular R packages for spatial data handling won’t be available on CRAN after October 2023.1 These packages are:
- rgdal: a package that provides bindings to the GDAL and PROJ libraries. In other words, it gives a capability of reading and writing spatial data formats, creating coordinate reference systems and projecting geometries.
- rgeos: a package that provides bindings to the GEOS library. It allows to perform various spatial operations, such as buffering, clipping, or unioning.
- maptools: an older set of various tools for manipulating spatial data pre-dating rgdal and rgeos.
As you can see, two of these packages, rgdal and rgeos link and allow access to external (non-R) spatial libraries for reading and writing spatial data formats and performing spatial operations, such as reprojections and spatial joins.
If you are a user or developer of any of these packages, you need to be aware of the upcoming changes. From the user perspective, you won’t be able to install these packages from CRAN soon, and thus your workflows will be broken. On the other hand, if you are a developer and your package uses some of the above packages, it will stop working and you won’t be able to retain (or submit) it to CRAN. Very soon you will need to find some alternatives to these packages. Gladly, most of rgdal, rgeos, and maptools functionality is already available in modern R packages, such as sf and terra, as you will see below.
The context
rgdal and maptools were first published on CRAN in 2003, and rgeos in 2011. These packages were developed when the spatial data analysis ecosystem in R was still very young, and they were subsequently used for many (ecological) data analysis workflows.
Writing a popular, complex package is a lot of work, and maintaining it is even much more work. This can be seen, for example, by looking at the release versions of the rgdal package. There were 151 releases of this package between 2003 and 2023, which means that there was a new release every 7 weeks on average. Now, let’s consider that each release requires many hours of (usually voluntary) work.
rgdal, maptools, and rgeos have a few things in common. While they are independent, they are also closely related to each other – all of them depend on the sp package for spatial data representation in R.2 Another thing they have in common is that currently we have more modern alternatives to them, such as sf (first released in 2016) and terra (2020). Finally, the main author of rgdal, maptools, and rgeos is the same person – Roger Bivand, who retired from his position at the Norwegian School of Economics in 2021.
Thus, given the workloads of maintaining these packages, the existence of modern alternatives, and the retirement of the main author, it was decided to retire these packages.3
How to test if your code is affected?
The most basic way to test if your code is affected by the upcoming changes is to check if you use rgdal, rgeos, and maptools in your scripts or as dependencies in your packages. If so – your workflows may be broken soon!
There is also a possibility that you use the sp package but not the affected packages. In this case, you may still be touched by the changes, because the sp package had interacted with rgdal and rgeos in the background. For example, if you run the spTransform() function from the sp package, it used the rgdal package in the background. Thus, you may add the following code to your script to check if it will work in the future:
If you get an error, it means that your code is affected by the changes.4
There is also another possible situation – you are using some packages that depend on the affected packages. This one is the most difficult to check, because you need to inspect the dependencies of all the packages you use.5
Solutions for users
My first advice would be: do yourself a favor, and just stop using the retired packages today. Write your new scripts using modern alternatives, such as sf or terra. In most cases they are easy to use, and you will be able to find a lot of examples and other resources online.
If you have some old scripts that use the retired packages, you have a few options and your decision should depend on your circumstances. If you do not plan to use them in the future, you can just leave them as they are. On the other hand, if you want to perform similar spatial operations, you should consider rewriting the scripts using modern alternatives – see the tables below for the equivalents of the most popular functions from rgdal, rgeos, and maptools.
You also may have old sp objects that you want to use in the future. Then, you can convert them to the modern equivalents with functions such as sf::st_as_sf() or terra::vect().6
Finally, you may decide to still use the retired packages. You can do that by either not updating your R installation and packages, or by creating a docker image with the old R and packages versions. However, this is generally not a good idea, because rgdal, rgeos, and maptools will be archived on CRAN soon, and thus you (and other people) won’t be able to install them directly.7
Solutions for package developers
Look at your package dependencies and check if you use any of the affected packages. If that is the case, you need to find alternatives to them. In general, there are two main alternative options8:
- sf package, which is a modern alternative to rgdal and rgeos, and also provides a spatial vector data representation in R.
- terra package, which gives support to working with spatial vector and raster data in R.
You just need to be aware that functions in these packages are not always identical to the ones in the affected packages. They may have different arguments, different defaults, expect different inputs, or return different outputs. For example, rgdal’s readOGR() function returns a Spatial*DataFrame object, while sf’s read_sf() returns an sf object and terra’s vect() returns a SpatVector object.9
| rgdal | sf | terra |
|---|---|---|
| readOGR() | read_sf() | vect() |
| writeOGR() | write_sf() | writeVector() |
The rgeos functions also have their equivalents in sf and terra.10
Interestingly, the most often used maptools functions have been already deprecated for a long time and alternative tools for the same purposes existed, e.g., unionSpatialPolygons() could be replaced with rgeos::gUnaryUnion(), and maptools::spRbind() with sp::rbind(). The table below shows their modern substitutes.
| rgeos | sf | terra |
|---|---|---|
| gArea() | st_area() | expanse() |
| gBuffer() | st_buffer() | buffer() |
| gCentroid() | st_centroid() | centroids() |
| gDistance() | st_distance() | distance() |
| gIntersection() | st_intersection() | crop() |
| gIntersects() | st_intersects() | relate() |
| maptools | sf | terra |
|---|---|---|
| unionSpatialPolygons() | st_union() | aggregate() |
| spRbind() | rbind() | rbind() |
The sp package is not going to be removed from CRAN soon, but it is good to stop using it because it is no longer being actively developed. Here you can find some replacements for its basic functions:
| sp | sf | terra |
|---|---|---|
| bbox() | st_bbox() | ext() |
| coordinates() | st_coordinates() | crds() |
| identicalCRS() | st_crs(x) == st_crs(y) | crs(x) == crs(y) |
| over() | st_intersects() | relate() |
| point.in.polygon() | st_intersects() | relate() |
| proj4string() | st_crs() | crs() |
| spsample() | st_sample() | spatSample() |
| spTransform() | st_transform() | project() |
You also may want to visit the comparison table and the migration wiki to get more complete lists of alternative functions to the ones from rgdal, rgeos, and maptools.
Additionally, you may still want to accept sp objects as inputs and return them as outputs of your functions. In such case, you can use the sf::st_as_sf() or terra::vect() functions to convert sp objects to the modern equivalents, perform required spatial operations with sf/terra, and then convert the results back to sp objects with as(x, "Spatial"). Packages depending on sp would also need to add sf as their weak dependency.11
More resources
You may use the evolution GitHub repository to ask questions about the retirement process.
To learn more about the rgdal, rgeos, and maptools retirement, you can check the following resources:
- The announcement of their retirement
- A blog post series about the retirement process: part 1, part 2, part 3, part 4
- A video about this retirement process: https://youtu.be/TlpjIqTPMCA
- Scripts converting code from the Applied Spatial Data Analysis with R 2nd edition book to run without retiring packages: https://github.com/rsbivand/sf_asdar2ed
On the other hand, if you want to learn more about their alternatives and how to use them, there are many resources available online:
- sf package’s official website
- terra package’s documentation
- The Geocomputation with R book
- The Spatial Data Science with applications in R book and its section on the retirement process
By exploring these resources, you will be able to find alternative workflows that suit your needs and continue your work with spatial data in R. Good luck!
Acknowledgements
I would like to thank Roger Bivand and Maximilian H.K. Hesselbarth for their comments and suggestions that helped to improve this document.
Footnotes
Their retirement was announced almost two years ago.↩︎
This they share with the raster package, which was builtd on sp representations and used rgdal and rgeos under the hood. Since September 2022, raster uses terra, not rgdal or rgeos.↩︎
More details about the context of these changes may be found in the paper by Bivand (2021).↩︎
But if you make the sf package available,
spTransform()will use it instead of rgdal. Similarly, many workflows using raster can make terra available, and remove any mention of rgdal or rgeos.↩︎However, maintainers of these packages have been actively contacted with the information of both the need to act, and suggesting ways to migrate from retiring packages to sf or terra. Many packages depended on rgdal and rgeos because raster used to depend on them; they can safely be replaced by the use by raster of terra “under the hood”.↩︎
Read more about this in the Conversions between different spatial classes in R and Progress on R-spatial evolution, Apr 2023 blog posts.↩︎
Their installation will require downloading source packages from the CRAN package archive, and the providing the external software libraries needed to install rgdal and rgeos from source.↩︎
There are also other options, such as using the vapour or geos package, but they are not discussed here.↩︎
Of course, you can convert these objects back to sp classes and carry on as before, if you choose. However, this choice is most suited to legacy settings rather than actively maintained packages.↩︎
You just need to be aware that they may return different values compared to rgeos. For example, sf may use a different algorithm to calculate the area of a polygon for data with a geographical coordinate reference system (CRS).↩︎
See the coercion section of the Progress on R-spatial evolution, Apr 2023 blog post.↩︎
Reuse
Citation
BibTeX citation:
@online{nowosad2023,
author = {Nowosad, Jakub},
title = {Upcoming Changes to Popular {R} Packages for Spatial Data:
What You Need to Do},
date = {2023-06-04},
url = {https://geocompx.org//post/2023/rgdal-retirement},
langid = {en}
}
For attribution, please cite this work as:
Nowosad, Jakub. 2023. “Upcoming Changes to Popular R Packages for
Spatial Data: What You Need to Do.” June 4, 2023. https://geocompx.org//post/2023/rgdal-retirement.