[GRASS-user] Stream flow direction map
Nikos Alexandris
nikos.alexandris at felis.uni-freiburg.de
Sun May 2 23:53:46 EDT 2010
Nikos:
[...]
> > 1. As far as I can remember, there are ordering systems that are based on
> > the length of segments (or let's call them branches) of a stream or
> > on the number of "children" branches of that (Strahler), right? If this
> > is correct (for some ordering systems), why is it required to use an
> > elevation and a flow direction map just to order an available/existing
> > (vector) stream network based on a ordering system that do not care
> > about the flow direction?
I now saw (tested) "v.strahler" [1] but it also required an elevation model as
input.
Jarek:
> 1) because none have write it, but the effort of ordering in comparison
> with detail digitization is rather very small. The problem is with
> raster data sets so that tools are rather addressed to raster extraction
> 2) there are more methods of ordering Strahler method is one of them.
> Some methods do require more parameters
Understood. But a simple module to order existing stream networks (according
to ordering systems that do not require more than just the network itself)
would be nice to have ;-)
> 3) Stream ordering is small part of bigger analysis called topological
> or Hortonian analysis of drainage network, it require more parameters
> connected with elevation direction etc....
I have done some of these stuff years ago (also measuring stone-diameters in
the field) using paper and pencil. Unfortunately, I was not lucky to be
informed and become introduced to foss4g earlier :-(. It would have been so
much different...
> > 2. Having a look at the current status of the hydro-modules, there is no
> > way to quickly order a user-provided (i.e. on-display digitised) stream
> > network (which shoud be [in most/any case(s)?] far more positionally
> > accurate than the automatically extracted streams by using an elevation
> > model.
> there is module v.orderna.red created in Spain, look for this,
...can't trace it anywhere...
> btw, It is very easy to write Postgre SQL Query (in version 8.4 and later)
> with recursive capabilities, but it require to build network topology
> first, or GRASS internal topology may be used.
I would ask for examples but I think I have to put a "dot" here. I will
forward the discussion to my friend and if she cares she can join the list and
try-out grass-gis.
> > The available solutions (like carving, as suggested in previous posts in
> > this thread) can use the existing highly-accurate vector stream network
> > to "improve" the elevation model in order to "improve" the stream
> > extraction process, right? But they do not use directly a user-provided
> > stream network, right?
> >
> >
> > *. The idea is a "v.stream.direction" module. It will output a vector
> > stream network. In fact the same (user-provided) stream network that
> > will be used as input but with the addition (as extra attribute(s) or
> > extra map) of the _correct_ direction of each segment to satisfy
> > (together with an elevation
>
> > model) the requirements of "r.stream.order". Something like:
> what means correct direction of each segment?
I (mis-)used the term "correct" here. I meant the flow direction that is
defined according to the algorithm used each time (MFD, SFD?).
> > - input(s): elevation, (vector) streams
> > - output: streams (vector, with the correct flow direction for each
> > segment/stream) _or_ just the directions map (?)
> > The output could be then fed directly to "r.stream.order" for example to
> > order the streams. Of course the question arises "what is the correct
> > direction". But isn't this answered by the algorithms that are already
> > used in r.stream.extract?
---
[1] http://grass.osgeo.org/wiki/GRASS_AddOns#v.strahler
More information about the grass-user
mailing list