Several weeks back, Helena gave a very good explanation of how
r.walk
actually works. It makes very good sense (see below). However,
from this
explanation, it is clear that lambda and a friction map should be
*optional*
rather than *required* as they are now.
The main part of r.walk calculates the time (in seconds) needed
to walk
across a landscape.
For any cell,
total time = (walking time in seconds to traverse the cell given
its
slope)
+ (lambda * friction map)
Lambda is a weighting coefficient to convert the friction map to
units
that
match the costs due to slope (i.e., units in seconds normally).
If you want to calculate walking time to traverse a landscape
that is
based
solely on the topography (i.e., slope), then you need a friction
map with
a
value of 0; lambda can be anything.
So this should be optional. Currently, you need to create a 0
friction
map
and try to figure out what lambda should be in order to run
r.walk. This
is
sort of pointless and can cause considerable confusion.
So, can lambda and friction map be changed to optional arguments
for our
upcoming releases?
Thanks
Michael
____________
Begin forwarded message:
From: Michael Barton <[EMAIL PROTECTED]>
Date: October 10, 2008 9:27:46 PM GMT-07:00
To: Helena Mitasova <[EMAIL PROTECTED]>
Cc: grass developers <grass-dev@lists.osgeo.org>, Ullah Isaac
<[EMAIL PROTECTED]>, [EMAIL PROTECTED], Sean Bergin
<[EMAIL PROTECTED]>, Moreno MartÃn Andrea <[EMAIL PROTECTED]>
Subject: Re: [GRASS-dev] default for r.walk
Thanks very much for this thorough explanation Helena. It is quite
helpful.
I hope that Roberto can verify (or correct) this.
I'm copying some folks who have been working with r.walk
recently. Our
lab
discussions on this caused me to raise these questions.
On the issue I first asked about, it seems that lambda should
either 1)
have
a default value of 1 or 2) be optional.
Michael
On Oct 10, 2008, at 6:09 PM, Helena Mitasova wrote:
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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
