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
Micha Silver pisze:
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
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
you cannot in this case.
jarek
Hi Micha,
May be with r.neighbors combined with interspersion method you can solve this.
good luck
milton
brazil=toronto
2009/8/2 Micha Silver <micha@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
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
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@arava.co.il <mailto:micha@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/~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.
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:
- run r.neighbors with interspersion
- check the values for isolated pixels and define a threshold
- run r.neighbors with majority
- 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!
cheers
milton
2009/8/3 Micha Silver <micha@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@arava.co.il mailto:[micha@arava.co.il](mailto:micha@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>
grass-user mailing list
grass-user@lists.osgeo.org mailto:[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.
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
These single-cell strings in basins, did you get them with SFD or MFD mode? If MFD mode, what convergence factor did you use?
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@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@arava.co.il <mailto:micha@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/~micha/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
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.
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@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@arava.co.il <mailto:micha@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/~micha/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
This mail was received via Mail-SeCure System.
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@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@arava.co.il <mailto:micha@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/~micha/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
This mail was received via Mail-SeCure System.
Markus Metz wrote:
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:
Thanks for your time.
So, bottom line, I'll look forward to updating to 6.5 or 7...
Markus M
Markus Metz wrote:
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 finally got around to compiling GRASS 6.5, with the r.watershed MFD options, and I must say... wow!
First, the memory handling must be much better. I'm working on a region with about 80 million cells. Theoretically I should need 2.5 GB to run the module in memory. There are many null cells surrounding the actual basin, but still, On my aging Pentium 4 with 1 GB memory, using the older r.watershed (GRASS 6.4) I would run out of memory, and I'd have to use the "seg" mode, which of course took hours and hours.
Now the newer module whips thru the same dataset in about 20 minutes.
And more importantly, using the -f flag (Multi flow direction) the original problem of "ladders" or strings of single cells in the catchment raster has almost disappeared!
The only remaining problem I noticed is streams that split and reconnect. Although this was quite minor.
Best regards,
Micha