[GRASS-user] Stream flow direction map

GRASS GRASS user
1

Hi list!

I am sort of forwarding a friends question related to hydro-processing.

While there is a proper (vector) contour map and a very clean stream network
map (digitised from scratch upon topographic maps of 1:50.000) available, the
flow direction map is missing.

Is this information easily calculated based on available dem(s), stream
network(s)? Or should _definitely_ the user add this information while
digitising the streams?

I have read many past threads wrt "streams, flow, direction, accumulation" but
could not trace an answer to the above question.

Thanks, Nikos

2

On Saturday 01 of May 2010 05:30:04 Nikos Alexandris wrote:

I am sort of forwarding a friends question related to hydro-processing.

While there is a proper (vector) contour map and a very clean stream
network map (digitised from scratch upon topographic maps of 1:50.000)
available, the flow direction map is missing.

Is this information easily calculated based on available dem(s), stream
network(s)? Or should _definitely_ the user add this information while
digitising the streams?

I have read many past threads wrt "streams, flow, direction, accumulation"
but could not trace an answer to the above question.

I read again some stuff and I guess that this is a very basic and simple
"hydro-gis" question (for which I do not know the answer):

is the direction map bound to a specific stream network, i.e. the one that
r.watershed or r.stream.extract produces or is it an independent one, based
solely on the input elevation model and its (x-y-z?) resolution?

If the latter is true, then it only takes to use either r.watershed or
r.stream.extract to get the direction(s).

If not, then the question is if the user can supply his own stream map to
r.stream.* modules (specifically to r.stream.extract) in order to get the
desired flow direction map?

Thanks, Nikos

3

Nikos Alexandris pisze:

On Saturday 01 of May 2010 05:30:04 Nikos Alexandris wrote:
  

I am sort of forwarding a friends question related to hydro-processing.

While there is a proper (vector) contour map and a very clean stream
network map (digitised from scratch upon topographic maps of 1:50.000)
available, the flow direction map is missing.

Is this information easily calculated based on available dem(s), stream
network(s)? Or should _definitely_ the user add this information while
digitising the streams?

I have read many past threads wrt "streams, flow, direction, accumulation"
but could not trace an answer to the above question.
    
I read again some stuff and I guess that this is a very basic and simple "hydro-gis" question (for which I do not know the answer):

is the direction map bound to a specific stream network, i.e. the one that r.watershed or r.stream.extract produces or is it an independent one, based solely on the input elevation model and its (x-y-z?) resolution?

If the latter is true, then it only takes to use either r.watershed or r.stream.extract to get the direction(s).

If not, then the question is if the user can supply his own stream map to r.stream.* modules (specifically to r.stream.extract) in order to get the desired flow direction map?
  

Interested question, but I think the easiest answer is carving or stream burining (r.stream.carve). Next reproduce r.watershed or r.stream.extract you shall receive (almost) ideally confidential network with supplied
HTH
Jarek

Thanks, Nikos
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  

4

On 01.05.2010 07:46, Jarek Jasiewicz wrote:

Interested question, but I think the easiest answer is carving or stream
burining (r.stream.carve). Next reproduce r.watershed or
r.stream.extract you shall receive (almost) ideally confidential network
with supplied
HTH
Jarek

Hi Nikos,Jarek,

Stream burning: Thats what I thought about.

Further I suggest to weight the DEM with the contour information.
A guess how this could be done:
v.to.rast contourmap
r.fillnulls (to interpolate between contour lines raster map)?
r.mapcalc dem*contourrast
then r.watershed

Best regards,
Achim

PS: Check the global dataset "HydroSHED"! It uses stream burning and works perfectly (for non profit projects). Its resolution? 3",15",30",5'! I successfully used it to create a global runoff-network for the global runoff model LSDM (Dill 2008).

5

Achim wrote:

Further I suggest to weight the DEM with the contour information.
A guess how this could be done:
v.to.rast contourmap
r.fillnulls (to interpolate between contour lines raster map)?

r.fillnulls is better for little holes (e.g. in SRTM data)

see comparison of other methods here:
  http://grass.osgeo.org/wiki/Contour_lines_to_DEM

Hamish

6

Nikos Alexandris wrote:

On Saturday 01 of May 2010 05:30:04 Nikos Alexandris wrote:
  

I am sort of forwarding a friends question related to hydro-processing.

While there is a proper (vector) contour map and a very clean stream
network map (digitised from scratch upon topographic maps of 1:50.000)
available, the flow direction map is missing.

Is this information easily calculated based on available dem(s), stream
network(s)? Or should _definitely_ the user add this information while
digitising the streams?

I have read many past threads wrt "streams, flow, direction, accumulation"
but could not trace an answer to the above question.
    
I read again some stuff and I guess that this is a very basic and simple "hydro-gis" question (for which I do not know the answer):

is the direction map bound to a specific stream network, i.e. the one that r.watershed or r.stream.extract produces or is it an independent one, based solely on the input elevation model and its (x-y-z?) resolution?

If the latter is true, then it only takes to use either r.watershed or r.stream.extract to get the direction(s).

If not, then the question is if the user can supply his own stream map to r.stream.* modules (specifically to r.stream.extract) in order to get the desired flow direction map?

Thanks, Nikos
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  

It's not clear if your friend needs a flow direction raster (normally, AFAIK, flow direction refers to a raster, where each cell has a value indicating which is the next downstream cell) or if he want to see the flow direction of streams in his stream network.
I might be worth mentioning also that, since line vectors already have a direction in GRASS, you can display their direction with the "disp=dir" option to d.vect. So *if* he digitized his stream network being careful to work always downstream, then
d.vect streams disp=shape,dir
will show small arrows indicating the direction of each line segment.
Otherwise, as Jarek said, he should go back to the start and do r.stream.carve then rerun r.watershed to extract catchments, streams, as well as flowdir along the way, etc.

--
Micha Silver
Arava Development Co. +972-52-3665918
http://www.surfaces.co.il

7

(I've switched to KDE (KMail) and still need to get used to sime things - so
apologies for not sending this reply to the ml in first place)

Nikos Alexandris:

>> While there is a proper (vector) contour map and a very clean stream
>> network map (digitised from scratch upon topographic maps of 1:50.000)
>> available, the flow direction map is missing.
>>
>> Is this information easily calculated based on available dem(s), stream
>> network(s)? Or should definitely the user add this information while
>> digitising the streams?
>>
>> I have read many past threads wrt "streams, flow, direction,
>> accumulation" but could not trace an answer to the above question.
>
> I read again some stuff and I guess that this is a very basic and simple
> "hydro-gis" question (for which I do not know the answer):
>
> is the direction map bound to a specific stream network, i.e. the one
> that r.watershed or r.stream.extract produces or is it an independent
> one, based solely on the input elevation model and its (x-y-z?)
> resolution?
>
> If the latter is true, then it only takes to use either r.watershed or
> r.stream.extract to get the direction(s).
>
> If not, then the question is if the user can supply his own stream map to
> r.stream.* modules (specifically to r.stream.extract) in order to get the
> desired flow direction map?

Jarek Jasiewicz:

Interested question, but I think the easiest answer is carving or stream
burining (r.stream.carve). Next reproduce r.watershed or
r.stream.extract you shall receive (almost) ideally confidential network
with supplied

Thanks Jarek. This might be (a or the) way to go.

It's not clear to me whether the user can provide his own streams and get the
directions let's say from another DEM (with resolution similar to the one of
the "source" material from which the streams were produced)? I think that this
(should be) is the case.

Ideally, I imagine a module like:

"v.stream.directions elevation=HighResolutionDEM streams=StreamNetwork
output=StreamNetwork_WITH_directions"

Is this rational?

Regards, Nikos

8

Nikos:

>>>> While there is a proper (vector) contour map and a very clean stream
>>>> network map (digitised from scratch upon topographic maps of 1:50.000)
>>>> available, the flow direction map is missing.

...

>>> is the direction map bound to a specific stream network, i.e. the one
>>> that r.watershed or r.stream.extract produces or is it an independent
>>> one, based solely on the input elevation model and its (x-y-z?)
>>> resolution?

Micha:

>> It's not clear if your friend needs a flow direction raster (normally,
>> AFAIK, flow direction refers to a raster, where each cell has a value
>> indicating which is the next downstream cell) or if he want to see the
>> flow direction of streams in his stream network.

Nikos:

> A flow direction raster map is required. And my silly question (because I
> am not a hydro-specialist) is whether the flow direction production is
> an independent process from the algorithm that produces the streams.

Micha:

The r.watershed process makes several rasters: catchments, streams, flow
direction, flow accumulation, and others if you want.

> Why? Because the self-provided streams are of very high resolution and
> accuracy (so why bother to extract them with potential errors like
> circles in the connection of two segments of a stream, of ladder
> effects).

I've found that Markus Metz's newer r.watershed (part of GRASS 6.5, not
6.4) does a good job of eliminating these problems when you choose the
MFD (Multi flow direction) algorithm.

Good to know! I haven't been following all this hydro-related development but
I am impressed (again) to see how powerfull grass-gis is.

In any case, probably the best approach is to use the already digitized
streams as input to the r.carve module (or r.stream.carve , Jarek's new
hydrology extension) to produce an "improved" DEM, then use that
resulting DEM to rerun r.watershed and get everything out as a
consistent set of data layers.

OK. I think Jarek and Achim understood the problem quickly and suggested this
as the best method. Myself have a clear picture now of why r.carve is really
useful here.

Thank you Micha, Nikos

[...]

9

Nikos Alexandris pisze:

(I've switched to KDE (KMail) and still need to get used to sime things - so apologies for not sending this reply to the ml in first place)

Nikos Alexandris:
  

While there is a proper (vector) contour map and a very clean stream
network map (digitised from scratch upon topographic maps of 1:50.000)
available, the flow direction map is missing.

Is this information easily calculated based on available dem(s), stream
network(s)? Or should definitely the user add this information while
digitising the streams?

I have read many past threads wrt "streams, flow, direction,
accumulation" but could not trace an answer to the above question.
        

I read again some stuff and I guess that this is a very basic and simple
"hydro-gis" question (for which I do not know the answer):

is the direction map bound to a specific stream network, i.e. the one
that r.watershed or r.stream.extract produces or is it an independent
one, based solely on the input elevation model and its (x-y-z?)
resolution?

If the latter is true, then it only takes to use either r.watershed or
r.stream.extract to get the direction(s).

If not, then the question is if the user can supply his own stream map to
r.stream.* modules (specifically to r.stream.extract) in order to get the
desired flow direction map?
      
Jarek Jasiewicz:
  
Interested question, but I think the easiest answer is carving or stream
burining (r.stream.carve). Next reproduce r.watershed or
r.stream.extract you shall receive (almost) ideally confidential network
with supplied
    
Thanks Jarek. This might be (a or the) way to go.

It's not clear to me whether the user can provide his own streams and get the directions let's say from another DEM (with resolution similar to the one of the "source" material from which the streams were produced)? I think that this (should be) is the case.

Ideally, I imagine a module like:

"v.stream.directions elevation=HighResolutionDEM streams=StreamNetwork output=StreamNetwork_WITH_directions"

Is this rational?

Regards, Nikos
  

Hmm... not exactly...
How you plan ascribe a scope of different directions to one stream? In general stream is not a straight line so in every vertex it can have dir pixels directed in any direction. Maybe you need something like r.stream.angle? see that module maybe it will help.

10

(
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?

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.

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:

  - 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

11

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
  

12

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 :wink:

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