[GRASS-dev] default for r.walk
Michael Barton
michael.barton at asu.edu
Fri Oct 10 19:39:23 EDT 2008
On Oct 10, 2008, at 11:32 AM, Helena Mitasova wrote:
> I opened the code and it has it right in header:
>
> TOTAL COST = [(WALKING ENERGY ) + (LAMBDA*FRICTION)]
>
> maybe this is how it should go into the man page
That seems like a good idea.
This suggests that friction and lambda should be in some kind of
energy units.
However, as I understand it, the values in an r.walk map--using the
default values--are an estimate of the number of seconds to traverse a
cell walking 'normally' (i.e., according to the default values). Is
this true anyone? If so, wouldn't the additive friction need to be in
time units?
I'm not trying to be dense, but trying to get clear about what the
output is actually telling us, since it does not seem to be in
arbitrary units like r.cost is (unless you do some numerical massaging).
Michael
>
>
>
> On Oct 10, 2008, at 2:21 PM, Michael Barton wrote:
>
>> I've been emailing with Helena to try to understand exactly how
>> lambda and a friction surface interacts with information about
>> topography (extracted from a DEM) in r.walk. It seems a good idea
>> to put this back on the list. Perhaps I'm the only one a little in
>> the dark, but maybe it can help others.
>>
>> On Oct 10, 2008, at 10:40 AM, Helena Mitasova wrote:
>>
>>>>
>>>> To clarify for me, is it
>>>>
>>>> total cost = (movement time cost + lambda) * friction costs
>>>>
>>>> OR
>>>>
>>>> total cost = movement time cost + (lambda * friction costs)
>>>
>>> I did not look into the code but if there are no brackets in the
>>> code, this second interpretation applies.
>>
>> For anyone familiar with the code, is this the case? If so, should
>> I be thinking in time units for creating a friction map? If I
>> remember, r.walk normally outputs in seconds to traverse the cell.
>>
>> So, should the friction map be in additional seconds to traverse
>> the cell? Or is friction a weighting factor (i.e., multiplicative
>> rather than additive)?
>>
>> Thanks
>> Michael
>>
>
More information about the grass-dev
mailing list