Upcoming maptools retirement

[yutannihilation]

A year ago, R-spatial announced rgdal, rgeos, and maptools will retire by the end of 2023.

https://r-spatial.org//r/2022/04/12/evolution.html

ggplot2 doesn't use rgdal, and just removed rgeos in #5242. However, maptools is still used in fortify.SpatialPolygonsDataFrame() (and the examples section of the document).

https://github.com/tidyverse/ggplot2/blob/1d1f79560c23241999529a92178a913769b8d28e/R/fortify-spatial.R#L35

We need to decide how to deal with this. I think we have several options:

1. Replace maptools::unionSpatialPolygons() with sf functions (convert to an sf object, transform it and convert back to an sp object)
2. Remove the functionality related to maptools::unionSpatialPolygons()
3. Drop fortify() methods for sp objects altogether

[thomasp85]

I'm fine with either 1 or 3

The only argument for 1 is to preserve the function of very old code as I assume everyone has moved to sf by now

[yutannihilation]

https://geocompx.org/post/2023/rgdal-retirement/#solutions-for-package-developers

[hadley]

I think we can drop it. We should schedule this for the next release.

[yutannihilation]

Thanks, let's drop it.

Note that the reason I couldn't decide is that I was afraid this assumption

everyone has moved to sf by now

might not be really true. For example, I read a book about spatial statistics using R, which was published in 2022, and it still uses rgoes and rgdal in several places although it primarily uses sf. I thought this probably means, even if the internal implementations were already replaced with sf, these longstanding packages might still generate the result as sp (I'm not familiar with spatial statistics, so I'm not sure).

But, converting an sp object to sf should be easy, and the sp ecosystem is about to retire anyway. So, it's probably time to drop it.

[hadley]

Alternatively, if ggplot2 still has a sf dependency, we could switch to sf::st_union() instead. Or maybe fortify.SpatialPolygonsDataFrame() could convert to an sf object and then fortify that?

[thomasp85]

Agreed - leaning heavily into dropping it

[Ludecan]

Hey there. I'm currently maintaining a very old spatial data codebase that heavily used sp for spatial data manipulation and ggplot2 for plotting. As a part of it I did both plots of point and raster data while plotting using a background shapefile like this:

I have several functions (one for points, one for points + text, one for rasters) that plot the data using custom x and y aesthetics and then plot the shapefile on top. To plot the base shapefile I'm using a single function that serves all 3 methods and uses fortify on a SpatialPolygonsDataFrame.

I take it it's because of this? Would it be possible to implement the functionality using sf as you suggest? Or is there a way I can implement an alternative version of it in my codebase? Thanks in advance

[teunbrand]

I think the recommendation from r-spatial is to move away from {sp} in favour of {sf}. More information can be found in the readme of https://github.com/r-spatial/evolution with various links to other places.

[Ludecan]

Yes, will definitely try to go that way, but this is an older codebase that is currently in maintenance mode, it's going to be a major change to migrate all of it to sf. I will try to start doing it gradually but it's not going to be an easy task.

[hadley]

@Ludecan if it's in maintenance mode, you could use renv::snapshot() to capture all the dependencies as of a certain date, and just continue to use sp.

[Ludecan]

@Ludecan if it's in maintenance mode, you could use renv::snapshot() to capture all the dependencies as of a certain date, and just continue to use sp.

Thanks @hadley, I tried your suggestion and it worked fine.

Then I realized I don't need to fortify the entire SpatialPolygonsDataFrame but rather only it's geometry, which is a SpatialPolygons object for which fortify doesn't seem to use maptools. This was the only use in my codebase so I dropped the dependency altogether.

I'll get into removing usage of rgdal and rgeos from the rest of my code but this will give me some time to do so. Thanks for your help!

[teunbrand]

Closing this as fixed by #5327.