[GRASS-user] [GRASS GIS] #1924: r.watershed - empty stream segment map

[Markus Metz]

On Tue, Jun 4, 2013 at 11:00 AM, Johannes Radinger
<johannesradinger at gmail.com> 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 <markus.metz.giswork at gmail.com>
> wrote:
>>
>> On Mon, Jun 3, 2013 at 3:30 PM, Johannes Radinger
>> <johannesradinger at gmail.com> 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 <trac at osgeo.org> 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
>> > grass-user at lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>
>