[GRASS-user] r.terraflow for cost path analysis

[Markus Metz]

On Fri, Feb 4, 2011 at 9:13 PM, Colin Wren <colindwren at gmail.com> wrote:
> A recent article published in the Journal of Archaeological Science
> (http://dx.doi.org/10.1016/j.jas.2010.11.006) proposed a method where
> hydrology models could be used on the product of a cost surface
> analysis to create a network of paths (instead of just the one made
> with r.drain -d). The flow accumulation map would represent the number
> of cells in the map from which a least-cost path would pass through
> that cell. ie. a flow accumulation of 100 means that 100 cells would
> have a LCP that would pass through that cell. You could also calculate
> mobility basins (like a watershed), etc.
>
> This is great extension of cost surface analysis except that I don't
> think it can be done in GRASS right now. r.cost and r.walk produce a
> cumulative cost surface and a "flow" direction surface, but if I'm
> right r.terraflow can't take them as inputs because it calculates
> everything "in-house".
>
> I was hoping someone could double-check my logic on this or perhaps
> suggest an alternative hydrology module(s) which could take the
> direction surface as an input instead of calculating everything from
> the elevation surface.
>
If the starting points used to generate cumulative cost surfaces are
not located at the edges of the current region or if they are not
bordering at least one NULL cell, they will be located in what is
called in hydrology sinks or depressions because the starting points
will be surrounded by cells with values higher than the starting
points. r.terraflow like most other hydrological modules removes these
sinks, altering the surface which is in this case not desired.

The GRASS modules r.watershed and r.stream.extract do not modify the
surface and use it as it is. These two modules use a LCP search to
determine flow directions and accumulate flow and would therefore be
suitable for the extraction of a network of paths, as long as these
modules stop routing flow when a starting point is reached. This is
currently only implemented in r.stream.extract where the rasterized
starting points which should have a cost of zero in the cumulative
cost surface can be used to define real depressions (this is also
possible in r.watershed, but for technical reasons r.watershed will
not produce the desired results in this case). r.stream extract will
then use these starting points indicating real depressions or ultimate
sinks without outflow as starting points for its LCP search. The LCP
path for a given cell can then be recovered by tracing back the LCP
search (flow direction in hydrology) to the nearest starting point. A
direction map is not needed, directions are calculated from the
(cumulative cost) surface. The calculated directions may differ in
ambiguous cases, e.g. for

7 4 7
6 5 6
7 4 7

the cell with the cumulative cost value 5 can be reached from either
of the two cells with cumulative cost value 4, i.e. the LCPs from the
cell with value 5 going through these two cells are both a valid
solution. The extracted network would represent paths used by at least
<threshold> cells, e.g. at least 100 cells would have a LCP that would
pass through a cell that is part of a path network. In
r.stream.extract, the option d8cut must be zero to enforce SFD.

Mobility basins can then be determined with r.stream.basins.

HTH,

Markus M