[GRASS-dev] small changes to r.walk
Michael Barton
michael.barton at asu.edu
Fri Nov 14 20:57:32 EST 2008
Hi Colin,
Thanks again for the info. We're looking into it. I guess we will need
to do some empirical tests, but it would be nice if one could specify
how to value a friction map so as to still get real time values in the
output. Here seems to be the most relevant piece of code.
else
fcost_dtm = (double)((double)(W_dtm - my_dtm) * c);
fcost_cost = ((double)(W_cost + my_cost) / 2.0);
min_cost = pres_cell->min_cost + fcost_dtm + (EW_fac * a) + lambda *
fcost_cost * EW_fac;
fcost_cost is not friction cost per se. Maybe my_cost is the actual
friction cost value? It doesn't seem be converted to time units at
that point, but this is not clear (What is W_cost?). I guess we need
to know this to determine the units/value ranges for the friction map.
Possibly the easiest way to think about a friction map is as a percent
of the 'normal' cost (faster or slower)--though that is not how it
seems to be added in.
I'm not sure why you say a friction map would need to only ADD time.
If it is included in the calculations BEFORE the final cumulative time
map is made, then it could either increase OR decrease the net time to
traverse a cell. This is what I was referring to a couple posts back.
And this is what seems to be happening here--except that it looks like
you can't really make a friction map value LESS than the topographic
costs of traversing a cell. Nevertheless, it is good if we model with
some factors reducing the time to cross a cell and other factors
increasing the time.
Michael
____________________
C. Michael Barton
On Nov 13, 2008, at 2:46 PM, Colin Nielsen wrote:
>> This is a BIG help and an equally big relief.
>
> Glad to help.
>>
>> Now the question arises as to what kind of units should the
>> friction map be
>> in to make sense in this kind of calculation.
>
> While I'm at it I can try this one too. Basically, without careful
> consideration, the use of a friction map will render the units of the
> output relative only (ie. unitless). Which isn't necessarily a bad
> thing unless you're set on knowing the actual time.
>
> The only way to avoid this is to make sure the friction map * lambda
> can logically be used to ADD time (rather than being used as a
> multiplier). I can't think of a dataset that would allow you to do
> this and I'm not even sure that adding the time it would take to cross
> a pixel of forest to the topographic time is an accurate way of
> representing multiple travel time factors. Good luck!
>
> -Colin
>
>>
>> Michael
>>
>> On Nov 13, 2008, at 1:06 PM, Colin Nielsen wrote:
>>
>>> If I understand your comment correctly then the current r.walk
>>> functionality is actually doing what you want it to be doing (ie.
>>> there is no problem). r.walk does not create a full cumulative cost
>>> map and then add the friction map, rather it combines the cumulative
>>> cost and friction cost with each origin pixel to neighbouring pixel
>>> calculation. If this was unclear in the help file perhaps an
>>> update to
>>> clarify is needed.
>>>
>>> See the snippet of code below from r.walk/main.c where "case 1"
>>> represents the consideration of the western neighbour:
>>>
>>> 1024 switch (neighbor) {
>>> 1025 case 1:
>>> 1026 dtm_value = &W_dtm;
>>> 1027 segment_get(&dtm_in_seg, dtm_value, row,
>>> col);
>>> 1028 cost_value = &W_cost;
>>> 1029 segment_get(&cost_in_seg, cost_value, row,
>>> col);
>>> 1030 if (G_is_d_null_value(cost_value))
>>> 1031 continue;
>>> 1032 if (((W_dtm - my_dtm) / EW_fac) >= 0)
>>> 1033 fcost_dtm = (double)((double)(W_dtm -
>>> my_dtm)
>>> * b);
>>> 1034 else if (((W_dtm - my_dtm) / EW_fac) <
>>> (slope_factor))
>>> 1035 fcost_dtm = (double)((double)(W_dtm -
>>> my_dtm)
>>> * d);
>>> 1036 else
>>> 1037 fcost_dtm = (double)((double)(W_dtm -
>>> my_dtm)
>>> * c);
>>> 1038 fcost_cost = ((double)(W_cost + my_cost) /
>>> 2.0);
>>> 1039 min_cost =
>>> 1040 pres_cell->min_cost + fcost_dtm +
>>> (EW_fac * a)
>>> +
>>> 1041 lambda * fcost_cost * EW_fac;
>>> 1042 break;
>>>
>>> The last calculation shows that the neighbour's new cost (min_cost)
>>> will be equal to the origin's cumulative cost (pres_cell-
>>> >min_cost) +
>>> the topographic/slope cost to move to the western neighbour
>>> (fcost_dtm) + lambda * the friction cost to move to the western
>>> neighbour (fcost_cost).
>>>
>>> I hope that helps and that I wasn't more long winded than was
>>> called for
>>> :).
>>>
>>> -Colin
>>>
>>>
>>> On Thu, Nov 13, 2008 at 2:34 PM, Michael Barton <michael.barton at asu.edu
>>> >
>>> wrote:
>>>>
>>>> Hi Colin,
>>>>
>>>>
>>>> On Nov 13, 2008, at 11:38 AM, Colin Nielsen wrote:
>>>>
>>>>> Not that I'm disagreeing with the need to change this
>>>>> functionality,
>>>>> but based on the way the algorithm incorporates the friction
>>>>> map, you
>>>>> can currently put zero for lambda and any map for the friction
>>>>> to have
>>>>> it work on slope alone. This is a little easier than the method
>>>>> you
>>>>> mentioned.
>>>>
>>>> This is a handy workaround. However, it is probably better in the
>>>> long
>>>> run
>>>> to fix this than to depend on a workaround.
>>>>
>>>>
>>>>>
>>>>>
>>>>> ie. total cost = movement time cost + (0 * friction)
>>>>>
>>>>> Further, I believe to make lambda and friction optional will take
>>>>> relatively substantial re-writes.
>>>>
>>>> Hopefully, this won't really take that much effort. However,
>>>> while we're
>>>> on
>>>> the subject, one of my students noticed something that might take
>>>> more
>>>> substantial rewrites and I guess I should mention it now.
>>>>
>>>> If we are correct on how r.cost uses a friction map (and this is
>>>> not 100%
>>>> certain), there is a fundamental flaw. A cost distance map should
>>>> have
>>>> cells
>>>> that represent cumulative cost outward from a starting point.
>>>> r.walk
>>>> automatically calculates this in seconds, making it a really useful
>>>> module
>>>> to have in GRASS.
>>>>
>>>> If the friction map is added in AFTER the initial cumulative
>>>> walking time
>>>> cost map is generated, the result will violate the cumulative
>>>> nature of
>>>> the
>>>> cost map. Imagine a map generated by r.walk with a cumulative
>>>> time cost
>>>> along a line of cells as follows:
>>>>
>>>> 0 | 100 | 120 | 150 | 250 | 350 |
>>>>
>>>> Now ADD a friction map to this
>>>>
>>>> 0 | 0 | 200 | 300 | 0 | -150 |
>>>>
>>>> Here is the result
>>>>
>>>> 0 | 100 | 320 | 450 | 250 | 200 |
>>>>
>>>> The final map is no longer the cumulative time to travel from the
>>>> origin.
>>>> More distant cells take less time to reach than closer cells.
>>>>
>>>> The friction map needs to be incorporated into the cost along with
>>>> topographic slope when the initial time map is created, not
>>>> afterwards.
>>>>
>>>> Michael
>>>>
>>>>
>>>>>
>>>>>
>>>>> -Colin
>>>>>
>>>>> On Thu, Nov 13, 2008 at 1:16 PM, Michael Barton <michael.barton at asu.edu
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> 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 <michael.barton at asu.edu>
>>>>>> Date: October 10, 2008 9:27:46 PM GMT-07:00
>>>>>> To: Helena Mitasova <hmitaso at unity.ncsu.edu>
>>>>>> Cc: grass developers <grass-dev at lists.osgeo.org>, Ullah Isaac
>>>>>> <Isaac.Ullah at asu.edu>, David.Quixal at uv.es, Sean Bergin
>>>>>> <Sean.Bergin at asu.edu>, Moreno Martín Andrea <andrea.moreno at uv.es>
>>>>>> 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 at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>>>>>
>>>>
>>>>
>>
>>
More information about the grass-dev
mailing list