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, <[email protected]>
wrote:
Date: Wed, 17 Dec 2008 07:22:45 -0000
From: "GRASS GIS" <[email protected]>
Subject: [GRASS-dev] Re: [GRASS GIS] #295: region corrupted
To: undisclosed-recipients:;
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
#295: region corrupted
-----------------------
+----------------------------------------------------
Reporter: msieczka | Owner: [email protected]
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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
