[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