[GRASSLIST:9387] r.walk and r.drain, and some other questions

Funny, just today I was starting to think about how to develop a friction
cost map using an elevation model and other data to compute a least-cost
path for walking in wilderness areas (i.e. with no established roads or
trails -- just finding the easiest way to get from here to there given
the terrain, vegetation, hydrography, etc.). Tonight I updated CVS and found
a new module called r.walk that appears (from what info there is so far) to be
very much related to exactly what I was pondering. Marcus, get out of
my head!

Anyhow, even without the mysterious and timely arrival of this new module,
I still had a question about how to accomplish something that I'd just
read about today as a related task in ArcGIS. Perhaps someone can
help me?

The paper I was reading was about computing paths through wilderness areas
to minimize the work needed to visit a small number (N) of sites starting from
the N+1th site. They did it by computing a friction surface for the region,
and generating N+1 cost surfaces (each one the cost surface with a given site
at origin). They used the N cost surfaces to compute N(N+1) least-cost
paths from each point to each of the others.

So far so good --- I see that in GRASS I'd have used r.cost if I were using
their particular friction surface (which I think is far too simplistic as
it is isotropic), and r.drain to compute a raster version of the least cost
path. And now that there's an r.walk (if it does what it seems to say it does) I won't have to figure out how to use r.spread and r.spreadpath to do this
with anisotropic costs due to the terrain.

But *then* they generated a vector network of paths and used network analysis
to compute the optimum route that minimized the work needed to visit the
various sites --- a travelling salesman problem, basically, but not only
trying to pick the right order of things to visit, but the best path
through the terrain to use to get there with the least effort and time.

I can see how I might generate such a vector network, by using r.to.vect
on each of the r.drain output rasters and then patching together the
vectors --- but how in the world could one attach cost columns to the vectors?
r.drain appears to be able to produce a raster where the pixels in the
least-cost path are the cost to get from the origin to that pixel, but
it doesn't seem like there's any way to get that information into a
vector created from that raster. Hints?

Assuming that there is in fact a way to convert the r.drain raster into
a vector with costs attached to the line segments, it shouldn't be that
difficult to do what these folks had done. Thoughts?

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"The only thing you can do easily is be wrong, and that's hardly
  worth the effort." -- Norton Juster

On Thu, Dec 08, 2005 at 10:12:35PM -0700, Tom Russo wrote:

Funny, just today I was starting to think about how to develop a friction
cost map using an elevation model and other data to compute a least-cost
path for walking in wilderness areas (i.e. with no established roads or
trails -- just finding the easiest way to get from here to there given
the terrain, vegetation, hydrography, etc.). Tonight I updated CVS and found
a new module called r.walk that appears (from what info there is so far) to be
very much related to exactly what I was pondering. Marcus, get out of
my head!

:slight_smile:
I also added the description now.

Anyhow, even without the mysterious and timely arrival of this new module,

strange things happen on this planet...

I still had a question about how to accomplish something that I'd just
read about today as a related task in ArcGIS. Perhaps someone can
help me?

I BCC to a colleague here who is probably thinking about the same
thing. Maybe he'll answer you or to the list.

The paper I was reading was about computing paths through wilderness areas
to minimize the work needed to visit a small number (N) of sites starting from
the N+1th site. They did it by computing a friction surface for the region,
and generating N+1 cost surfaces (each one the cost surface with a given site
at origin). They used the N cost surfaces to compute N(N+1) least-cost
paths from each point to each of the others.

So far so good --- I see that in GRASS I'd have used r.cost if I were using
their particular friction surface (which I think is far too simplistic as
it is isotropic), and r.drain to compute a raster version of the least cost
path. And now that there's an r.walk (if it does what it seems to say it does) I won't have to figure out how to use r.spread and r.spreadpath to do this
with anisotropic costs due to the terrain.

But *then* they generated a vector network of paths and used network analysis
to compute the optimum route that minimized the work needed to visit the
various sites --- a travelling salesman problem, basically, but not only
trying to pick the right order of things to visit, but the best path
through the terrain to use to get there with the least effort and time.

I can see how I might generate such a vector network, by using r.to.vect
on each of the r.drain output rasters and then patching together the
vectors --- but how in the world could one attach cost columns to the vectors?
r.drain appears to be able to produce a raster where the pixels in the
least-cost path are the cost to get from the origin to that pixel, but
it doesn't seem like there's any way to get that information into a
vector created from that raster. Hints?

I'm too tired now to clearly read above but I will submit a patch tomorrow
to make r.drain accept a vector path. Maybe it's what you need, maybe not.

Assuming that there is in fact a way to convert the r.drain raster into
a vector with costs attached to the line segments, it shouldn't be that
difficult to do what these folks had done. Thoughts?

--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
"The only thing you can do easily is be wrong, and that's hardly
  worth the effort." -- Norton Juster

Markus

--
Markus Neteler <neteler itc it> http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy