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

Moritz Lennert mlennert at club.worldonline.be
Wed Dec 17 12:40:12 EST 2008


On 17/12/08 17:05, Michael Barton wrote:
> 
> 
> On Dec 17, 2008, at 12:22 AM, <grass-dev-request at lists.osgeo.org> wrote:
> 
>> Date: Wed, 17 Dec 2008 07:22:45 -0000
>> From: "GRASS GIS" <trac at osgeo.org>
>> Subject: [GRASS-dev] Re: [GRASS GIS] #295: region corrupted
>> To: undisclosed-recipients:;
>> Message-ID: <051.2301d585497eab3a94c92ac263194240 at osgeo.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> #295: region corrupted
>> -----------------------+---------------------------------------------------- 
>>
>>  Reporter:  msieczka  |       Owner:  grass-dev at 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


More information about the grass-dev mailing list