[GRASS-user] Stream flow direction map

[Jarek Jasiewicz]

Nikos Alexandris pisze:
> (
> The following question(s) might be already answered and I just miss the  
> hydrological background to understand "why is not possible to...". If it is 
> the case, scratch-out this post entirely
> )
>
> Nikos:
>   
>>> Ideally, I imagine a module like:
>>>  "v.stream.directions elevation=HighResolutionDEM streams=StreamNetwork 
>>>  output=StreamNetwork_WITH_directions"
>>>       
>
> Maybe this idea was wrong. The "problem to be solved" that I have in mind is 
> the following:
>
> Let's say the user (as it is the case of my friend) has digitised from scratch 
> highly accurate (concerning the position) and topologically clean (vector) 
> streams and  wants to order them (according to the usual suspect systems... 
> Strahler, etc.).
>
>
> 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?
>   
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
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....
>
> 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, 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.
> 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?
>   - 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?
>
>
> --%<---
> # as a side-note: why does for example:
> "r.stream.extract elevation=elevation_10m direction=TEST_direction 
> threshold=100"
>
> fail to run the error message:
>
> "ERROR: Sorry, you must choose at least one output map."
>
> Isn't the direction map an output on its own (enough?). A bug?
> ---%<--
>
> Nikos
>