Thanks Colin,This is all very helpful. The percentage friction map was a wish. It is clear that it can't be used that way with the current code. At least now it is very clear how lambda and a friction map interacts with the rest of the cost calculations. If some empirical tests could be made, it might be possible to suggest value ranges for a friction map that would give meaningful time values in the result. It would probably be good to get some of this information into the manual page. We will be using r.walk in a number of research settings, so we might come up with some information. If so, I'll pass it along.
Michael ______________________________ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Nov 15, 2008, at 6:06 PM, Colin Nielsen wrote:
Hi again,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 seemsto 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, butthis is not clear (What is W_cost?). I guess we need to know this to determine the units/value ranges for the friction map.Perhaps it would clarify things if I explain exactly how the two costs (topographic and friction) are calculated and then how they're combined. Beginning with the specified start point, an origin cell is selected. The topographic and friction costs are then calculated to each of its neighbours (8 or 16). The snippet of code I gave was for the western neighbour (ie. W_cost) but it continues with every other neighbour as well. In the code, W_dtm = the elevation cell value of the western neighbour, W_cost = the friction cell value of the neighbour, my_dtm = elevation of origin, my_cost = friction value of origin. The topographic cost is calculated by finding the difference in elevation between the origin and its neighbour over the horizontal resolution, dtm=digital terrain model: (W_dtm - my_dtm) / EW_fac. Depending on the slope and the specified slope_factor it is multiplied by one of the specified coefficients b,c,d to convert it to seconds (see the attached graph, assuming this list will accept attachments, nb. I converted the slope to degrees). The friction cost is calculated by summing half the friction of each of the origin cell and the neighbouring cell: (W_cost + my_cost) / 2.0). This is because the "walker" is travelling from cell center to cell center and therefore only has to walk across half of each pixel (actually in the code it is an average of the two cell values possibly to save on calculation time). With the next step, the other half of the pixel will be counted.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 beadded in.It might be convenient if it worked that way but since it is added, rather than multiplied, I don't think the friction as a percent of normal will work currently.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 tocross a cell and other factors increasing the time.I meant the friction is ADDed as opposed to being used as a multiplier. As you said, in theory, there is no reason why a negative friction cost couldn't be created which would then decrease the net time it took to cross the cell. As for the range of the friction map to create, empirical tests are probably the way to go. Possibly mountaineering guides would be a good source for this kind of data as well (especially since the r.walk equation was taken from one to begin with). Once completed, perhaps lambda could be used for a global conversion between friction map values and friction time (as I'm guessing it was originally intended for this). I hope you and your students are finding this as interesting to work on as I have. -ColinOn 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 mapbe in to make sense in this kind of calculation.While I'm at it I can try this one too. Basically, without carefulconsideration, the use of a friction map will render the units of theoutput 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 dothis and I'm not even sure that adding the time it would take to crossa pixel of forest to the topographic time is an accurate way of representing multiple travel time factors. Good luck! -ColinMichael 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 toclarify 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:). -ColinOn Thu, Nov 13, 2008 at 2:34 PM, Michael Barton <[EMAIL PROTECTED] >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 youmentioned.This is a handy workaround. However, it is probably better in the longrun 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 takerelatively substantial re-writes.Hopefully, this won't really take that much effort. However, whilewe're onthe subject, one of my students noticed something that might take moresubstantial rewrites and I guess I should mention it now.If we are correct on how r.cost uses a friction map (and this is not100%certain), there is a fundamental flaw. A cost distance map should havecellsthat represent cumulative cost outward from a starting point. r.walk automatically calculates this in seconds, making it a really usefulmodule to have in GRASS.If the friction map is added in AFTER the initial cumulative walkingtimecost map is generated, the result will violate the cumulative nature ofthecost map. Imagine a map generated by r.walk with a cumulative time costalong 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 <[EMAIL PROTECTED]> wrote:Several weeks back, Helena gave a very good explanation of how r.walk actually works. It makes very good sense (see below). However, fromthisexplanation, 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 towalk across a landscape. For any cell,total time = (walking time in seconds to traverse the cell given itsslope) + (lambda * friction map)Lambda is a weighting coefficient to convert the friction map tounits 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 isbasedsolely on the topography (i.e., slope), then you need a friction mapwith a value of 0; lambda can be anything. So this should be optional. Currently, you need to create a 0 friction mapand 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 forour 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.walkThanks very much for this thorough explanation Helena. It is quitehelpful. 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 either1) 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 ofenergy units.However, as I understand it, the values in an r.walk map-- using thedefaultvalues--are an estimate of the number of seconds to traverse a cellwalking'normally' (i.e., according to the default values). Is this trueanyone? 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 theoutput isactually telling us, since it does not seem to be in arbitrary unitslike r.cost is (unless you do some numerical massaging).these are perfectly valid questions - authors should probably answerthem rather than mebut we tried to put some explanation based on the manual in to theappendix of GRASSbookand I have just covered it in the class so I had to spend some timetrying to understand it. the units are - according to the manual - time - see belowS, H are meters but the coefficients a,b,c,d are 1/speed which issec/meter giving you time in seconds,then friction map can be either in units of time (sec) and lambda isunitless 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 theresults you will get isochrones -so you can delineate an area where the person gets within 2 hours orwhatever time you chose.But it would be really good to hear from the authors because theseare my interpretationsof the manual and my experiments with the module. The man page isprettygood it just needs to be more clear that the cost is measured by time(if I understand it correctly) HelenaT= [(a)*(Delta S)] + [(b)*(Delta H uphill)] + [(c)*(Delta H moderatedownhill)] + [(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 moderatedownhill * d: underfoot condition and cost associated to movement steep downhill It has been proved that moving downhill is favourable up to a specific slopevalue threshold, after that it becomes unfavourable. The defaultslope 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 proposedbyLangmuir (0.72, 6.0, 1.9998, -1.9998), based on man walking effort instandard conditions.The lambda parameter of the linear equation combining movement andfriction 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 froma DEM) in r.walk. It seems a good idea to put this back on the list.PerhapsI'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 thecode, this second interpretation applies.For anyone familiar with the code, is this the case? If so, should Ibethinking 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 thecell?Or is friction a weighting factor (i.e., multiplicative rather thanadditive)? Thanks Michael _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev<dtm_cost.png>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
