Why r.walk calculates different cumulative cost depending on calculation direction

[skitourenguru]

Describe the bug I have two points A and B. If I calculate cumulative costs from A to B respectively from B to A I expect the same cumulative costs at the arrival points. Take into account that the walk_coeff are set symmetrically:

From A to B: a,b,c,d=0.72,6,10,-10 From B to A: a,b,c,d=0.72,10,6,-6

Details for abcd you find under r.walk

To Reproduce Data-Sample. All data have EPSG=21781.

r.walk elevation=dem@PERMANENT friction=cost@PERMANENT output=cumCostUp outdir=movDirUp start_points=start@PERMANENT stop_points=stop@PERMANENT max_cost=10000000 null_cost=16000 walk_coeff=0.72,6,10,-10 lambda=0.2 --overwrite

v.what.rast map=stop@PERMANENT raster=cumCostUp@PERMANENT column=cumCost

r.walk elevation=dem@PERMANENT friction=cost@PERMANENT output=cumCostDown outdir=movDirDown start_points=stop@PERMANENT stop_points=start@PERMANENT max_cost=10000000 null_cost=16000 walk_coeff=0.72,10,6,-6 lambda=0.2 --overwrite

v.what.rast map=start@PERMANENT raster=cumCostDown@PERMANENT column=cumCost

Expected behavior Cumulative costs should be the same at the arrival-points independent of direction. With resolution=1 the cumulative costs differ: start/stop = 50021.4056830234/50129.4681520099. If calculated at resolution=10, the cumulative costs differ much more.

System description (please complete the following information):

• Operating System: Windows 10
• GRASS GIS version: 7.8.6

Additional context

• dem and cost have a resolution of 10m. Pixels are tapped to 10 m (-tap from GDAL)
• start and stop coordinates are in X and Y: n*10 + 5
• Calculation resolution: The difference becomes big if r=10. The difference becomes minimal with very small resolutions r=1 or r=0.1 (r.region res=r). So the mirroring of abcd is correct.
• If b=c=d=0 there isn't anymore an asymmetry.
• If uphill and downhill cost are set both to 6 there is still an asymmetry.

Stackexchange Issue at Stackexchange

[petrasovaa]

There is an answer on Stackexchange, does that sufficiently answer the question?

[skitourenguru]

No, the answer on Stackexchange makes clear, that no careful look at the parameters a,b,c,d was done.

[isaacullah]

This behavior is correct because r.walk is an anisotropic cost function. Therefore, the costs from A --> B should be different than from B --> A. If you want the costs to be the same, you need to use r.cost with an isotropic algorithm to calculate the input friction values.

[petrasovaa]

This behavior is correct because r.walk is an anisotropic cost function. Therefore, the costs from A --> B should be different than from B --> A. If you want the costs to be the same, you need to use r.cost with an isotropic algorithm to calculate the input friction values.

I think @skitourenguru was trying to address this with the changed a,b,c,d parameters, no?

[isaacullah]

Yes, but his two sets of walking coefficients are still not going to make Naismith's rules isotropic because the slope cutoff means the slope bins are anisotropic to begin with. It might be possible to tune all of those parameters to make r.walk isotropic, but Naismith's rules are meant to be anisotropic. IMO, he's much better off using r.cost and a symmetrical cost algorithm like Tobler's rules.

Sent from my📱

On Thu, Apr 13, 2023, 11:22 AM Anna Petrasova @.***> wrote:

This behavior is correct because r.walk is an anisotropic cost function. Therefore, the costs from A --> B should be different than from B --> A. If you want the costs to be the same, you need to use r.cost with an isotropic algorithm to calculate the input friction values.

I think @skitourenguru https://github.com/skitourenguru was trying to address this with the changed a,b,c,d parameters, no?

— Reply to this email directly, view it on GitHub https://github.com/OSGeo/grass/issues/2496#issuecomment-1507429643, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDYS5GXKPXN7MFJ5I5GQC3XBA767ANCNFSM54RPYZTA . You are receiving this because you commented.Message ID: @.***>

[skitourenguru]

Please take into account the third additional remark: Calculation resolution: The difference becomes big if r=10. The difference becomes minimal with very small resolutions r=1 or r=0.1 (r.region res=r). So the mirroring of abcd is correct.

If r would be set to a very small value, lets say r=0.001, the asymmetry would completely disapper. So r.walk is by theory and by practice isotropic, if the parameters abcd are set inversly.

Please try it out. r.walk has a minor bug! Here you find SampleData.

[skitourenguru]

Is Dijkstra's Algorithm symmetrical? If the graph is not directional, the set of shortest paths from A to B is the same as set of shortest paths from B to A. You can prove it by the contradiction. With the mentioned settings a,b,c,d the graph is not directional. Therefore r.walk must have a minor bug in the source code.

[skitourenguru]

c must be equal to d.

The following example produces a symmetrical result for all resolutions r, also for r=10: From A to B: a,b,c,d=0.72,6,-10,-10 From B to A: a,b,c,d=0.72,10,-6,-6