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

[Markus Metz]

On Sun, Feb 6, 2011 at 12:05 AM, Colin Wren <colindwren at gmail.com> wrote:
> 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.
>
You're right. It would be too costly for a hiker to tackle a waterfall.

> 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.
>
Not that I know. For SFD-like drainage direction (each cell has only
one direction to follow), this should not be too hard. A simple FIFO
linked list of cells to process and some flag to check if a cell is in
the list could do the trick. I think there are also requests for such
functionality somewhere in the ml archive.

Markus M

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