achubaty / grainscape Goto Github PK
View Code? Open in Web Editor NEWEfficient Modelling of Landscape Connectivity, Habitat, and Protected Area Networks
Home Page: https://alexchubaty.com/grainscape
Efficient Modelling of Landscape Connectivity, Habitat, and Protected Area Networks
Home Page: https://alexchubaty.com/grainscape
from the example in MPG()
:
library(igraph)
library(raster)
tiny <- raster(system.file("extdata/tiny.asc", package = "grainscape"))
tinyCost <- reclassify(tiny, rcl = cbind(c(1, 2, 3, 4), c(1, 5, 10, 12)))
tinyPatchMPG <- MPG(cost = tinyCost, patch = (tinyCost == 1))
plot(tinyPatchMPG, col = c("grey", "black"), legend = FALSE)
## Produce a patch-based MPG with a study area consisting of half of the map
tinySa <- tinyCost
tinySa[] <- 1
tinySa[1:5000] <- 0
tinySaMPG <- MPG(cost = tinyCost, patch = (tinyCost == 1), sa = tinySa)
plot(tinySaMPG)
Without looking more closely, this may simply be an issue with how the mpgPlot
is being created, rather than an issue with the mpg
itself.
see http://adv-r.had.co.nz/OO-essentials.html
goc
, mpg
) have class attributed properly assignedgsGOC
, gsMPG
)gsGOC.mpg()
)the change was introduced in 16d5c53
#' ## Load raster landscape
#' tiny <- raster::raster(system.file("extdata/tiny.asc", package = "grainscape"))
#'
#' ## Create a resistance surface from a raster using an is-becomes reclassication
#' tinyCost <- raster::reclassify(tiny, rcl = cbind(c(1, 2, 3, 4), c(1, 5, 10, 12)))
#'
#' ## Produce a patch-based MPG where patches are resistance features=1
#' tinyPatchMPG <- MPG(cost = tinyCost, patch = (tinyCost == 1))
#'
#' ## Extract a representative subset of 5 grains of connectivity
#' tinyPatchGOC <- GOC(tinyPatchMPG, nThresh = 5)
#'
#' ## Examine the properties of the GOC graph of grain 3 of 5
#' graphdf(grain(tinyPatchGOC, nThresh = 3)) ## fails due to missing `whichThresh` argument
started, see MPG_algorithm.Rmd
This was an interesting idea to develop several years ago, but it really needs to be motivated properly in its own paper. I think for the time being we should not prioritize its development and exclude it from the initial presentation of this software.
We can either remove it, or classify it as an experimental function and not draw attention to it in vignettes, or manuscripts. At best it is experimental.
Consider adding warnings in MPG()
around line 168 if any of the patchArea
sizes are 1 cell in size.
While these still work, it may be useful for the user to know this and be encouraged to filter them out for improved interpretability of the output.
For example:
warning('grainscape: Patches of only 1 pixel in size are present. You may wish to remove them to improve interpretation of your connectivity models. Use patchfilter() to do this.')
create a plot.mpg
method which plot
s the raster component (likely this should be default -- user-specified with an argument?).
how to deal with the igraph component?
The following clip from @cxfauvelle input raster can be used to demonstrate this problem.
naErrorExample.zip
res <- raster("naErrorExample.asc")
resMPG <- MPG(res, patch=res==1)
## Red areas are NA
plot(is.na(res), col=c("white", "red"))
## Superimpose the mpgPlot and see the orphaned links
plot(res$mpgPlot, add=TRUE)
As below where red areas are NA and green areas are real patches (==1).
Other spatial packages in R do not give warnings about things like projection. I think we don' t need to hold the user's hand here. It is only in cases where unprojected rasters (i.e. where projection(ras)
contains '+proj=longlat ...'
) are used that things are not meaningful.
Perhaps we should remove these warnings based on the size of raster cells, and just flag a warning when we see "longlat"
in the proj4
string.
graphdf(myMPG)[[1]]$e
yields startPerimX
and startPerimY
and endPerimX
and startPerimY
variables that appear to be unitless. They do not appear to refer to the cell number on the raster either.
They should be in the coordinate reference system of the raster to be of any use to anyone.
I am about to push changes that will rename the package.
@ecologics @samdoctolero @cxfauvelle this will cause some minor issues for you in terms of workflow:
github.com/achubaty/grainscape.git
;devtools::install_github('achubaty/grainscape')
;library(grainscape)
;Use the ggnetwork
package which is designed for creating network visualizations as ggplot2
objects. It has geom_edges()
and geom_nodes()
geoms. It also has a fortify.network()
function that calls another package. It is not especially useful for spatially-referenced networks (such as these), but when a fortify.network(..., layout=data.frame(xcoord, ycoord))
call is passed to it it will lay out the nodes according to their actual coordinates, rather than coordinates that correspond to some node layout algorithm.
However there appear to be some bugs or annoyances with the ggnetwork
workflow. So creating a tight visualize()
function that produces a ggplot2
object and deals with these, is probably necessary.
Ideally the visualize()
function should:
visualise()
to work for those in the UKgrain()
as well as MPG
objects.geom_raster()
or geom_tile()
of a patch raster could also be added to the plotNote that briefly there was a visualize()
function and a gsGOCVisualize
function and that these were deprecated. This function will have completely different functionality, and is unlikely to cause problems among users as visualize()
was only temporarily in use (and not on the RForge release).
raster::rasterToPolygons()
which presumably still relies on the rgeos library functionality, has had a serious memory leak problem for almost five years. And no-one seems to care enough about it to fix it.
Cat reported that she ran out of memory when vectorizing something (not as part of visualize(.., sp=TRUE)
but rather another application of rasterToPolygons()
).
Ways forward either involve:
The problem with (3) is that you will not be able to make the nice corridor pictures.
This uses the raster
function rasterToPolygon()
which is based on an rgeos
function which has long been known to have memory leak. I woul dhave hoped that newer versions of the GEOS
library would have fixed this problem. But all in vina.
Indeed use of this function ever since I developed this several years ago always consumes all available memory.
Quite simply we will need to remove this functionality from the GOC()
function because it doesn't work. It's too bad as it creates really great visualizations if you can coax it into operation. A test I ran last night blew up on a moderate raster (2000 x 3000 cells).
Ideally, this might be put in the help section for MPG()
(from #24).
filterPatch
and spreadFactor
are no longer used, as they were Andrew Fall's parameters.
The first is still useful, but I think it needs to be up to the researcher to prefilter out patches below a threshold number of cells. There is always a danger in helping the user too much! What do you think @achubaty? Too many patches can be hard to interpret. And one cell patches are also of questionable utility and accuracy. Worth implementing?
The second is a legacy option from Andrew Fall and allowed control over how graph was extracted for speed purposes. It could be that variance in Sam's implementation with respect to this variable is leading to differences in resulting graph. Not relevant, so remove.
sa
parameter. See discussion in other issue (#23).
Using the NA
test case from #28, note that not all patches end up linked:
f <- "naErrorExample.asc"
r <- raster(f)
c <- r
p <- (r == 1)
mpg <- MPG(cost = c, patch = p)
plot(mpg)
I am going back and forth on this. I think a middle ground is appropriate.
I propose the following:
A new function called ggGS()
which is very simple. It will take either an MPG
or grain
object and a second parameter with the slot name, and possibly a third parameter.
If it is a raster it will prep that raster by turning it into a data.frame
with columns x
, y
, and value
so that it can be used with geom_raster()
in ggplot2
as follows:
ggplot() + geom_raster(ggGS(myMPG, "patchId"), aes(x=x, y=y, fill=value)
If it is an igraph
object and a type
parameter ='node'
it will produce a data.frame
with the nodes and attributes. If type='link'
it will produce a data.frame
with the links, their endpoints and attributes. For example:
ggplot() + geom_segment(ggGS(myMPG, "mpg", "link"), aes( ...)) # etc
In this sense it is basically a fortify tool for tidying objects for ggplotting.
When this functionality is developed, it will be simple to create a plot()
for class MPG
and grain
that takes a second variable specifying the type of plot. It will then wrap these calls to produce canned quick visualizations with various other elements (e.g. themes, scales and layouts) preset for a fast look at the state of the data.
click the badges below to see more detailed coverage info:
branch | coverage status |
---|---|
master |
|
development |
see http://r-pkgs.had.co.nz/tests.html
NOTE: this list is likely incomplete.
mpg
goc
hce
grain
corridor
corridor
distance
GOC
grain
graphdf
-- this one is probably the easiest to start with: compare an igraph object to the resulting data.frameMPG
-- current tests for #32 check the igraph object but not the produced raster.point
thresholds
The pre-amble to each of the examples is the same, so there is no point in duplicating the code.
Move all examples into separate files and consolidate where possible.
Probably should rename, given the canonical nature of the raster package.
repo needs to be public
That will remove patches smaller than a threshold number of pixels (or area) and could be called as follows MPG(costRas, patch=patchfilter(patchRas))
.
This may be important, as very tiny patches can make visualizations hard to understand, and they don't always behave nicely. For example, single pixel patches can be orphaned when surrounded (mostly) by NAs. This can also make things a little bit nonintuitive..
The raster
and SpaDES
packages do this, providing a quick overview of the most important utilities in the package.
.Rmd
version, which can easily be updated and rebuilt. @ecologics do you have the (sweave?) source file used to build the original vignette pdf?grainscape
to grainscape2
--no-build-vignette
option to the RStudio project for building & checking. This needs to be reverted once the vignette has been updated. (reverted with 0e05af5.)I haven't looked at everything in detail, so I'm sure there are other problems not listed here.
To debug these, we should start with the first functions in the sequence (gsMPG()
and gsGOC()
) to make sure they are correct before attempting to debug the others.
NAs introduced by coercion
(see #14)gsGOCVisualize
).gsGOCDistance
.max(patchyMPGLattice$patchId[], na.rm = TRUE)
should return 100
, but it returns 104
.gsGOCCorridor
figure 10 shows different links and a different shortest path.In the voronoi plots, the colours make it difficult to see how different the plots are in each vignette.
NOTE: I've temporarily commented out the following chunks that fails:
patchyMPG$lcpPerimWeight
used to create raster thresholdLink
contains values between 201-810, none of which are <=200
specified to create the latter, resulting in a raster of all NA
s, causing the plot to fail. UPDATE follwing bug fix for #32, now runs without error.For example:
tiny <- raster(system.file("extdata/tiny.asc", package = "grainscape"))
tinyCost <- reclassify(tiny, rcl = cbind(c(1, 2, 3, 4), c(1, 5, 10, 12)))
tinyPatchMPG <- MPG(cost = tinyCost, patch = (tinyCost == 1))
## Extract a GOC for only one threshold given the doThresh option
## Here doThresh references the threshold value in resistance units
tinyPatchGOC <- GOC(tinyPatchMPG, doThresh = 21)
## FAILS
visualize(tinyPatchGOC, whichThresh = 21)
## WORKS because it is the first and only indexed
## threshold produced bu GOC()
visualize(tinyPatchGOC, whichThresh = 1)
Need some way to deal with this.
Here's the original cost surface raster with NA regions the rectangular chunks at the borders of the image.
Here's what it looks like when grain()
is run on it, and the various spatial outputs are plotted. Note the errant centroid in the top middle region. It appears to be associated with the centroid of the NA cells on the raster. Links are wacky as well, corresponding likely to this centroid throwing everything off. This is a hard to notice problem on simple rasters like this, but very obvious on large real-world rasters, which tend to have NAs around the edges as they are irregular regions of interest. The result is cases where links go every which way in a meaningless pattern when grain()
is used to extract a GOC. Visualizations of MPG()
outputs are perfect however!
Here is some reproducible code:
## Make a raster with NA values around edge
## as would typically occur in most GIS applications
tiny <- raster(system.file("extdata/tiny.asc", package = "grainscape"))
tinyCost <- reclassify(tiny, rcl = cbind(c(1, 2, 3, 4), c(1, 5, 10, 12)))
tinyCostNA <- tinyCost
tinyCostNA[0:40, 0:40] <- NA
tinyCostNA[0:20, 60:100] <- NA
tinyCostNA[50:80, 90:100] <- NA
tinyCostNA[90:100, 0:80] <- NA
## Extract MPG and GOC
tinyCostNAMPG <- MPG(tinyCostNA, tinyCostNA==1)
tinyCostNAGOC <- GOC(tinyCostNAMPG, 5, verbose=10)
## Use new export function to create simple to visualize things
spExport <- export(grain(tinyCostNAGOC,4), R=TRUE, vorBound=TRUE)
badCentroids <- spExport$nodes
badLinks <- spExport$linksCentroid
vorBound <- spExport$vorBound
## Plot
plot(vorBound, col=c("NA", "black"))
plot(badCentroids, add=TRUE, col="red", cex=2, pch=20)
plot(badLinks, add=TRUE, col="red")
@cxfauvelle reports the following failure after running MPG() on a large raster:
Error: cannot allocate vector of size 472.7 Mb
I am assuming that this is occurring because R does not have the overhead to handle the data that is being shipped back from the C++ code. It remains uncertain whether this is particular to the hardware @cxfauvelle is using (i.e. not enough overhead memory) or it is truly because the code has not been designed to handle the passing back of massive vectors.
inherits(object, "foo")
instead of class(object)
, as class
may return more than one valueis(object, "foo")
instead of is.foo(object)
, as is.foo
may not be defined for that class.I had made a few comments in the GOC()
code, specifically:
metaData
element in this list, so this can probably be removed.A vignette of how you might use MPG()
and GOC()
in a parks and protected area connectivity scenario. Ideally this would also be supplementary material on a publication on this software.
Ideally export(directory)
will take either a MPG
or GOC
object and save a series of raster files and perhaps vector representation of the minimum planar graph into a new directory
as specified. Much of the code to do this already exists in a script.
Currently grain()
creates a new voronoi raster by reclassifying the voronoi raster at a threshold thresh
to reflect the igraph
contained in a GOC
object (i.e. myGOC@th[[thresh]]
).
Add new functionality to grain()
so that it also extracts the myGOC@th[[thresh]]
object and places it into the output of grain()
as these igraph
objects are currently deeply buried, This will have the added advantage of allowing grain()
objects to be plotted using visualize()
.
with #3, @ecologics how do you feel about the following:
gsGOC
class to GOC
and gsMPG
to MPG
;This does not work properly, probably because the lcpLinkId
raster was not calculated properly. This is something that I suggested to Sam that he just ignore. So he must have tried to correctly figure out the minimum spanning tree links, but I suspect did not do it properly.
The simplest thing to do would be just to remove this example from the help, and not draw attention to lcpLinkId
.
not sure where these are coming from, as they only appear when doing test(".", "examples")
and not when running examples interactively.
Warnings ----------------------------------------------------------
1. ../../man/patchFilter.Rd (@patchFilter.R#15) - no non-missing arguments to min; returning Inf
2. ../../man/patchFilter.Rd (@patchFilter.R#15) - no non-missing arguments to max; returning -Inf
3. ../../man/patchFilter.Rd (@patchFilter.R#20) - no non-missing arguments to min; returning Inf
4. ../../man/patchFilter.Rd (@patchFilter.R#20) - no non-missing arguments to max; returning -Inf
5. ../../man/patchFilter.Rd (@patchFilter.R#26) - no non-missing arguments to min; returning Inf
6. ../../man/patchFilter.Rd (@patchFilter.R#26) - no non-missing arguments to max; returning -Inf
Can visualize
be replaced with a plot
method for goc
objects?
since all rasters placed in list returned by gsMPG()
have the same resolution, extent, etc. just with different values, it might make sense to stack()
them.
pros:
gsMPG()
: a list containing the igraph object and the RasterStackcons:
myMPG$mpgPlot
returning the rasterlayer I might want, I need to use myMPG$mpgStack$mpgPlot
)other:
mpgPlot
raster (see #11) and add it to the stack@ecologics thoughts?
Not sure how to enable this for travis-ci/appveyor builds (#7). Without it, CI builds are failing due to warning:
checking sizes of PDF files under ‘inst/doc’ ... WARNING
‘gs+qpdf’ made some significant size reductions:
compacted ‘grainscape_tutorial.pdf’ from 517Kb to 238Kb
consider running tools::compactPDF(gs_quality = "ebook") on these files
not sure how to fix, but it looks like there is a conflict between xcode's version of things and R/Rcpp's.
E.g., the length
defined in Rinternals.h
and that used in xcode's iostream
/ ios
In file included from rcpp_HabConnEngine.cpp:3:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/Rcpp.h:27:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/RcppCommon.h:51:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:869:34: error: too many arguments provided to function-like macro invocation
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Library/Frameworks/R.framework/Resources/include/Rinternals.h:1222:9: note: macro 'length' defined here
#define length(x) Rf_length(x)
^
In file included from rcpp_HabConnEngine.cpp:3:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/Rcpp.h:27:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/RcppCommon.h:51:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:869:15: error: expected ';' at end of declaration list
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:954:34: error: too many arguments provided to function-like macro invocation
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Library/Frameworks/R.framework/Resources/include/Rinternals.h:1222:9: note: macro 'length' defined here
#define length(x) Rf_length(x)
^
In file included from rcpp_HabConnEngine.cpp:3:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/Rcpp.h:27:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/RcppCommon.h:51:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:954:15: error: expected ';' at end of declaration list
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:1038:34: error: too many arguments provided to function-like macro invocation
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Library/Frameworks/R.framework/Resources/include/Rinternals.h:1222:9: note: macro 'length' defined here
#define length(x) Rf_length(x)
^
In file included from rcpp_HabConnEngine.cpp:3:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/Rcpp.h:27:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/RcppCommon.h:51:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:1038:15: error: expected ';' at end of declaration list
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:1124:34: error: too many arguments provided to function-like macro invocation
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
/Library/Frameworks/R.framework/Resources/include/Rinternals.h:1222:9: note: macro 'length' defined here
#define length(x) Rf_length(x)
^
In file included from rcpp_HabConnEngine.cpp:3:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/Rcpp.h:27:
In file included from /Users/achubaty/Library/R/3.3/library/Rcpp/include/RcppCommon.h:51:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iostream:38:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:216:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__locale:1124:15: error: expected ';' at end of declaration list
int length(state_type& __st, const extern_type* __frm, const extern_type* __end, size_t __mx) const
^
8 errors generated.
make: *** [rcpp_HabConnEngine.o] Error 1
ERROR: compilation failed for package ‘grainscape2’
* removing ‘/private/var/folders/l2/hy6b0sl977bcd8695nt6j7s80000gn/T/RtmpeI2u6V/devtools_install_1c8e2470f9bd/grainscape2’
Error: Command failed (1)
Execution halted
Exited with status 1.
The following reprex shows the problem:
patchy <- raster(system.file("extdata/patchy.asc", package = "grainscape2"))
patchyCost <- reclassify(patchy, rcl = cbind(c(1,2,3,4,5), c(1, 10, 8, 3, 6)))
patchyMPG <- gsMPG(patchyCost, patch = (patchyCost == 1))
patchyGOC <- gsGOC(patchyMPG, nThresh = 100)
From the gsMPG
help docs:
Four types of links are identified in the MPG (1=Nearest neighbour; 2=Minimum spanning tree; 3=Gabriel; 4=Delaunay;)
I don't believe these are currently being calculated / returned, so the question is whether they should/need to be.
see http://r-pkgs.had.co.nz/data.html
inst/extdata/fragmented.asc
inst/extdata/patchy.asc
inst/extdata/tiny.asc
raster
colours; or use RColorBrewer
palette)corridor()
should return a goc corridor object, and a plot()
method created for that object.
Now that we have people using the package, we can't let the master branch be broken.
@samdoctolero @ecologics please use the new development
branch for all work, and ensure changes are tested by running R CMD check
in Rstudio before committing and pushing.
We can periodically merge good/passing commits to master as we implement new features etc.
This should be straightforward to fix. Better also check if grainscape::distance()
also fails when passed coordinates on NA cells.
Reproducible example:
## Make a random raster with a border of NA values
.makeRaster <- function(dim, naBorder=NULL, FUN=function() floor(rgamma(dim*dim, 2.5)) + 1) {
require(raster)
ras <- raster(xmn=0, xmx=dim, ymn=0, ymx=dim, resolution=1)
ras[] <- FUN()
if (!is.null(naBorder)) {
ras[1:naBorder, ] <- NA
ras[, 1:naBorder] <- NA
ras[(dim-naBorder):dim, ] <- NA
ras[, (dim-naBorder):dim] <- NA
}
return(ras)
}
## Create a random raster with a border of five NA cells
cost<- .makeRaster(100, 5)
## Extract MPG and GOC
mpg <- MPG(cost, cost==1)
goc <- GOC(mpg, nThresh=5, verbose=10)
## Create coordinates inside and outside NA border
coordFails <- rbind(c(2,2), c(98, 98))
coordWorks <- rbind(c(10,10), c(90, 90))
## Fails
try(corridorFails <- corridor(goc, whichThresh=2, coordFails))
## Works
corridorWorks <- corridor(goc, whichThresh=2, coordWorks)
## And plot to test the new plot() functionality
plot(corridorWorks)
@cxfauvelle reports the following in an email to me:
Trying to run a raster so I can get my "spatial" treatment and at first I was getting the usual "cannot allocate vector of size x" but I got that sorted away, and now I'm getting this fun new error message:
Error in data.frame(name = uniquePatches, patchId = uniquePatches, patchArea = patchArea, :
arguments imply differing number of rows: 37525, 37524The raster I'm using is the same as the last one but with roads added into it. It has no NA values, and no values of 0. I can't attach it because it's too large, but I uploaded it to Google Drive (link: https://drive.google.com/open?id=0B7_JxCEZXN7BbXdhRDB4YVRmM2s)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.