Re: [GRASS-user] Stream flow direction map
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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
( 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
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
Re: [GRASS-user] Stream flow direction map
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). ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
(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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
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 [...] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
On Saturday 01 of May 2010 09:12:21 Achim Kisseler wrote: 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. Thanks guys, I'll be testing this quickly (or just pass the information to the friend (uses Arc-something-9.3). 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 Yep, I had the same feeling about it (since there is high resolution info available, there must be a way to use it) but was unsure about the approach. Thanks Achim ;-) Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
Jarek: 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 Achim Kisseler: Stream burning: Thats what I thought about. Nikos: Thanks guys, I'll be testing this quickly (or just pass the information to the friend (uses Arc-something-9.3). Steps tested (more or less successfully): # comment: contours were digitised from topomaps with a scale of 1:5 # scanned at 300dpi # estimated cell size = 4.23 m # same scale applies to digitised streams # set region and rasterise g.region vect=contours_20m res=4.23m -pa v.to.rast in=contours_20m out=contours_4.23m # comment: this is harder than I thought. Quick checking reveals disconnected lines # set resolution to 1m and (re-)rasterize g.region res=1 -pa v.to.rast in=contours_20m out=contours_1m # checking... looks ok. # I think this particular step is a crux for a successful processing # any ideas to avoid disconnected lines at a resolution 4.23m? # some special downscaling method? Neatest neighbor seems to be a bad choice here. # change resolution as the 1m will be running for days? g.region vect=contours_20m res=50m -pa # contours to elevation r.surf.contour in=contours_1m out=elevation_50m # carving... r.carve rast=elevation_50m vect=streams out=elevation_50m_carved # extracting streams and direction map (not sure about the threshold) r.stream.extract elevation=elevation_50m_carved stream_rast=streams_extracted direction=stream_directions_extracted threshold=100 # strahler-ordering streams r.stream.order stream=streams_extrected dir=stream_directions_extracted strahler=strahler # resulted streams look a bit squared due to the 50m res I guess. Strahler looks correct to me (afaict from my studies 6-7 years ago). Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Stream flow direction map
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Stream flow direction map
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
Re: [GRASS-user] Stream flow direction map
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
