[GRASS-dev] r.watershed

[Helena Mitasova]

On Jan 17, 2009, at 5:04 AM, Markus Metz wrote:

>
>
> Helena Mitasova wrote:
>> just a quick note from the first run - it may be better to have  
>> SFD as default so that the same command as in grass63
>> gives the same result. E.g. running
>> g.region rast=elevation
>> r.watershed elevation thresh=10000 accum=accum_10K2  
>> drain=draindir_10K2 basin=basin_10K2 stream=rivers2
>>
>> gives an MFD result that some people may consider weird when  
>> compared with the old r.watershed
>> (although it is perfectly fine as MFD result)
> This is true, the same command gives a different result. But some  
> other people may consider the SFD result weird, e.g. with  
> elev_lid792_1m in nc_spm_08. As an example imagine a user who wants  
> to compare the output of different modules for flow accumulation  
> and runs r.terraflow and r.watershed with default settings. With  
> DEMs like elev_lid792_1m, MFD is needed to get halfway realistic  
> results, and r.watershed with SFD produces here really weird  
> results. I haven't found yet a testing dataset where I would prefer  
> the SFD results over the MFD results.

I am talking here about the issues related to including the new  
r.watershed in GRASS64 not the merits
of SFD versus MFD (I have done my share of criticizing SFD for many  
years)
  - people may have scripts, applications where they expect certain  
result and that will be very different
with MFD for certain data. This is perfectly fine with GRASS7 but it  
may be problematic with GRASS64.

Just run it with elevation in nc_spm. The MFD result is actually more  
realistic because it simulates the existing
lakes but you would have to do additional processing if you need a  
stream network (or re-run with -s
or to get a really good result switch from MFD to SFD as your  
modification allows, which is great).

I would like to see the new r.watershed in GRASS64 and not wait for  
GRASS7 but the change should not
create problems for people who have r.watershed included in their  
applications or modeling tools.

> So the argument to have SFD as default is that default settings  
> produce results identical to the previous version.

that is exactly what I had in mind for GRASS64

> The argument to have MFD as default is to keep default settings  
> similar to r.terraflow and to use the mode as default that is  
> likely to produce the most realistic results (still debatable).

MFD does produce more realistic results - but the problem is that is  
not what people always want
(like the issue of hydrologically "correct" DEMs that fill all the  
depressions changing your wetlands
into straight channels and creating a totally unrealistic hydrology,  
but many GIS textbooks tell you
to do just that)

>>
>> running the same with r.watershed -s gives the same, more "normal"  
>> looking result.
>> So people who have r.watershed in scripts and expect/need SFD  
>> result would need to add -s,
>> or will be puzzled by the different result.
> I'm not that much of a hydrology expert, when would SFD results be  
> needed?

when you need to extract vectorized stream network from lower  
resolution data (30-90m) and you need the network
to create a single channel through lakes, SRTM is a good example as  
is the elevation DEM in nc_cpm_08.

| Should a paragraph be added to the documentation when SFD is  
preferred over MFD?

yes, some comments on when to use which option would be helpful.

Helena

>>
>> So whoever has some examples, scripts with r.watershed please run  
>> it to see whether
>> it behaves as expected.
>>
>> Helena
>>