[GRASS-dev] Re: [GRASS GIS] #518: negative flow accumulation with r.watershed SFD or MFD

Michael Barton michael.barton at asu.edu
Fri Mar 6 09:54:15 EST 2009

On Mar 6, 2009, at 3:09 AM, <grass-dev-request at lists.osgeo.org> wrote:

> Date: Fri, 06 Mar 2009 08:18:38 -0000
> From: "GRASS GIS" <trac at osgeo.org>
> Subject: [GRASS-dev] Re: [GRASS GIS] #518: negative flow accumulation
> 	with r.watershed SFD or MFD
> To: undisclosed-recipients:;
> Message-ID: <048.30fedfc30b8b5f67edb5ee82855f1ca8 at osgeo.org>
> Content-Type: text/plain; charset="utf-8"
> #518: negative flow accumulation with r.watershed SFD or MFD
> -------------------------- 
> +-------------------------------------------------
>  Reporter:  dylan        |       Owner:  grass-dev at lists.osgeo.org
>      Type:  enhancement  |      Status:  new
>  Priority:  major        |   Milestone:
> Component:  default      |     Version:  svn-develbranch6
> Resolution:               |    Keywords:  r.watershed
>  Platform:  Linux        |         Cpu:  x86-32
> -------------------------- 
> +-------------------------------------------------
> Comment (by mmetz):
> IMHO, there is still some cleaning up to do for r.watershed. I left  
> some
> things in it for backwards compatibility. One such thing is the  
> "visual"
> output which I regard as obsolete because "accumulation" output now  
> comes
> with a (better I hope) colortable by default.
> The "visual" output could be removed and another output option be  
> added,
> e.g. called "absacc" that gives absolute accumulation values. That  
> would
> however break backwards compatibility, a new flag would not.
> There is a good reason *not* to add this option/flag, nicely  
> illustrated
> by Dylan creating this ticket. The purpose of negative accumulation  
> values
> is to make people wonder what on earth is going here, then figure  
> out that
> not the whole catchment area under study was included and expand the
> computational region accordingly to get proper results: only positive
> accumulation values for the catchment under study.

IMHO, this is a very poor way to achieve this end--i.e., silently  
performing all hydrology operations and producing completely bogus  
values to get you to scratch your head and wonder what is going on  
when you notice it. I suspect this is a legacy of the age of this  
module. To make things worse, GRASS's other hydrology modules do not  
work this way.

A much more direct way is to give a warning for each problematic basin  
in the output:
WARNING: part of basin XX extends beyond region extent; accumulation  
values may be too low.

It should be possible to turn off this "feature" of negative  
accumulation. This is especially important for scripting. For example,  
we use accumulation values as part of a complex, iterative erosion/ 
deposition model. We are currently running this on complete watersheds  
created with r.watershed (although an earlier version). Our goal is  
not to create accumulation maps and in fact never see the accumulation  
maps but use the values for additional modeling. Watershed maps get  
deleted along the way unless a flag is set to keep them because of the  
very large numbers of maps created to model decades or centuries of  
surface process dynamics. The new version seems to be calculating the  
watershed in a slightly different way, and now a tiny bit must extend  
off the region because we are getting negative values in some  
watersheds that were not problematic before. We will check this of  
course. But we never knew that we were getting negative values until  
this issue came up in another context. So our model values are  
completely bogus and we have to run this over again. The slight  
difference in accumulation would have only a very tiny effect on our  
results, but entire negative accumulation values make a big  
difference. So we'll have to build in taking the absolute value of  
accumulation (completely negating the goal of the negative values,  
BTW), but it would still be nice to have a text informational warning  
about which watersheds might be a problem for users of the model.


More information about the grass-dev mailing list