[GRASS-user] negative slope values and movement costs

[Miguel Correia]

I suppose that the accuracy of the algorithm you use depends on the type of
terrain you want to model. Anyway, sometimes the resolution of the DEM used
implies more influence on the final result than the algorithm used to
generate the friction surface (which in the case of Tobler's hiking function
represents a velocity map).
The region that I'm trying to model it's quite rocky (although it is not
Everest… I ensure you). By the other hand, Tobler's function is far from
been perfect (just like all these hiking functions, Naismith's, the one used
in r.walk, it's far from being perfect too…). Anyway, it seems that for this
particular region in northwest Spain , Tobler's hiking function and a 25x25m
DEM is sufficient to produce reliable results. Obviously it will never
produce perfect results (which is impossible, I suppose), but it's a good
starting point.


It would be very interesting if we could use this forum to keep discussing
how Grass can model these questions, don't you think? Yesterday I wrote some
things that are wrong and I'm working on what I think it might be the
solution. Let's keep talking about this. How did you resolve this problem
with hydrology?



Miguel.


2007/2/2, Glynn Clements <glynn at gclements.plus.com>:
>
>
> Michael Barton wrote:
>
> > If you are calculating round-trip, simply create a slope map and use the
> > original Tobler algorithm to make a positive (i.e. uphill) cost map and
> a
> > negative (downhill) cost map. Then add them together and use the summed
> > result as the basis for a round-trip cost surface. If you are doing
> one-way
> > only you¹ll need an anisotropic algorithm. Perhaps you can modify the
> > coefficients in r.walk to simulate a Tobler result. If not you can
> create
> > the whole thing in the map calculator (e.g., using neighborhood
> functions)
> > or the best way would be to work with Markus on r.walk to add the Tobler
> > algorithm as an option if it is widely used and generally desirable.
>
> You can't implement r.cost/r.walk purely with r.mapcalc, as such an
> algorithm is inherently stateful, while r.mapcalc is stateless.
>
> You would probably want to modify r.walk or r.cost. One relatively
> simple option would be to modify r.cost to use 8 different cost maps:
> one for each of the possible directions (I'm ignoring -k here). You
> could generate the cost maps from a DEM using r.mapcalc.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20070202/661e4345/attachment.html