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
Dear Benjamin,
On Wed, Jul 1, 2020 at 11:57 PM Benjamin Ducke <benducke@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