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.
If "align" seems a more accurate way to phrase this, then I'm in favor
of it.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
