[GRASS-dev] Region setting correction

cmbarton · August 19, 2006, 5:21am

I wanted to correct a few things I just said about region settings.

If you run g.region from the command line—either with arguments (e.g., g.region –p) or without arguments so that it starts one of the autogenerated GUI dialogs—it sets and/or reports on the values in the WIND file. This is the way I described it a few minutes ago.
BUT, if you run g.region from the menu, there is anomalous behavior that may be the cause of considerable and repeated confusion. G.region started from the menus will REPORT (i.e., with –p set) on the region of the currently active display window (i.e., whichever display currently has the focus). If you try to set something with g.region run from the menu, it seems to have NO EFFECT on a display OR on the WIND file.
However, if you set something from a g.region dialog run from the menu AND select ‘zoom to current region’ from the menu button on the toolbar, the display will match the g.region settings—even though this is NOT in the WIND file.
If you set something from a g.region dialog started from the command line (or issue a g.region command with arguments) and select ‘zoom to current region’ from the menu button on the toolbar, it will have NO EFFECT on the display zooming.
If you zoom interactively in a map display and select ‘set current region (WIND file) to match display’, this WILL change the WIND file to match the display (check by running g.region –p from the command line). At this point, it can insert some rounding error in resetting the WIND file to match the display. I think this is what Maciek is seeing. I tried changing to a g.region –a (align to current region) and it had no effect on this rounding error.

The map display interactive zooming and zoom menu button are behaving as they should.

Interactive zooming affects a dynamic region ONLY for that display and DOES NOT affect the WIND file
Selecting ‘zoom to current region’ DOES change the display to match the settings of g.region run from the menu—but NOT from the command line.
Selecting ‘set current region (WIND file)…’ DOES change the WIND file to match the display.

BUT (and a very confusing one at that), g.region run from the command line and g.region run from the menus do NOT always behave the same way with regard to the interactive zooming in a display. I have no idea why this is so. Maybe someone else can enlighten me.

Michael

Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Glynn_Clements1 · August 19, 2006, 9:01am

Michael Barton wrote:

BUT (and a very confusing one at that), g.region run from the command line
and g.region run from the menus do NOT always behave the same way with
regard to the interactive zooming in a display. I have no idea why this is
so. Maybe someone else can enlighten me.

The only plausible explanation is that WIND_OVERRIDE isn't always
being unset before g.region is run from gis.m, resulting in g.region
modifying something other than the WIND file.

In fact, AFAICT, WIND_OVERRIDE will always be set; searching for
WIND_OVERRIDE in gui/tcltk/gis.m indicates that the only places it is
ever unset are in procedures (georect.tcl and mapcanvas.tcl) which
subsequently set it. Thus any command run from gis.m will read (and
possibly write) the saved region for the most recently used display,
not the WIND file.

Also, as the <FocusIn> handler for each canvas sets WIND_OVERRIDE, its
value can change at any time.

--
Glynn Clements <glynn@gclements.plus.com>

cmbarton · August 20, 2006, 4:28pm

OK. I see that this pretty much the way it should work. There should
probably be more transparency in the process and better explanation. Showing
some current region stats (rows, columns, resolution?) in the status bar
wouldn't hurt either. Also, need to see if there are inconsistencies to work
out still. Also, as you've suggested, we probably need to switch to setting
the region dynamically rather than use a saved region as the temporary wind
file.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 19 Aug 2006 10:01:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: 'GRASS user list' <grassuser@grass.itc.it>, Grass Developers List
<grass-dev@grass.itc.it>
Subject: [GRASS-user] Re: [GRASS-dev] Region setting correction

Michael Barton wrote:

BUT (and a very confusing one at that), g.region run from the command line
and g.region run from the menus do NOT always behave the same way with
regard to the interactive zooming in a display. I have no idea why this is
so. Maybe someone else can enlighten me.

The only plausible explanation is that WIND_OVERRIDE isn't always
being unset before g.region is run from gis.m, resulting in g.region
modifying something other than the WIND file.

In fact, AFAICT, WIND_OVERRIDE will always be set; searching for
WIND_OVERRIDE in gui/tcltk/gis.m indicates that the only places it is
ever unset are in procedures (georect.tcl and mapcanvas.tcl) which
subsequently set it. Thus any command run from gis.m will read (and
possibly write) the saved region for the most recently used display,
not the WIND file.

Also, as the <FocusIn> handler for each canvas sets WIND_OVERRIDE, its
value can change at any time.

--
Glynn Clements <glynn@gclements.plus.com>

Maciej_Sieczka2 · August 24, 2006, 11:07am

Michael Barton napisa?(a):

1. If you run g.region from the command line‹either with arguments (e.g.,
g.region p) or without arguments so that it starts one of the autogenerated
GUI dialogs‹it sets and/or reports on the values in the WIND file. This is
the way I described it a few minutes ago.

OK.

2. BUT, if you run g.region from the menu, there is anomalous behavior that
may be the cause of considerable and repeated confusion. G.region started
from the menus will REPORT (i.e., with p set) on the region of the
currently active display window (i.e., whichever display currently has the
focus). If you try to set something with g.region run from the menu, it
seems to have NO EFFECT on a display

Ouch!

OR on the WIND file.

OK.

3. However, if you set something from a g.region dialog run from the menu
AND select Œzoom to current region¹ from the menu button on the toolbar, the
display will match the g.region settings‹even though this is NOT in the WIND
file.

(dizzy)

4. If you set something from a g.region dialog started from the command line
(or issue a g.region command with arguments) and select Œzoom to current
region¹ from the menu button on the toolbar, it will have NO EFFECT on the
display zooming.

Yikes.

5. If you zoom interactively in a map display and select Œset current region
(WIND file) to match display¹, this WILL change the WIND file to match the
display (check by running g.region p from the command line).

OK.

At this point, it can insert some rounding error in resetting the WIND file to match the
display. I think this is what Maciek is seeing. I tried changing to a
g.region a (align to current region) and it had no effect on this rounding
error.

And when I inserted -a here and there to g.region calls in mapcanvas.tcl
it DID correct the rounding error. Only I'm not sure where exactly this
-a is really required! Please try once more.

The map display interactive zooming and zoom menu button are behaving as
they should.

1. Interactive zooming affects a dynamic region ONLY for that display and
DOES NOT affect the WIND file

OK.

2. Selecting Œzoom to current region¹ DOES change the display to match the
settings of g.region run from the menu‹but NOT from the command line.

(double dizzy)

3. Selecting Œset current region (WIND file)...¹ DOES change the WIND file
to match the display.

OK.

BUT (and a very confusing one at that), g.region run from the command line
and g.region run from the menus do NOT always behave the same way with
regard to the interactive zooming in a display. I have no idea why this is
so.

Oh no.

Maybe someone else can enlighten me.

These unresolved issues are extremely important. If they remain not
fixed for 6.2 it would be insane to force gis.m as a default GUI. People
will hate Grass and us.

Maciek