[GRASS-dev] [GRASS GIS] #295: region corrupted

GDAL · September 6, 2008, 11:41am

#295: region corrupted
----------------------+-----------------------------------------------------
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Keywords: | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295>
GRASS GIS <http://grass.osgeo.org>

GDAL · September 6, 2008, 11:44am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · September 6, 2008, 11:45am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · September 6, 2008, 11:46am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):

It's related to #293.

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · September 7, 2008, 12:03pm

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by msieczka):

Replying to [comment:2 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 1, 2008, 2:03am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/295#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 15, 2008, 4:01am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by glynn):

Replying to [comment:5 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 15, 2008, 9:48am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by 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).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 17, 2008, 7:22am

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by 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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · December 17, 2008, 5:16pm

#295: region corrupted
-----------------------+----------------------------------------------------
  Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution: wontfix | Keywords:
  Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Changes (by msieczka):

* status: new => closed
* resolution: => wontfix

Comment:

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/295#comment:9>
GRASS GIS <http://grass.osgeo.org>