You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently w/ {sp} >=1.6.x the following message is issued on load of aqp (and soilDB, or anything else that imports aqp)
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 still import the SpatialPoints object and import/export the coordinates() method for SoilProfileCollection, which invokes this dependency on {sp}.
All {sp}-based code has been refactored in aqp 2.0 such that there is no reliance on {sp} internals for function results. Current CRAN version (aqp 1.42) is compatible with the sf-based {sp} backend (i.e. "evolution status" 2) and does not require use of rgdal/rgeos.
At this point the SpatialPoints slot of the SPC is unused (superseded by new column metadata identifying geometry columns), and coordinates()proj4string() and their replace methods are deprecated (replaced by initSpatial<- & getSpatial(), prj<- and prj()). We could consider planning changes to the SPC object definition for aqp 2.1.x. The SpatialPoints slot is an "implementation detail" so explicit access of spc@sp has not been encouraged (though it may be used in the wild, as there was no direct accessor for it). Removing the unused @sp slot would be a breaking change to the S4 definition.
My understanding is that this month the evolution status will be updated from 0 to 2 (https://r-spatial.org/r/2023/05/15/evolution4.html). This is expected to continue to have no effect on aqp itself, but users will get the message on load even after this change. Currently the message is issued even when manually setting options(sp_evolution_status=2) before load.
I am creating this issue primarily to identify that these messages from {sp} are a "known" issue in the {aqp} dependency tree; users may be confused by the message but at this point please be assured aqp is consistent with sp evolution process, though still reliant on some sp class definitions for backward compatibility purposes.
The text was updated successfully, but these errors were encountered:
Currently w/ {sp} >=1.6.x the following message is issued on load of aqp (and soilDB, or anything else that imports aqp)
We still import the
SpatialPoints
object and import/export thecoordinates()
method for SoilProfileCollection, which invokes this dependency on {sp}.All {sp}-based code has been refactored in aqp 2.0 such that there is no reliance on {sp} internals for function results. Current CRAN version (aqp 1.42) is compatible with the sf-based {sp} backend (i.e. "evolution status"
2
) and does not require use of rgdal/rgeos.At this point the SpatialPoints slot of the SPC is unused (superseded by new column metadata identifying geometry columns), and
coordinates()
proj4string()
and their replace methods are deprecated (replaced byinitSpatial<-
&getSpatial()
,prj<-
andprj()
). We could consider planning changes to the SPC object definition for aqp 2.1.x. The SpatialPoints slot is an "implementation detail" so explicit access of spc@sp has not been encouraged (though it may be used in the wild, as there was no direct accessor for it). Removing the unused@sp
slot would be a breaking change to the S4 definition.My understanding is that this month the evolution status will be updated from
0
to2
(https://r-spatial.org/r/2023/05/15/evolution4.html). This is expected to continue to have no effect on aqp itself, but users will get the message on load even after this change. Currently the message is issued even when manually settingoptions(sp_evolution_status=2)
before load.I am creating this issue primarily to identify that these messages from {sp} are a "known" issue in the {aqp} dependency tree; users may be confused by the message but at this point please be assured aqp is consistent with sp evolution process, though still reliant on some sp class definitions for backward compatibility purposes.
The text was updated successfully, but these errors were encountered: