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

GRASS GIS GRASS GIS developer
1

On Dec 17, 2008, at 12:22 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Wed, 17 Dec 2008 07:22:45 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #295: region corrupted
To: undisclosed-recipients:;
Message-ID: <051.2301d585497eab3a94c92ac263194240@osgeo.org>
Content-Type: text/plain; charset="utf-8"

#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"?

This sounds fine. I need to look at the code again, but I'm pretty sure that most of the variance reported here is in the "Zoom display to computational region..." step. The display is designed to fit in the window regardless of whether the computational region has the same proportions as the window or not. The computational region can be seen with a colored rectangle that can be turned on or off.

When you 'Zoom computational region to display...', the region extents are actually set to match the display. I suppose there could be a pixel/grid cell difference, but the algorithm simply takes the display extents in real world coordinates and puts those into g.region.

If "align" seems a more accurate way to phrase this, then I'm in favor of it.

Michael

2

On 17/12/08 17:05, Michael Barton wrote:

On Dec 17, 2008, at 12:22 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Wed, 17 Dec 2008 07:22:45 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #295: region corrupted
To: undisclosed-recipients:;
Message-ID: <051.2301d585497eab3a94c92ac263194240@osgeo.org>
Content-Type: text/plain; charset="utf-8"

#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"?

This sounds fine. I need to look at the code again, but I'm pretty sure that most of the variance reported here is in the "Zoom display to computational region..." step. The display is designed to fit in the window regardless of whether the computational region has the same proportions as the window or not. The computational region can be seen with a colored rectangle that can be turned on or off.

When you 'Zoom computational region to display...', the region extents are actually set to match the display. I suppose there could be a pixel/grid cell difference, but the algorithm simply takes the display extents in real world coordinates and puts those into g.region.

This shows the advantage of the "strict" display mode in gis.m which avoids such confusion. So (nagging again): is it really too difficult to implement that in the wx gui ?

Moritz

3

On Dec 17, 2008, at 10:40 AM, Moritz Lennert wrote:

On 17/12/08 17:05, Michael Barton wrote:

On Dec 17, 2008, at 12:22 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Wed, 17 Dec 2008 07:22:45 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #295: region corrupted
To: undisclosed-recipients:;
Message-ID: <051.2301d585497eab3a94c92ac263194240@osgeo.org>
Content-Type: text/plain; charset="utf-8"

#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"?

This sounds fine. I need to look at the code again, but I'm pretty sure that most of the variance reported here is in the "Zoom display to computational region..." step. The display is designed to fit in the window regardless of whether the computational region has the same proportions as the window or not. The computational region can be seen with a colored rectangle that can be turned on or off.
When you 'Zoom computational region to display...', the region extents are actually set to match the display. I suppose there could be a pixel/grid cell difference, but the algorithm simply takes the display extents in real world coordinates and puts those into g.region.

This shows the advantage of the "strict" display mode in gis.m which avoids such confusion. So (nagging again): is it really too difficult to implement that in the wx gui ?

Moritz

Moritz

It is difficult, though not impossibly so of course. However, it is MUCH slower in displaying and could cause difficulties with other new display features developed for the wxGUI. In the original 'strict' TclTk display mode (which I sort of wish I had not even done in TclTk), the image display renders to the resolution of the computational region. It also needs to try to maintain the proportions of computational region within a display window of variable size and proportion. This can make rendering very slow since regions may have much higher resolutions than the display window. Also, due to the fact that cells are some kind of standard unit size, even this 'strict' mode sometimes cannot *exactly* render the display to match the computational region. However, because it comes closer, it is even more potentially confusing if there is an expectation that setting the window can set the region precisely. That is gone with the xterm d.zoom command. In most cases, d.zoom caused at least as many problems as it helped others--maybe more for most users.

In most other GIS systems that I've used, computations take place at the scale of the entire map. GRASS has masks and regions to constrain some GIS operations. Since we have regions, I think it is much cleaner conceptually (and less confusing) to make the user explicitly set the computational region extents and resolution, and not couple it to the display. Adding another display mode would be difficult to explain to most users (as it is now in the TclTk GUI), slower, and wouldn't really be a benefit as far as I can see.

Michael