Running r.threshold on an accumulation map produced by r.watershed does
not produce a visible result; nor do I find one in the base directory:
r.threshold acc=dem.accum --v
100%
Warning: Flow accumulation contains negative values
Done!
Pointer required.
TIA,
Rich
Hi Rich,
On Thu, Jun 21, 2012 at 1:54 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
Running r.threshold on an accumulation map produced by r.watershed does
not produce a visible result; nor do I find one in the base directory:r.threshold acc=dem.accum --v
100%
Warning: Flow accumulation contains negative values
Done!Pointer required.
To now, r.threshold doesn’t manage negative values, so if the warning appears, there is no output.
cheers, madi
TIA,
Rich
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
–
Dr. Margherita Di Leo
On Thu, 21 Jun 2012, Margherita Di Leo wrote:
To now, r.threshold doesn't manage negative values, so if the warning
appears, there is no output.
madi,
Do I run r.mapcalc on the accumulation map to replace negative values with
zeros? Or, is there a different preferred approachu?
Thanks,
Rich
Rich,
On Thu, Jun 21, 2012 at 2:51 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
Do I run r.mapcalc on the accumulation map to replace negative values with
zeros? Or, is there a different preferred approachu?
you can use abs function of r.mapcalc
madi
–
Dr. Margherita Di Leo
On Thu, 21 Jun 2012, Margherita Di Leo wrote:
you can use abs function of r.mapcalc
madi,
There are broad valleys on either side of the mountain and those probably
account for the large number of negative accumulation values. r.describe
tells me:
r.describe map=dem.accum
100%
* -1513339.000000 thru -1455846.764706 -1448660.235294 thru -1427100.647059 -1355235.352941 thru -1348048.823529 -1348048.823529 thru -1340862.294118 -1297743.117647 thru -1276183.529412 -1261810.470588 thru -1254623.941176 -1254623.941176 thru -1247437.411765 -974349.294118 thru -952789.705882 -880924.411765 thru -873737.882353 -873737.882353 thru -866551.352941 -859364.823529 thru -852178.294118 -844991.764706 thru -751566.882353 -737193.823529 thru -708447.705882 -557530.588235 thru -550344.058824 -550344.058824 thru -543157.529412 -535971.000000 thru -528784.470588 -507224.882353 thru -449732.647059 -428173.058824 thru -392240.411765 -385053.882353 thru -363494.294118 -349121.235294 thru -341934.705882 -320375.117647 thru 96443.588235 110816.647059 thru 118003.176471 125189.705882 thru 153935.823529 161122.352941 thru 182681.941176 197055.000000 thru 204241.529412 211428.058824 thru 247360.705882 297666.411765 thru 319226.000000
I'll tpply abs() within r.mapcalc.
Thanks,
Rich
On Thu, 21 Jun 2012, Rich Shepard wrote:
I'll tpply abs() within r.mapcalc.
madi,
This yields a suggested threshold value. Thanks for the insight.
Rich
Do I run r.mapcalc on the accumulation map to replace negative values with
> zeros? Or, is there a different preferred approachu?
you can use abs function of r.mapcalc
would the -a flag of r.watershed be an option?
http://grass.osgeo.org/grass64/manuals/html64_user/r.watershed.html
-a
Use positive flow accumulation even for likely underestimates.[...]
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/r-threshold-Where-is-the-output-tp4982835p4983000.html
Sent from the Grass - Users mailing list archive at Nabble.com.
Helmut,
On Thu, Jun 21, 2012 at 3:33 PM, Helmut Kudrnovsky <hellik@web.de> wrote:
Do I run r.mapcalc on the accumulation map to replace negative values with
zeros? Or, is there a different preferred approachu?you can use abs function of r.mapcalc
would the -a flag of r.watershed be an option?
http://grass.osgeo.org/grass64/manuals/html64_user/r.watershed.html
-a
Use positive flow accumulation even for likely underestimates.[…]
sure, I didn’t mention it because I assumed that flow accumulation was already calculated…
The result is the same. Negative flow accumulation in the r.watershed convention means that in those cells flow accumulation is likely underestimated, i.e. part of the contributing area falls outside of the computational region. It is not meant as “negative area” (nonsense), it’s only a convention.
Regards,
madi
–
Dr. Margherita Di Leo
On Thu, 21 Jun 2012, Helmut Kudrnovsky wrote:
would the -a flag of r.watershed be an option?
http://grass.osgeo.org/grass64/manuals/html64_user/r.watershed.html
-a
Use positive flow accumulation even for likely underestimates.[...]
Helmut,
I don't know, but I will try and let everyone know the results.
Regards,
Rich
On Thu, 21 Jun 2012, Margherita Di Leo wrote:
To now, r.threshold doesn't manage negative values, so if the warning
appears, there is no output.
madi,
Using absolute values of the r.watershed accumulation map as input to
r.threshold provides a suggested r.basin threshold of 5297. As you write in
the wiki entry, this is both a suggestion and a reflection of uncertainty in
the meaning of the threshold.
Using this threshold value in the shell script for the 7 sub-basins,
r.basin halts on the calculation of the Horton indices for one basin, and
does not produce a parameter .csv file for a second sub-basin. The base DEM
map is used by r.basin, not the accumulation map with all positive values.
Can you suggest a strategy I can apply to generate different threshold
values to see how to allow r.basin to complete its run on those last two
sub-basins? Is there a reason for the threshold value to be the same for
each sub-basin?
Thanks,
Rich
Rich,
On Thu, Jun 21, 2012 at 6:19 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
Using absolute values of the r.watershed accumulation map as input to
r.threshold provides a suggested r.basin threshold of 5297. As you write in
the wiki entry, this is both a suggestion and a reflection of uncertainty in
the meaning of the threshold.Using this threshold value in the shell script for the 7 sub-basins,
r.basin halts on the calculation of the Horton indices for one basin, and
does not produce a parameter .csv file for a second sub-basin. The base DEM
map is used by r.basin, not the accumulation map with all positive values.Can you suggest a strategy I can apply to generate different threshold
values to see how to allow r.basin to complete its run on those last two
sub-basins? Is there a reason for the threshold value to be the same for
each sub-basin?
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.
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.
HTH,
madi
–
Dr. Margherita Di Leo
On Thu, 21 Jun 2012, Margherita Di Leo wrote:
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.
madi,
That confirms what I thought I would do.
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.
Also what I planned. Thanks for confirming.
Regards,
Rich