[GRASS-user] 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 <benducke at fastmail.fm> 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