On Tue, Jun 4, 2013 at 11:00 AM, Johannes Radinger <[email protected]> wrote: > Thank you Markus, > > thats really a profound answer perfectly solving the problem. I've tested > it, and > it is smoothly working in GRASS65. Just the variables for r.patch in python > are input and output instead of in and out....
Only shell supports option abbreviation. Sometimes shell is easier (and faster to type). The procedure I suggested will not work in all situations. Sometimes it might be necessary to create a buffer, and then set the start point (cumulative costs = 0) to NULL instead of modifying the buffer. This will create segments leading up to the start point, but excluding the start point. Markus M > > cheers, > /johannes > > > On Mon, Jun 3, 2013 at 9:49 PM, Markus Metz <[email protected]> > wrote: >> >> On Mon, Jun 3, 2013 at 3:30 PM, Johannes Radinger >> <[email protected]> wrote: >> > Hi Markus, >> > Hi others, >> > >> > I am coming back to the topic of running r.watershed on a rasterized >> > river >> > network. >> > >> > As recommended I buffered now my river raster. This river raster is a >> > thinned distance raster >> > with increasing values from the outlet to the branches (calculated via >> > r.cost) and as >> > I said it is buffered now with a very large value (2 x max of the >> > thinned >> > distance raster). >> > >> > So actually this should work as an input map to r.watershed. And it does >> > more or >> > less perfectly: There's just one issue concerning the outlet-stream >> > segment. >> > Somehow this (in my case small segment, in the south-west corner) is >> > missing >> > in the stream-map output of r.watershed. >> > I am working on GRASS6.5. Attached there is a zipped GTIFF with the >> > "pseudo-elevation" map >> > (this thinned and buffered distance raster) I am using as input to >> > r.watershed. >> >> There is another error in the north-eastern part where a stream >> segment extents into the buffer area. The reason for these artefacts >> is that r.watershed does not know where the outlet is because all >> river segments are inside the buffer. In this case, the outlet is the >> starting point of r.cost which has in the river raster the value 0. >> You could produce the desired output with >> >> # buffer >> r.grow.distance input=river_raster value=river_raster_nearest >> >> # get value of nearest river cell >> r.grow input=river_raster output=river_raster_grow radius=2.01 old=1 >> new=100000 >> >> # remove buffer for start point >> r.mapcalc "river_raster_grow_start = if(river_raster_nearest == 0, >> null(), river_raster_grow)" >> >> # grow by one cell to make sure that the start point is the only cell >> of the river bordering a NULL cell >> r.grow input=river_raster_grow_start output=river_raster_buffer >> radius=1.01 old=100000 new=100000 >> >> # path river raster with buffer >> r.patch in=river_raster,river_raster_buffer out=buffered_distance_raster2 >> >> # get stream segments >> r.watershed -s --overwrite elevation=buffered_distance_raster2 >> stream=test_segments threshold=3 >> >> HTH, >> >> Markus >> >> > >> > The command I am using is: >> > r.watershed -f --overwrite elevation=buffer_river_raster >> > stream=test_segments threshold=3 >> > The threshold has been set to 3 as this is the number of raster cells >> > that >> > refer to the buffer (3 x resolution) >> > >> > Can anyone reproduce that the outlet small river segment is missing in >> > the >> > produced "test_segments"?? >> > What is causing that? >> > >> > /Johannes >> > >> > >> > >> > >> > >> > On Wed, Apr 10, 2013 at 12:37 PM, GRASS GIS <[email protected]> wrote: >> >> >> >> #1924: r.watershed - empty stream segment map >> >> >> >> >> >> -----------------------+---------------------------------------------------- >> >> Reporter: jradinger | Owner: grass-dev@… >> >> Type: defect | Status: new >> >> Priority: normal | Milestone: >> >> Component: Raster | Version: svn-trunk >> >> Keywords: | Platform: Linux >> >> Cpu: x86-32 | >> >> >> >> >> >> -----------------------+---------------------------------------------------- >> >> >> >> Comment(by mmetz): >> >> >> >> Replying to [comment:2 jradinger]: >> >> > >> >> > Two more important things: >> >> > 1) The elevation input map is accutally already a thinned river >> >> raster. >> >> The raster >> >> > values represent a pseude elevation which was generated with r.cost >> >> from the source. >> >> > Thus the value (elevation) is increasing upstream. r.watershed is >> >> just >> >> used for getting >> >> > the flowdirection and segmenting the river raster. (if needed I can >> >> provide the elevation-rcost >> >> > raster) >> >> >> >> r.watershed expects a surface as input. Using a thinned river raster >> >> as >> >> input should give weird results: all non-NULL cells face at least one >> >> NULL >> >> cell treated as unknown elevation, thus flow direction can not be >> >> unambiguously determined. You can try to place a buffer around the >> >> rivers >> >> and fill the buffer with pseudo-elevation values larger than the >> >> largest >> >> cost value. For example, create a buffer using 300 meter (3 cells) as >> >> distance, set a pseudo elevation value for the buffer zone, patch the >> >> thinned river raster with the pseudo elevation, run r.watershed with >> >> threshold=3. Works for me. >> >> >> >> > And maybe a warning/error message should be printed when threshold = >> >> 0, >> >> instead of the (for me confusing error) >> >> >> >> Makes sense. >> >> >> >> Markus M >> >> >> >> -- >> >> Ticket URL: <http://trac.osgeo.org/grass/ticket/1924#comment:3> >> >> GRASS GIS <http://grass.osgeo.org> >> >> >> > >> > >> > _______________________________________________ >> > grass-user mailing list >> > [email protected] >> > http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
