Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

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

comment:1 Changed 6 years ago by martinl

Milestone: 6.4.47.0.0

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.

comment:2 in reply to:  1 ; Changed 6 years ago by 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.

comment:3 in reply to:  2 ; Changed 6 years ago by martinl

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.

comment:4 in reply to:  3 ; Changed 6 years ago by 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 interactively

comment:5 Changed 6 years ago by martinl

Cc: grass-dev@… added
Owner: changed from grass-dev@… to martinl
Status: newassigned

comment:6 in reply to:  4 ; Changed 6 years ago by 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 interactively

Great, Martin ! it works like a charm... Do you plan to backport this to 6.4 relbr too ?

Thank you

comment:7 in reply to:  4 ; Changed 6 years ago by 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 interactively

Oops, line 1257 in grass/trunk/gui/wxpython/mapdisp/frame.py:
s/iteractively/interactively/

comment:8 in reply to:  7 Changed 6 years ago by martinl

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 interactively

Oops, line 1257 in grass/trunk/gui/wxpython/mapdisp/frame.py:
s/iteractively/interactively/

ops, fixed in r60059. Thanks for testing.

comment:9 in reply to:  6 ; Changed 6 years ago by martinl

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 in reply to:  9 Changed 6 years ago by wenzeslaus

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.

comment:11 in reply to:  3 ; Changed 6 years ago by 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

comment:12 in reply to:  11 Changed 6 years ago by vincent

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 Changed 6 years ago by martinl

Resolution: fixed
Status: assignedclosed

comment:14 Changed 6 years ago by mlennert

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

comment:15 in reply to:  14 ; Changed 6 years ago by 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?

comment:16 in reply to:  15 Changed 6 years ago by vincent

Replying to martinl:

Do you suggest to use this flag by default?

+1 for the default -a flag.

comment:17 in reply to:  15 ; Changed 6 years ago by mlennert

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

comment:18 in reply to:  17 ; Changed 6 years ago by martinl

Replying to mlennert:

Do you suggest to use this flag by default?

Yes.

please try out r60251 (trunk).

comment:19 in reply to:  18 ; Changed 6 years ago by 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.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 in reply to:  19 Changed 6 years ago by neteler

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.

comment:21 in reply to:  19 ; Changed 6 years ago by annakrat

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

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.

comment:22 in reply to:  21 Changed 6 years ago by mlennert

Replying to annakrat:

Apparently the -a flag requires the resolution parameter to be applied. Please try r60300.

Works great, thanks !

Moritz

comment:23 Changed 6 years ago by annakrat

Backported in r60377.

Note: See TracTickets for help on using tickets.