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

Michael Barton michael.barton at asu.edu
Wed Dec 17 14:06:40 EST 2008


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 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

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



More information about the grass-dev mailing list