#2277 closed enhancement (fixed)
graphically set up region bounds
| Reported by: | vincent | Owned by: | martinl |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.0.0 |
| Component: | wxGUI | Version: | unspecified |
| Keywords: | region | Cc: | grass-dev@… |
| CPU: | Unspecified | Platform: | Unspecified |
Description
When using grass with wx gui, one can regret the lack of an interactive tool in map display window that would allow to graphically determine region bounds via a drag-n-drop box. I don't mean to interact with region resolutions, only with boundaries. If I refer to gui/wxpython/mapdisp/mapwindow.py, it would be a kind of mix between functions Zoom(self, begin, end, zoomtype) and DisplayToWind(self). The latter is nice except if you need to define a region whose dimensions don't fit with the map display frame ratio...
My knowledge of python is too poor to propose any concrete coding, but I guess it should not be that tricky to implement.
Does anyone else think it's a good idea that wxgui provides an on-the-fly method for region setting ?
Change History (23)
follow-up: 2 comment:1 by , 10 years ago
| Milestone: | 6.4.4 → 7.0.0 |
|---|
follow-up: 3 comment:2 by , 10 years ago
Replying to martinl:
Slightly related, it's possible to set region extent from display, see
Various zoom options -> Set computational region from display extent.
Yes I use that, but proceeding this way may not be very handy : you have to resize the map display frame if you need to define e.g. an especially narrow region.
follow-ups: 4 11 comment:3 by , 10 years ago
Replying to vincent:
Replying to martinl:
Slightly related, it's possible to set region extent from display, see
Various zoom options -> Set computational region from display extent.Yes I use that, but proceeding this way may not be very handy : you have to resize the map display frame if you need to define e.g. an especially narrow region.
right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to relbr70.
follow-ups: 6 7 comment:4 by , 10 years ago
comment:5 by , 10 years ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
follow-up: 9 comment:6 by , 10 years ago
follow-up: 8 comment:7 by , 10 years ago
comment:8 by , 10 years ago
Replying to vincent:
Replying to martinl:
Replying to martinl:
right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to relbr70.
Various zoom options -> Set computation region extent interactivelyOops, line 1257 in grass/trunk/gui/wxpython/mapdisp/frame.py:
s/iteractively/interactively/
ops, fixed in r60059. Thanks for testing.
follow-up: 10 comment:9 by , 10 years ago
Replying to vincent:
Do you plan to backport this to 6.4 relbr too ?
not really, the code is different, it would require extra work. Moreover we are very close to RC1. Feature freeze time.
comment:10 by , 10 years ago
Replying to martinl:
Replying to vincent:
Replying to martinl:
right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to relbr70.
Do you plan to backport this to 6.4 relbr too ?
not really, the code is different, it would require extra work. Moreover we are very close to RC1. Feature freeze time.
And this is the problem of backporting features. Will we also backport to 6.5 (or even to 6.3)? And then fix the bugs in all branches (there are always some at least minor, such as typos) and also backport improvements (e.g. printing of the region to console to get some feedback) for the new features once they are in place in all branches.
follow-up: 12 comment:11 by , 10 years ago
comment:12 by , 10 years ago
Replying to martinl:
Replying to martinl:
right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to relbr70.
for record: backported to relbr70 as r60125
OK, a slight typo detail:
line 1235 in grass/branches/releasebranch_7_0/gui/wxpython/mapdisp/frame.py:
s/compulational/computational/
comment:13 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
follow-up: 15 comment:14 by , 10 years ago
Very nice tool, indeed, thanks !
Just wondering: in most of my applications, I generally would want to keep the resolution as set before, i.e. use the -a flag in the call to g.region. Otherwise, one will generally get weird resolutions since drawing the rectangle as a multiple of the desired resolution is a bit difficult.
Moritz
follow-ups: 16 17 comment:15 by , 10 years ago
Replying to mlennert:
Just wondering: in most of my applications, I generally would want to keep the resolution as set before, i.e. use the -a flag in the call to g.region. Otherwise, one will generally get weird resolutions since drawing the rectangle as a multiple of the desired resolution is a bit difficult.
Do you suggest to use this flag by default?
comment:16 by , 10 years ago
follow-up: 18 comment:17 by , 10 years ago
Replying to martinl:
Replying to mlennert:
Just wondering: in most of my applications, I generally would want to keep the resolution as set before, i.e. use the -a flag in the call to g.region. Otherwise, one will generally get weird resolutions since drawing the rectangle as a multiple of the desired resolution is a bit difficult.
Do you suggest to use this flag by default?
Yes.
Moritz
follow-up: 19 comment:18 by , 10 years ago
follow-ups: 20 21 comment:19 by , 10 years ago
Replying to martinl:
Replying to mlennert:
Do you suggest to use this flag by default?
Yes.
please try out r60251 (trunk).
Doesn't work for me. I still get values such as;
nsres: 9.9953005 ewres: 9.99522706
while working with the 10m resolution elevation data from the NC dataset. I've tried playing with the different constrain settings in the wxGUI MapDisplay ("Constrain display resolution to computational settings" and "Align region extent based on display size"), but no combination of the two seemed to do the trick.
Does the GUI internally redefine the region for display and then applies that region in that call to g.region ?
Moritz
comment:20 by , 10 years ago
Replying to mlennert: ...
Does the GUI internally redefine the region for display and then applies that region in that call to g.region ?
This reminds me of my question posted in grass-dev:
On Wed, Apr 16, 2014 at 6:09 PM, Markus Neteler <neteler@…> wrote:
Hi,
when trying to render a large raster map with d.rast in the "command line version" (d.mon wx0), then it tries to use the current region which leads to a cairo memory error.
It seems that the wxGUI is initializing the display in a more reasonable way to downsample the map to be rendered on the fly since it makes no sense to render it at original resolution. This "magic" is yet missing in d.mon.
Where is that calculated in wxGUI to get an idea about the calculation of map display window size versus raster map size/resolution?
Maybe related, maybe not. In any case a resolution/region issue.
follow-up: 22 comment:21 by , 10 years ago
Replying to mlennert:
Replying to martinl:
Replying to mlennert:
Do you suggest to use this flag by default?
Yes.
please try out r60251 (trunk).
Doesn't work for me. I still get values such as;
nsres: 9.9953005 ewres: 9.99522706while working with the 10m resolution elevation data from the NC dataset. I've tried playing with the different constrain settings in the wxGUI MapDisplay ("Constrain display resolution to computational settings" and "Align region extent based on display size"), but no combination of the two seemed to do the trick.
Does the GUI internally redefine the region for display and then applies that region in that call to g.region ?
There is no GUI magic, just try to run this and you see that the -a flag does nothing:
g.region -ap s=220660.881801 e=637854.596623 w=634055.347092 n=225295.966229
Apparently the -a flag requires the resolution parameter to be applied. Please try r60300.
Slightly related, it's possible to set region extent from display, see
Various zoom options -> Set computational region from display extent.In any case milestone moved to GRASS 7.