Le 27/02/2011 22:28, Tristan Nunez a écrit :
Hi Patrick,
If I understand the question, I haven't done this in GRASS, but one
cumbersome approach without using a function like r.drain to find a
cost distance *corridor* between two patches is to calculate a
separate cost distance surface for every individual patch, from (and
only from) that individual patch. Then, for each pairwise combination
of two patches that you want to find the least cost path for, you add
together (or average them; gives similar results) the two resulting
cost distance surfaces for those individual patches, which gives you
an accumulative cost distance surface of the cost involved in moving
from any one pixel to BOTH patches - basically, a corridor. Basically,
there will be a row of pixels between the two cores with the lowest
cost values of the accumulative cost distance raster, which is the
least cost path. You can either extract out all the pixels with the
lowest values or perhaps use a tool like r.drain to find the least
cost path (LCP) itself - I haven't done this in GRASS but I believe it
can be done.
I think you can use r.drain directly to find the LCP - but
importantly, I think it uses the backlink (direction) raster from
r.cost as an input to calculate LCPs; if you're connecting, say,
patches A and B with an LCP, I think what you do is calculate a cost
surface and backlink raster from patch A, then use r.drain to
calculate to calculate the LCP by putting in patch B as your starting
point, plus the cost surface and backlink raster from the calculation
using patch A. If I'm not mistaken you have to do this on a pairwise
patch-to-patch basis, and you'll want to make sure you're using the
backlink raster. Also, if you're using one of the binary releases for
Windows, for some of this you have to use the r.cost and the r.drain
module from version 6.5.1 or later (do a search to find the patches on
those modules); there's an older version in the WIN 6.4 release that
doesn't produce a backlink and thus makes it hard to do this kind of
calculation. You might also take a look at some tools built in other
GIS platforms for ideas on this kind of connectivity analysis,
particularly www.corridordesign.org, Funncon
(http://www.nrel.colostate.edu/projects/starmap/FUNCONN%20Users%20Manual_public.pdf),
www.circuitscape.org; there are others currently in development by
conservation organizations in the US that should come online in the
near future.
Hope that helps,
Tristan
Thanks for this very detailed answer. Sure it will help. Actually, I
have worked yesterday on this issue and this led to a similar strategy.
I have explored the following:
1/ consider one patch (converted to raster) at a time (say patch A) and
compute the corresponding cost distance surface
2/ for each other pach (polygon vector converted to line then to point -
to just consider the border points) compute the LCP from patch A and its
length (= number of pixels, with r.stats -c piped to head and cut)
iteratively for all points and keep the shortest LCP
This has still to be implemented in a batch file, now. Some lines of
programmes are already written. However, I suppose computing will be
time consuming if paches and patch border points are many....
Best,
Patrick
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
