[GRASS-dev] default for r.walk

[Helena Mitasova]

On Oct 10, 2008, at 7:39 PM, Michael Barton wrote:

>
>
>
> 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).

these are perfectly valid questions - authors should probably answer  
them rather than me
but we tried to put some explanation based on the manual in to the  
appendix of GRASSbook
and I have just covered it in the class so I had to spend some time  
trying to understand it.

the units are - according to the manual - time - see below

S, H are meters but the coefficients a,b,c,d are 1/speed which is sec/ 
meter  giving you time in seconds,
then friction map can be either in units of time (sec) and lambda is  
unitless weight
or friction is unitless factor and lambda is in seconds which  
converts it to time.
So the results are in seconds - when you derive contours from the  
results you will get isochrones -
so you can delineate an area where the person gets within 2 hours or  
whatever time you chose.

But it would be really good to hear from the authors because these  
are my interpretations
of the manual and my experiments with the module. The man page is  
pretty good it just needs to be more clear that the cost is measured  
by time (if I understand it correctly)

Helena


T= [(a)*(Delta S)] + [(b)*(Delta H uphill)] + [(c)*(Delta H moderate  
downhill)] + [(d)*(Delta H steep downhill)]

where:
T is time of movement in seconds,
Delta S is the distance covered in meters,
Delta H is the altitude difference in meter.

The a, b, c, d parameters take in account movement speed in the  
different conditions and are linked to:

     * a: underfoot condition (a=1/walking_speed)
     * b: underfoot condition and cost associated to movement uphill
     * c: underfoot condition and cost associated to movement  
moderate downhill
     * d: underfoot condition and cost associated to movement steep  
downhill

It has been proved that moving downhill is favourable up to a  
specific slope value threshold, after that it becomes unfavourable.  
The default slope value threshold (slope factor) is -0.2125,  
corresponding to tan(-12), calibrated on human behaviour (>5 and <12  
degrees: moderate downhill; >12 degrees: steep downhill). The default  
values for a, b, c, d are those proposed by Langmuir (0.72, 6.0,  
1.9998, -1.9998), based on man walking effort in standard conditions.

The lambda parameter of the linear equation combining movement and  
friction costs:
total cost = movement time cost + (lambda) * friction costs
must be set in the option section of r.walk.


>
>
> 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
>>>
>>
>