Fix rgdal dependencies

[kaijagahm]

When I load the package, I get the following message as of recently:

The legacy packages maptools, rgdal, and rgeos, underpinning this package will retire shortly. Please refer to R-spatial evolution reports on https://r-spatial.org/r/2023/05/15/evolution4.html for details. This package is now running under evolution status 0

We need to update vultureUtils so it doesn't depend on these packages anymore, but without changing the outputs.

This is because rgdal is retiring. Apparently I'm actually an entire year late to dealing with this. Ugh. Resources for dealing with this:

• https://r-spatial.org/r/2022/04/12/evolution.html
• https://stackoverflow.com/questions/69589608/what-should-i-actually-be-doing-in-response-to-this-warning-please-note-that-r (sounds like sf doesn't depend on rgdal, so we're good using that, which confirms what I thought).

The places where I know this package uses rgdal/maptools/rgeos are 1) the "distgeo" function crops up in various places for distance calculations, I think, and 2) some of the sunrise/sunset calculations use maptools functions, and I don't want them to.

[ryannguyen6392]

I think maptools is only used once in get_roosts_df and is addressed here in the corresponding PR.

distGeo is used by geosphere, which in turn ports sp. However, sp seems to be handling the issue. The other direct ports are move and spatsoc. Though move also ports sp and spatsoc seems to be handling the issue, see https://github.com/ropensci/spatsoc/issues/50

[robitalec]

You might be interested in move2, which uses sf instead of sp https://gitlab.com/bartk/move2

spatsoc should be updated soon, and will use sf instead of sp. The grouping functions won't noticeably change, but the returned objects from build_lines and build_polys will be sf objects. Hopefully that doesn't disrupt users too much if they are using those functions and expecting sp objects returned.

Good luck!