[GRASS-dev] r.walk issues for 6.4.2?

[Markus Metz]

On Sat, Oct 8, 2011 at 5:29 PM, Michael Barton <Michael.Barton at asu.edu> wrote:
> One of my students was having problems with r.walk not properly reflecting
> surface topography in 6.4.2 svn (from a few weeks ago).
> So I checked it out today. My comparison is not quite the same as hers as
> she is on Mac OS X 10.6.8 and I've tested this on 10.7.2 (Lion). But we're
> using the same GRASS builds (done with 10.6.8 on my other computer).
> I did not have the same problem she did. I tested with the Spearfish demo
> set. She is using a DEM in a Lambert Conformal Conic projection (which I
> suppose might be a problem for some reason).
> However, I did turn up something of interest for the upcoming GRASS 6.4.2
> release.
> In 6.4.1, we did not include the new backlink map option, but I thought it
> was going to be in 6.4.2. So far it has not been backported from 6.5.
> Also, running r.walk without the backlink in GRASS 6.4.2 and GRASS 7
> produces significantly different results. Here are the links to a couple of
> outputs of a difference map between r.walk on 6.4.2 minus r.walk on GRASS 7
> using exactly the same command and files.
> r.walk elevation="elevation.dem at PERMANENT" friction="flat1m at PERMANENT"
> output="cost1" start_points="Elkhorn_Peak_site at G7_vector" max_cost=0
> percent_memory=100 walk_coeff="0.72,6.0,1.9998,-1.9998" lambda=1.0
> slope_factor=-0.2125
> http://dl.dropbox.com/u/7437464/rwalk_diff.jpg
> http://dl.dropbox.com/u/7437464/rwalk_diff_histogram.png
> As you can see, there are very patterned differences in the behavior of
> r.walk between the 2 GRASS versions. The differences are not huge (in the
> range of +3 to -13 minutes), but are still notable.  Beyond adding the
> backlink option, do the r.walk algorithms differ significantly between them?
> Also, has anybody had any problems with r.walk in a Lambert projection?
>
There should be no differences between GRASS 7 and GRASS 6.4, at least
in my tests there are no differences.

The problem you experience has most likely nothing to do with Lambert
projection, instead I suspect with the resolution of 1km posted in the
ticket. Even though the results appear to make sense in geographic,
this is pure accident. In fact, r.walk is not supposed to work with
geographic because r.walk assumes meters as both horizontal and
vertical units.

The formula given in the manual and implemented in (all versions of)
r.walk is IMHO weird because the c coefficient results in negative
time required to cross a moderate downhill slope, but walking humans
can not travel backwards in time, and the Dijkstra search requires for
good reason positive costs. With large horizontal resolutions, e.g.
1km, the time required to cover the distance from one cell to the next
cell is much larger than most encountered slopes. At least the r.walk
algorithm behaves likes this, which results in a sort of manhattan
distance map as obtained in a flat landscape.

Markus M