r.mapcalc gives wrong result when neighborhood modifier takes a cell above first

[wenzeslaus]

When I run G7:r.mapcalc with x = p[1,0] + p[-1,0] (r.mapcalc possibly first taking cell one row below), I get a correct result, but when I swap the parts if the expression to x = p[-1,0] + p[1,0] (r.mapcalc possibly first taking cell one row above), I get a wrong result. A reproducible example follows.

> r.in.ascii in=- out=p <<EOF
north: 10
south: 8
east: 20
west: 18
rows: 3
cols: 3
1 0 1
1 1 0
1 1 0
EOF
> g.region rast=p
> r.mapcalc "x1 = p[1,0] + p[-1,0]" && r.out.ascii x1
north: 10
south: 8
east: 20
west: 18
rows: 3
cols: 3
* * * 
2 1 1 
* * * 
> r.mapcalc "x2 = p[-1,0] + p[1,0]" && r.out.ascii x2
north: 10
south: 8
east: 20
west: 18
rows: 3
cols: 3
* * * 
2 2 0 
* * * 

I get same result with or without r67851 (row cache fix for #2917).

[wenzeslaus]

In 68708:

r.mapcalc: test for row order reading problem (see #3067)

[marisn]

I can confirm the issue with trunk r68709

[glynn]

In 68717:

Fix #3067

[glynn]

Replying to wenzeslaus:

A reproducible example follows.

This should be fixed by r68717.

[neteler]

Replying to glynn:

Replying to wenzeslaus:

A reproducible example follows.

This should be fixed by r68717.

Shall I backport it?

[glynn]

Replying to neteler:

Shall I backport it?

I think so. The previous version was clearly incorrect.

[wenzeslaus]

In 68722:

r.forestfrag: fix test reference data after r68717 (see #3067)

[neteler]

In 68768:

r.mapcalc: fix wrong result when neighborhood modifier takes a cell above first (trunk, r68717, fixes #3067)

[neteler]

In 68769:

r.mapcalc: fix wrong result when neighborhood modifier takes a cell above first (trunk, r68717, fixes #3067)

[neteler]

Backported in r68768 (relbr72), r68769 (relbr70).

Note that relbr64 seems not to be affected since the cache was introduced only in r34444 and not backported.