|
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 <mi...@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 <mi...@arava.co.il <mailto:mi...@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@lists.osgeo.org <mailto:grass-user@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
