Comments (7)
I have read up on this topic and it seems that we can stay on raster, and probably should, so long as we can lose our dependency on rgeos
and rgdal
. One obvious way to do this is to set the imported version of raster to be at or after the version where it's changed to no longer depend on these packages. We shall also have to comb through our imported packages and functions to figure out which ones may be causing a dependency on the retiring packages.
from poems.
I have made a list of imported/suggested packages with problematic dependencies.
gdistance
geosphere
raster v3.4.5
(current version is okay)
So we just need to tick up the version of raster
that poems
depends on and find replacements for the imported gdistance
and geosphere
packages.
from poems.
I don't think we need a replacement gdistance
as they're slowly adding some additonal methods to handle the conversion from raster
to terra
. This process started a while ago AgrDataSci/gdistance#3. It means we won't need to convert to terra
and then back to raster
if the conversion is handled on their end.
The dev version of leastcostpath seems to do something similar but uses terra instead of raster which means we would have to add a function to do the conversion, which possibly (?) brings up the issue of parallel processing with terra objects that I mentioned above. They also don't interally do the conversion if a raster
object is passed.
leastcostpath::create_cs(x = as.raster(r), neighbours = 16, dem = NULL, max_slope = NULL)
Error in (function (classes, fdef, mtable) :
unable to find an inherited method for function ‘values’ for signature ‘"raster"’
The output of leastcostpath::create_cs()
provides a conductance matrix - see the create_cs
function and example. I don't know how much effort would be involved in rewriting poems
to use this and the output from create_cs
. But as it uses terra
I think switching to it is more hassle than it's worth.
The geosphere
package is written by the author of raster
and terra
so I would be surprised if he let it become obsolete. Let's assume that it does however - I think the best alternative (and IMO something we really should have done from the start), would be to force only projected coordinates to be used for any spatial model. My understanding is geosphere
is only used in poems
for calculating dispersal distances on non-projected data? If people want to use poems
to make a spatially explicit model, it must use projected coordinates or else the region won't be created and the model won't run. I think the easist way would be through a check in the Region object.
Adding a check to here to make sure the CRS is projected if a region raster is provided: https://github.com/GlobalEcologyLab/poems/blob/b0e18f52b2877593e6f750548f3bdc63d750607f/R/Region.R#L178C1-L178C1
Would force the region to be projected. Something like this.
region_raster = function(value) {
if (missing(value)) {
if (is.null(private$.region_raster) && !is.null(private$.coordinates) && self$use_raster) {
## if coordinates are provided assume EPSG:4087. Issue warning to use raster object instead
## https://epsg.io/4087
warning("CRS for cooordinates assumed to be EPSG:4087 (https://epsg.io/4087).\nSuggest providing a raster instead of coordinates.",
immediate. = TRUE, call. = FALSE)
raster::rasterFromXYZ(cbind(private$.coordinates, cell = 1:nrow(private$.coordinates)),
crs = "EPSG:4087")
} else {
private$.region_raster
}
} else {
if (raster::isLonLat(value)) {
stop("Region raster must use a projected CRS", call. = FALSE)
}
if (!is.null(value) && !("RasterLayer" %in% class(value))) {
stop("Region raster should be a raster::RasterLayer (or inherited class) object", call. = FALSE)
}
if (!is.null(value) && !is.null(private$.coordinates)) {
stop("Region is already associated with a set of coordinates", call. = FALSE)
}
if (raster::fromDisk(value)) { # move to memory
raster::values(value) <- raster::values(value)
}
private$.region_raster <- value
}
}
We would need an additional check if coordinates instead of a raster is passed to the region. Something to stop if the x coordinates are within -365 and 365 and the y coordinates are within -90.1 and 90.1.
from poems.
So in summary, it seems the problem will resolve on its own if we just wait a bit for geosphere
and gdistance
to get off of rgeos and rgdal.
from poems.
The new plan is to keep raster
for now and shift functions away from geosphere
and gdistance
, which are still stuck on using sp
.
from poems.
Like I mentioned in my earlier comment, the geosphere
dependency can be resolved by forcing people/groups to use projected coordinates. It is only used for calculating distances when lat/long rasters or coordinates are given. It's a really simple fix, and in my opinion, a conditon which probably should've been enforced from the beginning of package development.
There is also no need to migrate away from gdistance
as sp
isn't being removed from CRAN or even retired. Internally, sp
has been migrated to use sf
instead of rgdal
, rgeos
, and maptools
. Those three packages are being retired and removed very soon, any packages which don't require a sp
version after those functions have been transitioned to use sf
will fail. gdistance
only uses a single sp
function which will be affected by the transition - sp::CRS
. See here - https://r-spatial.org/r/2023/05/15/evolution4.html. As long as the latest version of sf
is used, sp
will use the sf
package to extract the CRS and it won't be an issue. The easist fix is to force a version dependency for sp
and sf
in poems
DESCRIPTION file - probably under suggests as we don't actually use the packages in any functions, but it will force any downstream packages to use the latest versions.
From a quick look, gdistance
only uses sp::CRS
when coordinates are given or for showing the least cost path between two points. The transition layers, barriers, cost distance etc. are all created from raster inputs. As poems
passes a raster through to all the gdistance
functions, poems
is not affected by any of the changes.
from poems.
from poems.
Related Issues (2)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from poems.