# Cell Size and nonsensical results from GRASS r.walk

I've been wrestling with two main problems the past six hours. I am using 30m resolution aster/srtm merged dem. When I use the r.walk function to calculate a walking time surface from a point, the output looks good, but when I check the values, they make no sense. That is, the time it takes to travel is way underestimated, often by a factor of 3 or more. I am assuming that the results are in seconds, so I divide that by 3600 to get the value in hours. Actually, given the terrain (Andes), the times are impossible because the velocity implied by the results is way more than 5km/hr (about 20km an hour). I tried using just the dem and setting lambda to 0 for the friction. I tried using a reclassed slope as the friction surface. Both yield similar results.

The second issue is that when I zoom in to check the cell size, it's about 1.5km on each side! I don't know how that's determined because all the raster inputs are 30m resolution. The extent of the GRASS region isn't that big, either. Maybe 150 by 150km. I can't find any resources that address this issue.

• Ok, I figured out the cell size problem. I had to edit the current grass region and set the resolution higher. Oct 24, 2017 at 0:05
• Yeah, quoting a grass tutorial "The "region" is a cornerstone concept in GRASS. If you want to be able to use GRASS to its full potential, you have to understand it.". Solving the "inconsistent" cell size, you will probably solve the rest Oct 24, 2017 at 7:48
• After making sure the resolution matched the dem, the results still don't make sense. R.walk underestimates by a factor of 4-5. Any ideas how to fix this? Oct 24, 2017 at 19:09
• For example, I zoomed in three points 100m away. Their values were 10, 8, and 45. If the results are in seconds, it's way faster than 5km an hour on a flat surface. Oct 24, 2017 at 19:27