[GRASS-user] Re: least cost path between patches

[Patrick Giraudoux]

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