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.
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.
v.surf.icw is an IDW interpolation method using true distance cost instead of euclidean shortest distance, i.e. as the fish swims around an island not as the bird flies. This will cleanly travel around hard barriers and a cost surface map may be used to model expensive-cross barriers. Input data points do not need direct line of sight to be considered, but should be kept to less than one hundred as the module becomes very computationally expensive. A number of radial basis function options are available.
screenshot: http://grass.osgeo.org/grass-wiki/images/Inlets_03_SurfSal_icw_big.png
On Fri, Feb 4, 2011 at 9:13 PM, Colin Wren <colindwren@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.
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@googlemail.com> wrote:
On Fri, Feb 4, 2011 at 9:13 PM, Colin Wren <colindwren@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.
On Sun, Feb 6, 2011 at 12:05 AM, Colin Wren <colindwren@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@googlemail.com> wrote:
On Fri, Feb 4, 2011 at 9:13 PM, Colin Wren <colindwren@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.
to r.cost,