Drop sp/raster support

[ateucher]

As these are end-of-life and being fully replaced by sf and terra, we should drop support for them, first by deprecating, then by removing them entirely

[stephhazlitt]

Would we consider using lifecycle for this, it has a nice option to deprecate just an argument or partially deprecate an argument. On quick look this is what we will need to do for most of the functions for sp?

[ateucher]

I think for the functions that provide data sources that makes sense... basically want to deprecate the class parameter right? For the utility functions (fix_geo_problems, transform_bc_albers) we want to deprecate the .Spatial methods I think using the traditional means - but I bet Lifecycle has ways to facilitate that as well?

[boshek]

One other way would be to just add a message on package load saying "sp is going away, be advised". The advantage there is that it is more likely to be read. Or maybe a combination of the two.

[ateucher]

I think both are a good idea. Using the .Depracated method you get the message on the function calls "for free"

[stephhazlitt]

This issue includes a fair bit of documentation updating as well. Perhaps just a notice for deprecating, but quite a bit of editing with removal.

[ateucher]

For sure. We should check the vignettes as well.

[stephhazlitt]

I have a PR up starting this work. Should (or can) we duplicate this issue and have one Issue/PR for deprecating all sp-related functionality and a second Issue/PR for changing raster fxns to use {terra}?

[stephhazlitt]

@ateucher nudge re: splitting the work behind this issue out into 2 PRs?

[ateucher]

I think two PRs makes sense

[stephhazlitt]

@ateucher Do we leave this open until the Summer release?

[ateucher]

Let's close it - I'll change the name so it's more reflective of what we did, then open a new one with a milestone

[ateucher]

closed by #119