[FEATURE] Deprecate osmdata_sp

[mpadge]

[elipousson]

Were you thinking of using lifecycle for this? Or is that overkill for deprecating a single function?

[jmaspons]

sp is not imported any more. Now is just a suggestion required for osm_elevation and trim_osmdata with sf points. See #302

[mpadge]

@jmaspons This goes one step beyond that, to deprecating and then ultimately removing the osmdata_sp() functions. This is in accordance with our official rOpenSci recommendations (last point in that list), and particulary the GitHub issue referenced there. sp is obsolete and shoulnd't really be supported anymore.

[rsbivand]

In https://github.com/rsbivand/sp/tree/sp161, now seeing in revdeps: 00check.log

[mpadge]

Thanks @rsbivand, above commit bypasses that expectation for the moment until we completely deprecate sp. Should pass your revdep tests from here on regardless.

[rsbivand]

With 0.2.2.002 SP_EVOLUTION_STATUS=0 and forthcoming sp 1.6-1 1 NOTE (libs size): 00check.log With SP_EVOLUTION_STATUS=2, same NOTE: 00check.log With no retiring packages on library path, SP_EVOLUTION_STATUS=2, same NOTE: 00check.log

Looks good! Thanks for your cooperation!

[rsbivand]

CRAN check failures now showing on https://cran.r-project.org/web/checks/check_results_osmdata.html as sp 1.6-1 is on CRAN.

[mpadge]

Thanks @rsbivand, i'm working on the resubmission this very moment :+1:

[mpadge]

@rsbivand New version on CRAN now. Thanks for always paying attention and helping!

[rsbivand]

Looks good! CMD check single NOTE (as before): 00check.log with sp evolution status 2L, and the same but with no retiring packages on the library path, also OK 00check.log So should be OK wrt. the evolution/retirement process.