[GRASS-dev] Re: [GRASS GIS] #106: wxgrass: zoom to computational region does not respect resolution set with g.region

GRASS GRASS developer
1

On Mar 27, 2008, at 3:10 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Thu, 27 Mar 2008 10:03:45 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] Re: [GRASS GIS] #106: wxgrass: zoom to
  computational region does not respect resolution set with g.region
To: undisclosed-recipients:;
Message-ID: <051.487a2804b30e0d4102ab7164ef71db69@osgeo.org>
Content-Type: text/plain; charset="utf-8"

#106: wxgrass: zoom to computational region does not respect resolution set with
g.region
--------------------------+-------------------------------------------------
  Reporter: mlennert | Owner: martinl
      Type: enhancement | Status: assigned
  Priority: major | Milestone: 6.4.0
Component: Python | Version: svn-trunk
Resolution: | Keywords: wxgrass resolution zoom
--------------------------+-------------------------------------------------
Changes (by mlennert):

* cc: mlennert@club.worldonline.be (removed)
  * type: defect => enhancement

Comment:

The issue is not only the extent, but also the resolution.

Yes. This was Martin's point. We've made it so that the display resolution stays constant regardless of the computational region. This makes the display render MUCH MUCH faster. The only drawback of having the display region stay constant in this way is that d.rast.num won't work as it now is. This is probably fixable either by modifying d.rast.num or by tweaking the GUI. But it hasn't been as high a priority as other items yet.

I think it would be useful to have the same system as in gis.m, i.e. with
one display mode aligning to window size and another mode showing the
exact computation region, i.e. respecting extent and resolution.

I think that these two different modes are fairly confusing to most users.

Martin has implemented something that I think is much more useful and easier to understand, and that serves the same purpose. As mentioned above, the display always fills the window and has a constant resolution. However, the computational region is shown by a red box outline. This means you can always tell the region in which map modification operations will take place, without having a very strange-looking map in the display window, with a lot of white space around it.

BTW, would also be nice to add "Zoom to default region" to the menu.

Good idea.

Michael

2

On 28/03/08 07:10, Michael Barton wrote:

I think it would be useful to have the same system as in gis.m, i.e. with
one display mode aligning to window size and another mode showing the
exact computation region, i.e. respecting extent and resolution.

I think that these two different modes are fairly confusing to most users.

Martin has implemented something that I think is much more useful and easier to understand, and that serves the same purpose. As mentioned above, the display always fills the window and has a constant resolution. However, the computational region is shown by a red box outline. This means you can always tell the region in which map modification operations will take place, without having a very strange-looking map in the display window, with a lot of white space around it.

But that brings us back to my original response ("The issue is not only the extent, but also the resolution."). Yes, the red box is very useful (although the functionality is maybe a hidden - maybe the "show" text box should always be visible and read "show extent of computational region", but a visual information about the resolution is also very important. It has happened to me often enought that I launch a command which then takes much longer than expected, only to find out that the computational region's resolution was much higher than the display's. Having a mode which allows seeing the exact computational region settings is, thus, very helpful...No need to make it the default, and you could possibly hide it a bit to not confuse users, but IMHO, it should be an option for power users.

Moritz

3

On Mar 28, 2008, at 5:32 AM, Moritz Lennert wrote:

On 28/03/08 07:10, Michael Barton wrote:

I think it would be useful to have the same system as in gis.m, i.e. with
one display mode aligning to window size and another mode showing the
exact computation region, i.e. respecting extent and resolution.

I think that these two different modes are fairly confusing to most users.
Martin has implemented something that I think is much more useful and easier to understand, and that serves the same purpose. As mentioned above, the display always fills the window and has a constant resolution. However, the computational region is shown by a red box outline. This means you can always tell the region in which map modification operations will take place, without having a very strange-looking map in the display window, with a lot of white space around it.

But that brings us back to my original response ("The issue is not only the extent, but also the resolution."). Yes, the red box is very useful (although the functionality is maybe a hidden - maybe the "show" text box should always be visible and read "show extent of computational region", but a visual information about the resolution is also very important. It has happened to me often enought that I launch a command which then takes much longer than expected, only to find out that the computational region's resolution was much higher than the display's. Having a mode which allows seeing the exact computational region settings is, thus, very helpful...No need to make it the default, and you could possibly hide it a bit to not confuse users, but IMHO, it should be an option for power users.

Moritz

Moritz,

I agree that it would be quite helpful for just the reason you describe to have the computational resolution shown, if it's not (it may be an option, but I don't remember at the moment). This is a good idea to add that to the display option.

But there is no point in making the display itself have the same resolution (xy pixels) as the map.

Michael