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

cmbarton · October 8, 2011, 3:29pm

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@PERMANENT” friction=“flat1m@PERMANENT” output=“cost1” start_points=“Elkhorn_Peak_site@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?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

Benjamin_Ducke1 · October 8, 2011, 3:55pm

+1 for backporting the r.walk 6.5 patches
to 6.4.2. They make the module a lot more useful.

Ben

On 10/08/2011 05:29 PM, Michael Barton 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@PERMANENT" friction="flat1m@PERMANENT"
output="cost1" start_points="Elkhorn_Peak_site@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?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer

benducke@fastmail.fm

Helena_Mitasova4 · October 9, 2011, 10:36pm

I am not sure whether it is relevant, but for our r.walk example here (nc_spm_08 data set)
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_granal2.html

the results from GRASS6.4.1 and GRASS7 are identical (I haven't tried it for 6.4.2, I assume it is same as 6.4.1?)

Helena

On Oct 8, 2011, at 11:29 AM, Michael Barton 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@PERMANENT" friction="flat1m@PERMANENT" output="cost1" start_points="Elkhorn_Peak_site@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?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

cmbarton · October 10, 2011, 6:20am

Helena,

Have you tried it in a Lambert projection?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Oct 9, 2011, at 3:36 PM, Helena Mitasova wrote:

I am not sure whether it is relevant, but for our r.walk example here (nc_spm_08 data set)
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_granal2.html

the results from GRASS6.4.1 and GRASS7 are identical (I haven't tried it for 6.4.2, I assume it is same as 6.4.1?)

Helena

On Oct 8, 2011, at 11:29 AM, Michael Barton 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@PERMANENT" friction="flat1m@PERMANENT" output="cost1" start_points="Elkhorn_Peak_site@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?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

Markus_GRASS · October 10, 2011, 7:33am

On Sat, Oct 8, 2011 at 5:29 PM, Michael Barton <Michael.Barton@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@PERMANENT" friction="flat1m@PERMANENT"
output="cost1" start_points="Elkhorn_Peak_site@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

cmbarton · October 10, 2011, 4:52pm

I got these differing results with elevation.dem in Spearfish, a UTM projection. The Lambert issue is a different one.

I'm not sure why r.walk should not work in a Lambert projection since the horizontal and vertical units are all in meters.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Oct 10, 2011, at 12:33 AM, Markus Metz wrote:

On Sat, Oct 8, 2011 at 5:29 PM, Michael Barton <Michael.Barton@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@PERMANENT" friction="flat1m@PERMANENT"
output="cost1" start_points="Elkhorn_Peak_site@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

cmbarton · October 10, 2011, 5:00pm

All I can say is that I did the following: I ran the exact same r.walk command in GRASS 7 and GRASS 6.4.2 on the same map in the Spearfish demo, on the elevation.dem topographic map. I then did a difference map of the results of these two r.walk runs.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Oct 9, 2011, at 3:36 PM, Helena Mitasova wrote:

I am not sure whether it is relevant, but for our r.walk example here (nc_spm_08 data set)
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_granal2.html

the results from GRASS6.4.1 and GRASS7 are identical (I haven't tried it for 6.4.2, I assume it is same as 6.4.1?)

Helena

On Oct 8, 2011, at 11:29 AM, Michael Barton 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@PERMANENT" friction="flat1m@PERMANENT" output="cost1" start_points="Elkhorn_Peak_site@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?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

cmbarton · October 10, 2011, 9:32pm

Hi Markus,

I didn't read this close enough. Thanks for the explanation.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Oct 10, 2011, at 12:33 AM, Markus Metz wrote:

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.

cmbarton · October 10, 2011, 10:21pm

So I guess it is not a resolution issue.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Oct 10, 2011, at 2:52 PM, Claudine Gravel Miguel wrote:

Hello,
so I reran it making sure I had the region at a high resolution (90m), and the result is the same. I’m attaching the output txt of the whole computation (with the info on the region) and the image showing the resulting raster. On a related note, this ‘flat’ walk was also produced when I tried running r.walk in a re-projection of a geoTIFF in UTM. This both in GRASS 6.4 and 7.

Thanks
Claudine

On Mon, Oct 10, 2011 at 2:32 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Hi Markus,

I didn’t read this close enough. Thanks for the explanation.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)

fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Oct 10, 2011, at 12:33 AM, Markus Metz wrote:

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.

<grass_cmd_history_walk.txt><Results_walk_Conical.png>