region corrupted

[msieczka]

1. Set region on CLI to something complex, like:

$ g.region n=883092.909724 s=883084.031429 w=236640.192128 e=236652.239791 nsres=5.10978688 ewres=3.92674331 -g

n=883092.909724
s=883084.031429
w=236640.192128
e=236652.239791
nsres=4.4391475
ewres=4.01588767
rows=2
cols=3
cells=6

2. In wxGUI: "Zoom to computational region..."

3. In wxGUI: "Set computational region from display"

4. On CLI:

$ g.region -g

n=883092.929617
s=883084.051322
w=236640.196842
e=236652.244505
nsres=4.4391475
ewres=4.01588767
rows=2
cols=3
cells=6

Bad. The region extent must not be different in both g.region -g outputs. wxGUI does something wrong when dealing with floating-point region settings.

[martinl]

Extent is by default changed based on display size...

[martinl]

To be more precise, extent is always changed to accommodate whole map canvas. I don't see any wrong here.

[martinl]

It's related to #293.

For "free display mode" this behaviour is corrent (wxGUI works like that).

[msieczka]

Replying to martinl:

To be more precise, extent is always changed to accommodate whole map canvas. I don't see any wrong here.

"Zoom to computational region..." is supposed to set the 'display region' match the 'computational region', right? And "Set computational region from display" should make 'computational region' equal the 'display region', right?

Then I don't see a reason why the region extent should change during these operations, like it does - i.e., the region extent in step 1 and 4 should be equal. They are not though.

It's either a bug, or the 2 functionalities in questions don't do what they claim they would.

[hamish]

before g.region -a shift

[hamish]

after g.region -a

[hamish]

All that has happened here is that 'g.region -a' has been run by the GUI, which "snaps to the grid".

n-s is the same in both of your cases, but in the second case n,s is exactly divisible by the nsres. (give or take 2e-6 error introduced by g.region outputting to terminal using %f; internally the double prec FP variables will equate)

By default if there is a conflict g.region respects the region bounds over the resolution (I would guess this reduces >90deg LL problems and is the less risky solution in the original GRASS military context!). With the -a flag the resolution grid is respected over the bounds and the bounds are "snapped" to the resolution grid with origin 0,0.

this causes an interesting problem,

G> g.region n=100525 s=100475 w=500825 e=500875 res=50 -g
n=100525
s=100475
w=500825
e=500875
nsres=50
ewres=50
rows=1
cols=1
cells=1

G> r.mapcalc one=1

G> g.region res=50 -a -g
n=100550
s=100450
w=500800
e=500900
nsres=50
ewres=50
rows=2
cols=2
cells=4

G> d.rast one
G> d.grid 25

note that g.region rounds outwards, and that resampling shifts the cell to the N and W by 1/2 a cell. In these cases my work around solution has been to half the resolution, g.region res=25 -ag then no resampling shift occurs by careless user mistake.

You ran:

3. In wxGUI: "Set computational region from display"

so you can expect the region to change.

If there is a problem it is that the g.region n=100525 s=100475 w=500825 e=500875 res=50 -g case may? be resamped by the GUI into the attached "after -a" image. I haven't checked that. But if you know about the resampling issue (I believe there's a paragraph about it in the g.region help page), this problem is easily worked around, and much less painful than having -a as the default. (IMO to switch that would be a horrible mistake)

fwiw, screenshots created with xmons+d.out.file, not from the GUI.

Hamish

[glynn]

Replying to hamish:

All that has happened here is that 'g.region -a' has been run by the GUI, which "snaps to the grid".

Maybe "Zoom to computational region..." should read "Zoom to something approximating the computational region..."?

Okay, that's only half serious, but it might be worth pointing out that it doesn't zoom to exactly the computational region. Or it might be worth adding an option which does zoom to exactly the computational region.

[martinl]

By Michael Barton from grass-dev:

For #295, the region is not really "corrupted". g.region should be used for precise setting of extents and resolution of the computational region, not the interactive display canvas. Zooming the display (approximately) to the computational region is a convenience option that is indeed very handy, but not precise. Setting the computational region from the display is precise I believe (that is, the computational extents match the display extents), but is still a convenience rather than designed to be a precision control (that is, the extents match within the limits of the display and computational region resolutions).

[hamish]

ok, so it is a matter of expectations.

how to improve the wording?

• I think all the "Zoom display to ..." menu items can stay as-is, as it is not as critical if the display region is slightly askew. -- it's just a visual thing. So vague language is ok here.

• My suggestion to solve this ticket is to reword "Set computational region extents to match display". It is critical to have the computational region set cleanly for computations, and g.region -a is needed to avoid sloppy regions set from the display. So crisp language is needed to explain this.

Replace "to match" with "from"? that makes it more technically correct, but still doesn't address the user expectation issue very well. Replace "Set" with "Align"? That puts forward the idea that the two grids are still somewhat independent.

how about: "Align computational region to current display"?

Hamish

[msieczka]

That's all just sweeping the dust under the carpet, claiming that half-pregnancy is possible and stuff.