Opened 17 years ago
Closed 16 years ago
#106 closed enhancement (fixed)
wxgrass: zoom to computational region does not respect resolution set with g.region
Reported by: | mlennert | Owned by: | martinl |
---|---|---|---|
Priority: | major | Milestone: | 6.4.0 |
Component: | wxGUI | Version: | svn-trunk |
Keywords: | wxgrass resolution zoom | Cc: | grass-dev@… |
CPU: | Unspecified | Platform: | Unspecified |
Description
When you set a resolution with g.region and then use the "Zoom to computational region" option, the resolution indicated in the display is not equal to the computational region's resolution. See http://geog-pc40.ulb.ac.be/grass/misc/wxgrass_resolution.png.
My config:
grass svn-head 20080327 python-wxgtk 2.8.7.1 python 2.4.4
Moritz
Change History (13)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Cc: | added |
---|---|
Owner: | changed from | to
Status: | new → assigned |
It is a feature. The display extent is always aligned to display window size. "Zoom to computational region" is not exception. Change statusbar mode to "Comp. extent" and enable "Show". The red colored box representing computational extent will be centered in the display.
Martin
follow-ups: 4 5 comment:3 by , 17 years ago
Cc: | removed |
---|---|
Type: | defect → enhancement |
The issue is not only the extent, but also the resolution.
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.
BTW, would also be nice to add "Zoom to default region" to the menu.
comment:4 by , 17 years ago
Replying to mlennert:
The issue is not only the extent, but also the resolution.
Well, you are speaking about resolution used for the display, the computational region settings are not changed.
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.
Yes, just to find time (now it has low priority in my TODO list) or more contributors.
BTW, would also be nice to add "Zoom to default region" to the menu.
OK
Martin
comment:5 by , 17 years ago
comment:6 by , 17 years ago
From grass-dev ML: mbarton:
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.
mlennert:
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.
For now I added new mode to the statusbar called "Comp. region". It shows extent and resolution of computational region settings. "Comp. extent" contains only checkbox to show computational extent outline in the display.
See r30779.
Sounds better?
Martin
follow-up: 9 comment:7 by , 17 years ago
More info is always better (could be formatted a bit better, with at least two more commas, but possibly spaces to make coordinates readable), but I do think a visualisation mode showing the exact computational region would be far superior. I won't insist though, as I seem to be the only one asking for this...
Moritz
follow-up: 10 comment:8 by , 17 years ago
see previous discussion:
http://thread.gmane.org/gmane.comp.gis.grass.devel/20610/focus=20714
a check box to turn the computational guide on|off would be nice.
Hamish
comment:9 by , 17 years ago
comment:10 by , 17 years ago
Replying to hamish:
see previous discussion:
http://thread.gmane.org/gmane.comp.gis.grass.devel/20610/focus=20714
Now display region extent is drawn as a blue box inside the computational region extent, computational region extent inside a display region extent as a red box. See r30816.
a check box to turn the computational guide on|off would be nice.
?
Martin
comment:11 by , 17 years ago
Michael:
But there is no point in making the display itself have the same resolution (xy pixels) as the map.
Either we are not speaking about the same thing, or I disagree. I do think that it can be very useful to display the map at more or less the same resolution as the computation region.
As images sometimes make things clearer, please look at http://geog-pc40.ulb.ac.be/grass/misc/wxgrass_resolution.png.
As you can see, the computational region's resolution is set to 300. The xmon-display makes it immediately obvious at which resolution we are working, whereas the wxgrass-display remains at a resolution of 30, even after zooming to the computational region.
I think that seeing the resolution used can be very helpful in many applications, so I still maintain that having a second viewing mode, just as in gis.m which totally respects the region settings, including resolution, would be very useful.
Moritz
comment:12 by , 16 years ago
Component: | Python → wxGUI |
---|
comment:13 by , 16 years ago
CPU: | → Unspecified |
---|---|
Platform: | → Unspecified |
Resolution: | → fixed |
Status: | assigned → closed |
Solved. See bug #293 for more details.
Sorry, forgot to mention that this is on Debian/Etch GNU/Linux.
Moritz