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

[Tom Russo]

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