Rich,<br><br><div class="gmail_quote">On Thu, Jun 21, 2012 at 6:19 PM, Rich Shepard <span dir="ltr"><<a href="mailto:rshepard@appl-ecosys.com" target="_blank">rshepard@appl-ecosys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  Using absolute values of the r.watershed accumulation map as input to<br>
r.threshold provides a suggested r.basin threshold of 5297. As you write in<br>
the wiki entry, this is both a suggestion and a reflection of uncertainty in<br>
the meaning of the threshold.<br>
<br>
  Using this threshold value in the shell script for the 7 sub-basins,<br>
r.basin halts on the calculation of the Horton indices for one basin, and<br>
does not produce a parameter .csv file for a second sub-basin. The base DEM<br>
map is used by r.basin, not the accumulation map with all positive values.<br>
<br>
  Can you suggest a strategy I can apply to generate different threshold<br>
values to see how to allow r.basin to complete its run on those last two<br>
sub-basins? Is there a reason for the threshold value to be the same for<br>
each sub-basin?<br></blockquote><div><br>Threshold value should be determined by trial and errors. If you have a map of digitized streams ("real" streams) you can compare the results you get using different threshold values and see which gives you the most similar to the reality.<br>
For what concerns your shell script running r.basin in loop for several basins, I'd suggest to analyze the "problematic basin" separately (outside the loop) adjusting the coordinates of the output by hand. <br>
<br>HTH,<br><br>madi<br></div><div> <br clear="all"></div></div><br>-- <br>Dr. Margherita Di Leo<br>