How to user "solver=" option of r.cost/r.walk

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to user "solver=" option of r.cost/r.walk

Benjamin Ducke-4
Dear Grass Users --

I am struggling to understand the usage of the
"solver=" option featured by both r.cost and
r.walk.

The r.walk manual page gives no details about it.
The r.cost manual page does contain an illustration
of the working principle, but no examples on how
to quantify the cells in the solver map. So it's
all a little too abstract for me.

I understand the basic premise: I have a relatively
coarse cost map, and r.cost's algorithm will often
encounter cells with many neighbours that have the
same cost. This produces ugly quantization effects
("steps") in least cost paths derived from such
surfaces. To work around this problem, I have so
far simply added some random noise to my cost
maps. However, it seems to me that the "solver="
option might be a more elegant, deterministic
solution to this problem.

So: Does anybody here have some experience with
the "solver=" option of r.cost? What kind of
values (ranges?) would a solver map contain?
How does r.cost interpret theses values (as
additional costs?). Could anyone come up with
an example of how to quantify a useful solver
map in practice?

Thanks!

Ben
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: How to user "solver=" option of r.cost/r.walk

Markus Neteler
Dear Benjamin,

On Wed, Jul 1, 2020 at 11:57 PM Benjamin Ducke <[hidden email]> wrote:
>
> Dear Grass Users --
>
> I am struggling to understand the usage of the
> "solver=" option featured by both r.cost and
> r.walk.

The implementation commit was this one (by Markus Metz):
https://github.com/OSGeo/grass/commit/2f86241cb733cf6c42a5f075aec9cb63be5bddc8

> The r.walk manual page gives no details about it.

That was probably an accidental omission and should be updated.

> The r.cost manual page does contain an illustration
> of the working principle, but no examples on how
> to quantify the cells in the solver map. So it's
> all a little too abstract for me.
>
> I understand the basic premise: I have a relatively
> coarse cost map, and r.cost's algorithm will often
> encounter cells with many neighbours that have the
> same cost. This produces ugly quantization effects
> ("steps") in least cost paths derived from such
> surfaces. To work around this problem, I have so
> far simply added some random noise to my cost
> maps. However, it seems to me that the "solver="
> option might be a more elegant, deterministic
> solution to this problem.
>
> So: Does anybody here have some experience with
> the "solver=" option of r.cost? What kind of
> values (ranges?) would a solver map contain?
> How does r.cost interpret theses values (as
> additional costs?). Could anyone come up with
> an example of how to quantify a useful solver
> map in practice?

Hope the author of the solver can enlighten us :-)

Best,
markusN
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user