Re: [GRASS-user] Stream flow direction map

2010-05-01 Thread Achim Kisseler



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

2010-05-01 Thread Hamish
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

2010-05-01 Thread Micha Silver

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

2010-05-01 Thread Nikos Alexandris
(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

2010-05-01 Thread Nikos Alexandris
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

2010-05-01 Thread Nikos Alexandris
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] v.vol.idw

2010-05-01 Thread Benjamin Ducke
I can only speculate that you are really 
referring to "s.vol.idw" (?)
As the name implies, this is a module that
uses the now outdated "site" data model for its
input data. Some of those modules never made
the transition to GRASS 6 and its new vector engine.
It was still around in GRASS 5.3.
They are generally easy to convert to the new API though.

But perhaps someone on this list knows more about it?

It would certainly be useful to have IDW in voxel space.
IDW is primitive and generally does not give results
as good as spline-based interpolation (unless your data
is very dense and regularly spaced), but it has the advantage
of being simple (so it's easy to make sense of the result
data) and fast.

Ben


On 04/28/2010 12:55 PM, Stefania Merlo wrote:
> Hi,
>
> I was wondering what happened to the above command in the new releases of 
> GRASS. I am quite sure I did use it in GRASS 5 and possibly early versions of 
> 6 but it seems it got lost somewhere along the road. Is there any reason for 
> this? Does anyone remember in what version of GRASS for Mac it was last 
> present? I am in desperate need to use it to interpolate 3d points of subsoil 
> data for comparison with v.vol.rst.
>
> All best
>
> Stefania
>
>
> Stefania Merlo
> Department of Archaeology
> University of Cambridge
> United Kingdom
> sm...@cam.ac.uk
>
>
>  “Mi piacerebbe che il mio viaggio fosse ancora lungo e costellato di 
> smarrimenti, si mi piacerebbe vivere per molto tempo e commettere ancora 
> mille errori, mille sbagli, ed anche un certo numero di peccati memorabili”! 
> (Amin Maalouf, Il periplo di Baldassarre)
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user



--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more information.

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Stream flow direction map

2010-05-01 Thread Nikos Alexandris
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