[GRASS-dev] r.watershed lsfac

Helena Mitasova hmitaso at unity.ncsu.edu
Fri Nov 28 23:30:05 EST 2008


Markus,

I checked and it seems to be still multiplied by 100
(I cc to Chuck as he is much better qualified to tell):

in
sg_factor.c
we have
69 	    L = 100 * pow((slope_length / 72.6), s_l_exp);
but L is defined as double on line 55 so the multiplication is
perhaps not necessary? Same for slope steepness?

While looking at this it also seems that
there may be an issue with meter-to-foot conversion - this is needed
because the number 72.6 above is in feet, but I don't see a check  
whether the data
is in feet - then the conversion should be skipped (but I did not  
explore this
much so it may be hidden somewhere)

35 	            if (ls_flag) {
36 	                length *= METER_TO_FOOT;
37 	                len_slp_equ(length, sin_theta, S, r, c);


as for the conversion constant - this would be better taken from UNITS
because the US feet may be more common than the int. feet used below
#define METER_TO_FOOT           (1 / 0.3048)

Helena

On Nov 27, 2008, at 6:06 PM, Markus Neteler wrote:

> Helena,
>
> could you please chek in SVN? I have uploaded the code to 6.4.and 7
> into raster/r.watershed2/
>
> It compiles as "r.watershed" module of course.
>
> Markus
>
> On Wed, Nov 19, 2008 at 5:36 AM, Helena Mitasova  
> <hmitaso at unity.ncsu.edu> wrote:
>> the man page for r.watershed says that the lsfac is multiplied by  
>> 100, but
>> the result is DCELL
>> so I am wondering whether the multiplication is still true. (and  
>> if yes
>> whether it should be changed)
>> And how is this for the new r.watershed2?
>>
>> thanks,
>>
>> Helena
>>
>>
>> On Oct 30, 2008, at 2:17 PM, Glynn Clements wrote:
>>
>>>
>>> Helena Mitasova wrote:
>>>
>>>> I have commented out the sites-related input/output from simwe  
>>>> in trunk.
>>>> It compiles and runs with grass7 updated today - I tested it  
>>>> with the
>>>> examples from grassbook and some variations of the parameters.
>>>>
>>>> Are these changes enough to get it back into grass7?
>>>> (there is still the issue of 3 separate waterglobs.h - I need to  
>>>> talk
>>>> to Jaro to see what would be the best way to fix it).
>>>
>>> I suggest committing the changes, but leaving it disabled in
>>> raster/Makefile until the sites and waterglobs.h issues have been
>>> fully dealt with.
>>>
>>> If you keep a private copy around for too long, it may become
>>> problematic to merge it if the SVN copy gets modified in the  
>>> meantime
>>> (if I'm making changes related to a particular header file or a
>>> particular function, I'll normally change everything which uses it,
>>> even modules which are disabled).
>>>
>>> Regarding waterglobs.h, does it work if you remove
>>> r.sim.*/waterglobs.h and add -I../simlib to EXTRA_CFLAGS in
>>> r.sim.*/Makefile? Or are there other issues?
>>>
>>>> Also, should I submit these changes to GRASS64 so that it runs in
>>>> winGRASS? (I am not sure what was the problem there)
>>>
>>> I'd suggest leaving it for now. The version in 6.4 isn't as  
>>> likely to
>>> be modified as in 7.0.
>>>
>>> --
>>> Glynn Clements <glynn at gclements.plus.com>
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
>
> -- 
> Open Source Geospatial Foundation
> http://www.osgeo.org/
> http://www.grassbook.org/



More information about the grass-dev mailing list