-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upcoming maptools retirement #5244
Comments
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 |
I think we can drop it. We should schedule this for the next release. |
Thanks, let's drop it. Note that the reason I couldn't decide is that I was afraid this assumption
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. |
Alternatively, if ggplot2 still has a sf dependency, we could switch to |
Agreed - leaning heavily into dropping it |
Hey there. I'm currently maintaining a very old spatial data codebase that heavily used 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 I take it it's because of this? Would it be possible to implement the functionality using |
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. |
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 |
@Ludecan if it's in maintenance mode, you could use |
Thanks @hadley, I tried your suggestion and it worked fine. Then I realized I don't need to fortify the entire I'll get into removing usage of |
Closing this as fixed by #5327. |
It seems now nothing can directly replace |
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).ggplot2/R/fortify-spatial.R
Line 35 in 1d1f795
We need to decide how to deal with this. I think we have several options:
maptools::unionSpatialPolygons()
with sf functions (convert to an sf object, transform it and convert back to an sp object)maptools::unionSpatialPolygons()
fortify()
methods for sp objects altogetherThe text was updated successfully, but these errors were encountered: