[GRASS-dev] Re: [GRASS-user] r.watershed in grass 6.1 and 5.4

[Paul Kelly]

On Thu, 17 Aug 2006, Dylan Beaudette wrote:

> On Thursday 17 August 2006 06:41, Maciej Sieczka wrote:
>> Hans Hauska napisa?(a):
>>> SECTION 5: Closing Maps.
>>>
>>> everything seems to work fine, but When it reaches Section 5 then it
>>> just stands on one point and chews ....
>>> I had it run for over 12 hours, but nothing happened in the final stage
>>> and it never finished.
>>> Has anyone been able to successfully run it?
>>> Is there a special trick? Should I use a Linux version (that is possible)
>>> I'd appreciate any hints or suggestions on the matter.
>>
>> This is a long-standing bug http://intevation.de/rt/webrt?serial_num=3112
>>
>> r.watershed completes fine on smaller input. On bigger it hangs (don't
>> know what the exact threshold is though).
>>
>> Maciek
>>
>
> Helena recently commented on this:
>
>> r.terraflow currently has only multiple flow directions option which
>> should give better results for hillslope erosion. On floodplains it
>> spreads water
>> so it won't create a single cell wide stream. It will be worth trying
>> to see how the results look like
>> with r.usped. Note that it is faster only on massive grids - for
>> regular sized grids
>> (1000x1000) it may be the same as r.watershed.
>> For stream extraction with depressions r.watershed gives more
>> accurate results
>> but it gets stuck for grids larger than approx 1500x1500 (depending
>> how big your memory is).
>> r.terraflow runs on 10,000x10,000 with no problems. Duke univ. team
>> is working on new version,
>> but I did not have a chance to try it yet and it has not been yet
>> implemented in GRASS.
>> Ultimately my plan was to replace all flow routing with r.terraflow
>> but it looks like
>> that won't be possible because some of the algorithms cannot be
>> rewritten as I/O efficient,
>> so we will keep r.watershed for now.
>>
>> I cc this to Dylan - regarding the r.watershed getting stuck on step
>> 5, it may be just color table
>> (it assigns a random color to each subwatershed and that search for
>> colors gets stuck when
>> there are too many-
>> if somebody would be willing to look at it (modify the code and test it)
>> I will be happy to help. Hamish identified the problem long time ago
>> (I might have submitted a bug report)
>> but I don't have enough time to explore it (I looked at the code, it
>> may not be too complicated).

Yes it seems quite simple. It assigns a random colour table with 
G_make_random_colors(), which is fast even for a huge number of 
watersheds, but then there is some extra code which appears to "prettify" 
the colour table in some way. It is really inefficient for large numbers 
of watersheds. Totally disabling it and just using the random colour table 
results in the program completing quickly even for a ridiculously huge 
number of watersheds, but I guess seeing it appears to prettify the output 
it would be worth keeping it in for number of watersheds below some 
arbitrary threshold?

Maybe Helena remembers what exactly the prettifying achieves or what 
problem it overcomes?

The files with the inefficient routine appear to be:
raster/r.watershed/ram/close_maps2.c
raster/r.watershed/seg/close_maps2.c
raster/r.watershed/shed/close_maps2.c

and here is an example from ram/close_maps2.c:


 	r = 1;
 	incr = 0;
 	while(incr >= 0) {
 	    for (gr=130+incr; gr<=255; gr += 20) {
 	        for (rd=90+incr; rd<=255; rd += 30) {
 		    for (bl=90+incr; bl<=255; bl += 40) {
 		        flag = 1;
 		        while (flag) {
 			    G_get_color(r,&red,&green,&blue, &colors);
 			    if((blue*.11 + red*.30 + green*.59) < 100) {
 				G_set_color(r, rd, gr, bl, &colors);
 			        flag = 0;
 		            }
 			    if (++r > max) {
 			        gr = rd = bl = 300;
 				flag = 0;
 			        incr = -1;
 			    }
 		        }
 		    }
 	        }
 	    }
 	    if (incr >= 0) {
 		incr += 15;
 		if (incr > 120)
 		    incr = 7;
 	    }
 	}

>> When r.watershed gets stuck on step 2, that is when it cannot be done/
>> fixed.
>> I just looked at Hans' command and if he used threshold 75 with a DEM
>> that is around 1000x1000,
>> that is where his problem is - he should use much larger threshold
>> (thousands at least).
>>
>> Helena
>
> So it would seem that we need to find a better random color generator to
> r.watershed, or just disable the color table if num watersheds > some
> threshold. I'll poke around in the source later today.
>
> Dylan
>
> -- 
> Dylan Beaudette
> Soils and Biogeochemistry Graduate Group
> University of California at Davis
> 530.754.7341
>
> _______________________________________________
> grassuser mailing list
> grassuser at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>