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

[Colin Wren]

Thanks Markus, but unfortunately this module won't work either. The
direction surface of a cost surface analysis can't be re-created by a
hydrology "drainage" steepest descent algorithm. This was why the -d
flag was added (by me under a different name actually :) to r.cost,
r.walk, and r.drain. It makes sense if you think about the elevation
profile of a drainage algorithm path versus a walking algorithm path,
the first makes an exponential curve while the second should make a
linear path (roughly). You don't want to save up the hardest part of
the hike for the end.

Ideally I would need an algorithm which calculates accumulation from a
direction map only. The cost surface itself is not needed. I was
hoping a suite of hydrology modules would first calculate flow
direction and then a second module would calculate flow accumulation
from the direction. Maybe I'll just have to write an addon module for
it if one doesn't exist.

Cheers,
Colin

On Sat, Feb 5, 2011 at 11:44 AM, Markus Metz
<markus.metz.giswork at googlemail.com> wrote:
> 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
>