Retirement of **maptools**, **rgdal** and **rgeos**

[rsbivand]

From https://r-spatial.org/r/2022/04/12/evolution.html and other channels you should know that maptools, rgdal and rgeos will retire during 2023. Your tests expect silent execution, but forthcoming releases of these packages deprecate many functions and methods. Development versions of the retiring packages may be found on R-Forge. Further note that from raster 3.6-3, the retiring packages are no longer dependencies, with terra used to access external libraries. 00check.log tinytest.Rout.zip

[pennybeaver]

Just tried to run the code using your boobies data, I keep getting the following error message:

?boobies # for some background info on the example data set

dataGroup <- formatFields(

• dataGroup = boobies,
• fieldID = "track_id",
• fieldDate = "date_gmt",
• fieldTime = "time_gmt",
• fieldLon = "longitude",
• fieldLat = "latitude"
• )

_No format supplied for Date and Time fields, a default format ('ymd_HMS') attempted when combining the fields. If error produced, see help page ('?lubridate::parse_date_time') for information on date formats._

Does the data need to be reformatted such as the date and time?

[rsbivand]

@pennybeaver please do start a separate issue; #43 is about a failed test when run with the development version of rgdal.

[MartinBeal]

Just noting here for future reference.

As far as I can tell, the major question for this migration out of rgdal/rgeos/maptools is the dependency on adehabitatHR. I think most of our direct dependencies on rgdal/rgeos/maptools will be straightforward to change, but if adehabitatHR doesn't migrate then we have deeper issues. I.e., how to perform KDE without adehabitatHR.

[rsbivand]

rgdal 1.6-2 has been submitted to CRAN; the failing testthat test reported three weeks ago will then be a CRAN check error:

----- FAILED[xcpt]: test_projectTracks.R<35--36>
 call| expect_silent(projectTracks(dataGroup = dat_prj, projType = "azim", 
 call| -->    custom = TRUE))
 diff| Execution was not silent. A warning was thrown with message
 diff| 'PROJ support is provided by the sf and terra packages among others'

Simply remove the expect_silent() or replace with the expected value, not an absence of messages.

[MartinBeal]

@rsbivand good to know, thanks.

In the coming paradigm of R-spatial without rgdal/maptools/sp are you aware of a method for constructing custom-centered projections? Currently we customize proj4strings based on the average position on the earth of the input data. As of yet I haven't come across an analogous procedure for WKT strings etc. Any suggestions leveraging sf/terra/stars would be great.

[rsbivand]

sp remains but will use sf where its methods and functions now rely on rgdal and rgeos. maptools also retires, with some functionality moved to sp, some noted as issues to r-spatial/evolution.

For custom projections, you can use PROJ strings, or projjson strings, but probably all projections/ transformations from these will only have ballpark accuracy. Better to drop them, really. If ballpark accuracy isn't a problem and you don't use any interactive/web mapping where the inaccuracies show up when zooming, maybe continue as now, but +towgs84 is gone.

[MartinBeal]

Ok great, that's one less headache. Thanks!

[rsbivand]

Maybe consider the crsuggest package too? If the output objects may need more accurate transformation, using an EPSG code might help.

[rsbivand]

New blog:

This package depends on (depends, imports or suggests) raster and one or more of the retiring packages rgdal, rgeos or maptools (https://r-spatial.org/r/2022/04/12/evolution.html, https://r-spatial.org/r/2022/12/14/evolution2.html). Since raster 3.6.3, all use of external FOSS library functionality has been transferred to terra, making the retiring packages very likely redundant. It would help greatly if you could remove dependencies on the retiring packages as soon as possible.

[MartinBeal]

From blog: "This also means that all packages that depend on or import from raster, and added a weak dependency on rgdal and rgeos for that reason, may now drop those dependencies, conditional on requiring raster of version >= 3.6-3."

[rsbivand]

This is what seems likely, so worth trying. The package also uses maptools::spRbind(), which may possibly be replaced by rbind() methods in sp for vector classes (including "SpatialPixels"), see https://github.com/edzer/sp/blob/main/R/rbind.R - the methods are not well documented.

[Jono-H]

With regards to removing all direct dependencies on rgdal/rgeos/maptools from within the track2KBA R package, I think have resolved this issue.

Checking direct dependencies

• To identify which functions in track2kbarely on functions in other packages, I used the foodweb function from the mvbutils R package. Description of approach in this stackoverflow post

Removing direct dependencies

• Using R version 4.2.2 (2022-10-31 ucrt), I downloaded an offline copy of the track2kbaR package.
• I sourced the functions and data directly from my personal machine via source and worked through the tutorial track2KBAGitHub code.
• I loaded required packages only when necessary to execute each of the functions in track2kba
• As suggested above, this resolved the dependency of the track2kba R package on maptools.

Next steps

• Having forked the track2kba package, I edited the relevant code, and created a pull request
• No other functions in track2kba use functions directly from rgdal/rgeos/maptools.
• Therefore, primary next steps are to consider migration of direct dependencies within track2kba on sp, and adehabitatHR (given adehabitatHR still depends on sp)

[MartinBeal]

I've updated the PR to rmv maptools from the package namespace and documentation.

For some reason it is failing the automatic checks on the Windows Release version of R. So will have to do some sleuthing there, but I don't think this is caused by the changes we made.

[rsbivand]

It looks transient, with no available version of sf for Windows when the job was run. I'd trigger the check again.

[MartinBeal]

@rsbivand I thought so too, but it still fails today...will try again tomorrow, I guess

[rsbivand]

Please try _SP_EVOLUTION_STATUS_=2 R CMD check: I see: 00check.log The version of sp with evolution status 2L will be submitted to CRAN June 10.

[MartinBeal]

sp remains but will use sf where its methods and functions now rely on rgdal and rgeos. maptools also retires, with some functionality moved to sp, some noted as issues to r-spatial/evolution.

For custom projections, you can use PROJ strings, or projjson strings, but probably all projections/ transformations from these will only have ballpark accuracy. Better to drop them, really. If ballpark accuracy isn't a problem and you don't use any interactive/web mapping where the inaccuracies show up when zooming, maybe continue as now, but +towgs84 is gone._

Hey Roger, I'm still getting errors in my tests regarding the use of spTransform() and it's dependency on rgdal. Is there a way to call this function without envoking rgdal? Or a minimum version of sp to specify, perhaps?

Error in sp::spTransform(dataGroup, CRSobj = proj) : 
    package rgdal is required for spTransform methods
  Calls: projectTracks -> <Anonymous> -> <Anonymous>
  Execution halted

[rsbivand]

Are you running CMD check manually with _SP_EVOLUTION_STATUS_=2 and possibly also _R_CHECK_SUGGESTS_ONLY_=true? See https://r-spatial.org/r/2023/05/15/evolution4.html#sp-evolution-status for more details. The evolution status mechanism was introduced in 1.5-0 a year ago, and improved in 1.6-0 early this year. You also still have rgdal and rgeos in Imports: in DESCRIPTION. Which branch is the development branch?

[MartinBeal]

@rsbivand I was running checks locally. The changes are now implemented in the rgdal/rgeos_indep branch.

Checks still failed locally when running devtools::check(args = c('_SP_EVOLUTIONSTATUS=2','_R_CHECK_SUGGESTSONLY=true'))

Unsurprisingly also fail in GH workflow (haven't yet figured out how to set R CMD options in yaml).

[rsbivand]

CMD check of track2kba-rgdal-rgeos_indep running under sp evolution status 2 and with retiring packages on the library path : 00check.log

and without retiring packages on the library path : 00check.log

After commenting out library(rgdal) in all the affected files in inst/tinytest/ (also with _R_CHECK_SUGGESTS_ONLY_=true) : 00check.log

So partly the library(rgdal) in test files. The remainder seem to be in test_findSite.R, but I can't debug that now, sorry.

[MartinBeal]

rgdal/rgeos_indep branch now passes checks with no problem. I believe this branch should now be fully independent of rgdal/rgeos/maptools.

Would you like to confirm before I merge with master and submit to CRAN @rsbivand ?

[rsbivand]

Looks OK, the test errors seem to be because I'm running a development version of GEOS with a version that triggers NAs introduced by coercion, in sf. I can't install a released version of GEOS because I have a too recent GCC.

[rsbivand]

@MartinBeal Is this ready to submit now? Note the summer submission break on CRAN: https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009324.html.

[MartinBeal]

I've submitted it and am awaiting a response from the CRAN team.

On Fri, Jul 14, 2023 at 10:04 AM Roger Bivand @.***> wrote:

@MartinBeal https://github.com/MartinBeal Is this ready to submit now? Note the summer submission break on CRAN: https://stat.ethz.ch/pipermail/r-package-devel/2023q3/009324.html.

— Reply to this email directly, view it on GitHub https://github.com/BirdLifeInternational/track2kba/issues/43#issuecomment-1635543512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK2MB2EHV27CKDTGL6OCB3TXQEDTBANCNFSM6AAAAAAREAXMIA . You are receiving this because you were mentioned.Message ID: @.***>

[rsbivand]

@MartinBeal Could you please expedite the submission? 1.1.0 still depends strongly on rgdal rgeos; less than three weeks before we archive them.

[MartinBeal]

v.1.1.1 on it's way to CRAN as we speak. something went wrong with the submit back in July.

[MartinBeal]

@rsbivand v 1.1.1 is now live. can you confirm that we are in the clear?

[rsbivand]

Looks OK, here is a check log: 00check.log