[GRASS-user] "ladders" in watershed delineation

[Markus Metz]

Micha Silver wrote:
> Markus Metz wrote:
>
>> These single-cell strings in basins, did you get them with SFD or MFD 
>> mode? If MFD mode, what convergence factor did you use?
>>
> My watershed delineation was done with r.watershed, not r.terraflow, 
> so IIUC it's SFD.  I didn't see any "braided" streams in the output.
r.watershed in 6.5+ can do MFD which reduces these single-cell strings 
substantially. I would recommend MFD over SFD for anything with 30m 
resolution or higher, not much gained for 90m or coarser. Results are 
generally more accurate with MFD for high resolution (<= 30m) DEMs.

Markus M

> I'm using GRASS 6.4 RC4 which, I believe contains your newer watershed 
> speedup. However size of the region and resolution were such that I 
> had to use the -m option.
> Regards,
> Micha
>> Markus M
>>
>>
>> Micha Silver wrote:
>>>
>>> Milton Cezar Ribeiro wrote:
>>>
>>>> Hi Micha,
>>>>
>>>> Make a test. If you run a 3x3 or 5x5 filter and get the percentage, 
>>>> and
>>>> after check the values for those isolated pixels, you perceive that 
>>>> when
>>>> pixels are isolated the percentage values are very different from its
>>>> neighbours. I forgot to give the full suggestion:
>>>>
>>>> 1. run r.neighbors with interspersion
>>>> 2. check the values for isolated pixels and define a threshold
>>>> 3. run r.neighbors with majority
>>>> 4. run r.mapcalc "newmap=if(map_inter< XXX, map_majority, map)"
>>>>     (I dont remember if is map_inter<   or map_inter> - check it).
>>>>
>>>> Try this!
>>>>
>>>>   
>>> After writing my first (silly) response, I thought thru and realized 
>>> what you were suggesting.
>>> I did r.neighbors twice: once with the interspersion method, and a 
>>> second time with the mode method to create two new rasters.
>>> Then, exactly as you explained above, I set 68 as the maximum 
>>> interspersion value [6 different value cells in the 3X3 window gives 
>>> (6/9)*100+1=67%].
>>>
>>> Then the mapcalc expression:
>>> if(catch_inter<=68, catch, catch_mod)
>>> gave me the new catchment raster. I looked it over and *most* but 
>>> not all of the problematic strings are gone. So this seems like a 
>>> very reasonable way to improve the catchment raster from r.watershed.
>>>
>>> Thanks for putting me on the right track,
>>> Micha
>>>> cheers
>>>>
>>>> milton
>>>>
>>>>
>>>>
>>>>
>>>> 2009/8/3 Micha Silver <micha at arava.co.il>
>>>>
>>>>  
>>>>> Milton Cezar Ribeiro wrote:
>>>>>
>>>>> Hi Micha,
>>>>>   
>>>>>>  May be with *r.neighbors *combined with /interspersion/  method 
>>>>>> you can
>>>>>> solve this.
>>>>>>
>>>>>>
>>>>>>       
>>>>> Hi Milton
>>>>> Thanks for your help.
>>>>> If my reading of the manual is correct, the "interspersion" option 
>>>>> gives
>>>>> each cell the percentage of different cells surrounding it. I'm 
>>>>> not clear
>>>>> how this will help with the string of single cells.
>>>>> But maybe running r.neighbors on the catchments raster with the 
>>>>> default
>>>>> "average" option will get rid of those strings...
>>>>> I'll give it a try.
>>>>> Best regards,
>>>>> Micha
>>>>>
>>>>>  good luck
>>>>>   
>>>>>>  milton
>>>>>> brazil=toronto
>>>>>>
>>>>>> 2009/8/2 Micha Silver <micha at arava.co.il <mailto:micha at arava.co.il>>
>>>>>>
>>>>>>    How can I avoid the problem of strings of single cells when
>>>>>>    creating basins with r.watershed? I think this is referred to as
>>>>>>    "ladders". Here's [1] an image showing what I mean.
>>>>>>
>>>>>>    In my example, the purple colored catchment has two "tails" of
>>>>>>    width 1 cell. One tail separates between the light green and the
>>>>>>    pale blue catchments. The other (northern) tail splits the dark
>>>>>>    green catchment into two.
>>>>>>
>>>>>>    After running r.to.vect to get the catchment vectors, I'm left
>>>>>>    with the two "strings" or "ladders" of tiny vector areas. The
>>>>>>    southern string can be removed with v.clean tool=rmarea with no
>>>>>>    ill effects.
>>>>>>
>>>>>>    However when I remove those small areas in the northern "ladder"
>>>>>>    I'm left with the stream running *along the drainage divide* or
>>>>>>    even zigzagging across the divide, neither of which is correct.
>>>>>>
>>>>>>    Can this problem be avoided? I've tried with a couple of 
>>>>>> different
>>>>>>    dem sources, and at different resolutions and threshold values,
>>>>>>    but these ladder phenomena always seem to appear.
>>>>>>
>>>>>>    This example was done with the ASTER DEM data, using a threshold
>>>>>>    of 11000 and resolution like the original data (1 arcsec ~= 30 
>>>>>> m.)
>>>>>>
>>>>>>
>>>>>>    Thanks,
>>>>>>
>>>>>>    Micha
>>>>>>
>>>>>>
>>>>>>    [1] http://my.arava.co.il/~micha/ladders.html
>>>>>>    
>>>>>> <http://my.arava.co.il/%7Emicha/ladders.html<http://my.arava.co.il/~micha/ladders.html> 
>>>>>>
>>>>>>          _______________________________________________
>>>>>>    grass-user mailing list
>>>>>>    grass-user at lists.osgeo.org <mailto:grass-user at lists.osgeo.org>
>>>>>>    http://lists.osgeo.org/mailman/listinfo/grass-user
>>>>>>
>>>>>>
>>>>>>
>>>>>> This mail was received via Mail-SeCure System.
>>>>>>
>>>>>>       
>>>>>     
>>>>
>>>> This mail was received via Mail-SeCure System.
>>>>
>>>>
>>>>
>>>>   
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>   
>>
>> This mail was received via Mail-SeCure System.
>>
>>
>
>