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 _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user