achubaty / grainscape Goto Github PK

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.

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().

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:

1. warning users that it may take a lot of memory, and/or crash on very large rasters;
2. finding another way to polygonize rasters in another package;
3. removing this functionality.

The problem with (3) is that you will not be able to make the nice corridor pictures.

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.

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:

• Have a synonym visualise() to work for those in the UK
• Work with output of grain() as well as MPG objects.
• Have an example showing how a geom_raster() or geom_tile() of a patch raster could also be added to the plot

Note 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).

Can visualize be replaced with a plot method for goc objects?

@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.

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).

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

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.

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)

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.

Ideally, this might be put in the help section for MPG() (from #24).

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

see also http://stackoverflow.com/q/31510406/1380598

see http://r-pkgs.had.co.nz/data.html

• inst/extdata/fragmented.asc
• inst/extdata/patchy.asc
• inst/extdata/tiny.asc

• create .Rmd version, which can easily be updated and rebuilt. @ecologics do you have the (sweave?) source file used to build the original vignette pdf?
• update vignette content (e.g., remove SELES and 'Windows only' references)
• change grainscape to grainscape2
• load all required packages (they are in Imports instead of Depends)
• Commit 94d87cc temporarily adds the --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.)

problems building vignette:

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.

• lots of warnings: NAs introduced by coercion (see #14)
• Tutorial 1, Step 3: not all links in the original version of figure 2 appear in the update version.
• Tutorial 1, Step 5: scalar analysis outputs don't match, including Figure 3.
• Tutorial 2, Step 4: different tessellations produced in figure 6 (gsGOCVisualize).
• Tutorial 2, Step 6: different values output from gsGOCDistance.
• Tutorial 3, Step 1: from the text, max(patchyMPGLattice$patchId[], na.rm = TRUE) should return 100, but it returns 104.
• Tutorial 3, Step 3: figure 7, showing the lattice links is totally different in the updated vignette.
• Tutorial 4, Section 2: gsGOCCorridor figure 10 shows different links and a different shortest path.
• Tutorial 4, Section 2: figure 11 shows different tesselation, links, and a different shortest path.
• Tutorial 4, Section 2: figure 12 shows different tessellation and 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:

• Tutorial 1, Step 6: raster 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 NAs, causing the plot to fail. UPDATE follwing bug fix for #32, now runs without error.

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.

with #3, @ecologics how do you feel about the following:

• rename functions to remove the "gs" prefix;
• rename gsGOC class to GOC and gsMPG to MPG;
• rename all 'GOC' methods, removing the "GOC" prefix.

@ecologics

I had made a few comments in the GOC() code, specifically:

• GOC.R#L151 there is no metaData element in this list, so this can probably be removed.
• GOC.R#L153 not sure why this is in here -- what's it doing?
• GOC.R#L187 can these messages be removed, or at least an argument be added to silence them?

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.

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")

create a plot.mpg method which plots the raster component (likely this should be default -- user-specified with an argument?).

how to deal with the igraph component?

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).

corridor() should return a goc corridor object, and a plot() method created for that object.

started, see MPG_algorithm.Rmd

see http://adv-r.had.co.nz/OO-essentials.html

• make sure all classes (e.g., goc, mpg) have class attributed properly assigned
• make sure all classes have inheritance info as needed
• make sure generics are created where needed (e.g., gsGOC, gsMPG)
• make sure methods are defined (e.g., gsGOC.mpg())

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

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.

@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, 37524

The 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)

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.

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).

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)

repo needs to be public

• links to SELES software (http://seles.info) is defunct

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.')

The raster and SpaDES packages do this, providing a quick overview of the most important utilities in the package.

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..

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.

• better default colours (I prefer the greyscale used in the examples over the confusing default raster colours; or use RColorBrewer palette)
• suppress legend as it is not required -- values are simply patch IDs.

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.

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.

• use inherits(object, "foo") instead of class(object), as class may return more than one value
• use is(object, "foo") instead of is.foo(object), as is.foo may not be defined for that class.

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)

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:

• simplifies the object returned by gsMPG(): a list containing the igraph object and the RasterStack

cons:

• accessing specific raster layers requires an additional sublist specification (i.e., instead of myMPG$mpgPlot returning the rasterlayer I might want, I need to use myMPG$mpgStack$mpgPlot)

other:

• we could keep the mpgPlot raster (see #11) and add it to the stack

@ecologics thoughts?

Probably should rename, given the canonical nature of the raster package.

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:

1. if you are using git, make sure to update your remote path to github.com/achubaty/grainscape.git;
2. when reinstalling the package, make sure you use: devtools::install_github('achubaty/grainscape');
3. when loading the package, be sure to use library(grainscape);
4. GitHub.com will temporarily redirect you from github.com/achubaty/grainscape2 to github.com/achubaty/grainscape, but you should update your bookmarks etc. in your browser.

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.

classes

• mpg
• goc
• hce
• grain
• corridor

methods

• corridor
• distance
• GOC
• grain
• graphdf -- this one is probably the easiest to start with: compare an igraph object to the resulting data.frame
• MPG -- current tests for #32 check the igraph object but not the produced raster.
• point
• thresholds

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.

• http://grainscape.r-forge.r-project.org/ should be updated to indicate that development is now taking place on GitHub
• the R-forge package version should be updated to message the user regarding the latest version on GitHub