[GRASS-dev] updates to region setting and display rendering in GIS Manager

GRASS GIS GRASS GIS developer
1

I just committed a set of updates to the cvs that should enhance region
management and display rendering times in the GIS Manager.

The display no longer uses d.mon and the PNG driver to create graphic output
to render to the TclTk canvas (i.e., map display). Instead, it uses the new
GRASS_RENDER_IMMEDIATE mode that is one of the new results of Glynn
Clement's revamping of the underlying GRASS display code. One informal test
suggested that this might as much as half rendering times, but I can't
confirm this. However, it does simplify display management and should reduce
potential conflicts with older display tools using d.mon and x11 displays.

Region setting also now uses one of Glynn's new tools, the GRASS_REGION
setting. What this means is that GRASS's complicated, but useful, region
geometry management should be a little easier and a lot more consistent from
the GIS Manager. Specifically:

-Each display maintains its own geometry/region settings, which do not
affect
anything else.

-Changing the zoom (region settings) in a display will have no automatic
effects on the computational region/geometry for any GRASS command run from
the menu or command line.

-Setting the region with g.region will affect the computational
region/geometry of any GRASS command run from the menu or command line in
the same way, no matter how g.region is started. It will have no automatic
effects on any display.

-Except for the display in the TclTk canvases of the GIS Manager, all GRASS
commands will use the same region information, whether started from the
command line or menu.

-You can explicitly set the region for non-display commands to match the
display region, but only if you choose to do so.

-You can explicitly set the display to match the WIND region set with
g.region, but only if you choose to do so.

I've also added a display of some region information at the bottom of each
display to help users know what they're looking at.

Hopefully, this will make the whole geometry setting process easier and more
consistent across all the program.

I also added both the new display rendering and region management to the
georectifier.

Finally, I was able to fix a nasty bug that locked up gism if there was a
bad raster name in the layer tree. Now it will report the problem in the
grass console, but otherwise ignore it.

Please test these updates. If they hold up, they should be backported to 6.2

Thanks to those who have done previous testing and helped me sort out these
issues.

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

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

2

Michael Barton wrote:

I just committed a set of updates to the cvs that should enhance region
management and display rendering times in the GIS Manager.

-Setting the region with g.region will affect the computational
region/geometry of any GRASS command run from the menu or command line in
the same way, no matter how g.region is started. It will have no automatic
effects on any display.

-Except for the display in the TclTk canvases of the GIS Manager, all GRASS
commands will use the same region information, whether started from the
command line or menu.

I'm still not sure whether this is a good thing. Apart from anything
else, it means that you need to be careful about running background
jobs from the shell, as any region changes within the GUI will affect
them.

This isn't a problem for monolithic C programs, which read the WIND
(etc) file once at startup, but it could be a problem for scripts or C
programs which run other GRASS modules via system/popen. Each child
will read the WIND file itself, potentially getting settings which
differ from the parent. I'm wondering if G_get_window() should export
the setting to GRASS_REGION so that any children automatically get the
same region.

My inclination would have been to make this an option: allow gis.m's
computational region to either mirror the shell's version (i.e. leave
WIND_OVERRIDE unset so that the WIND file is used) or to be separate
(set WIND_OVERRIDE to a private saved region). For the latter case,
you would have specific commands to import/export the gis.m region
from/to the WIND file.

If gis.m uses GRASS_REGION as the sole method for forcing specific
regions, then manually setting WIND_OVERRIDE to the name of a saved
region before starting gis.m will solve this. However, if gis.m uses
WIND_OVERRIDE for any reason, it should set it back to the value which
it had at startup rather than "unset"ting it.

OTOH, whatever gis.m does, the user can always force the shell to use
a separate region by setting WIND_OVERRIDE manually.

One final point: using WIND_OVERRIDE (instead of GRASS_REGION) for the
display regions (i.e. giving each display its own saved region) would
have the advantage that the user can directly access those regions
from the shell, either using WIND_OVERRIDE= or "g.region region=".

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

3

Glynn,

I guess I didn't explain this as well as I thought (or maybe I did and don't
quite understand your comments).

The only thing in gism that uses GRASS_REGION is interactive panning and
zooming in the display. The only time this is invoked is just before
rendering the display images to PPM files. It is then immediately unset.

WIND_OVERRIDE is unset all the time.

So all commands (including g.region) called from the menus behave exactly
the same as if they were called from the command line with respect to region
geometry. Hopefully, this makes gism behavior consistent with the rest of
GRASS behavior as far as regions go.

Your point about being able to access a file of region info for the display
is dealt with in 2 ways. With the new zoom menu item, you can save the
display geometry to a named region in the windows folder (and access it from
other displays or from g.region). You can also set the WIND file from the
display with another selection from the zoom menu. In both cases, however,
you must do this intentionally. It is not done for you unexpectedly.

I hope this explains it better.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Thu, 24 Aug 2006 22:12:33 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: grass-dev <grass-dev@grass.itc.it>, grass list <grassuser@grass.itc.it>
Subject: Re: [GRASS-dev] updates to region setting and display rendering in
GIS Manager

Michael Barton wrote:

I just committed a set of updates to the cvs that should enhance region
management and display rendering times in the GIS Manager.

-Setting the region with g.region will affect the computational
region/geometry of any GRASS command run from the menu or command line in
the same way, no matter how g.region is started. It will have no automatic
effects on any display.

-Except for the display in the TclTk canvases of the GIS Manager, all GRASS
commands will use the same region information, whether started from the
command line or menu.

I'm still not sure whether this is a good thing. Apart from anything
else, it means that you need to be careful about running background
jobs from the shell, as any region changes within the GUI will affect
them.

This isn't a problem for monolithic C programs, which read the WIND
(etc) file once at startup, but it could be a problem for scripts or C
programs which run other GRASS modules via system/popen. Each child
will read the WIND file itself, potentially getting settings which
differ from the parent. I'm wondering if G_get_window() should export
the setting to GRASS_REGION so that any children automatically get the
same region.

My inclination would have been to make this an option: allow gis.m's
computational region to either mirror the shell's version (i.e. leave
WIND_OVERRIDE unset so that the WIND file is used) or to be separate
(set WIND_OVERRIDE to a private saved region). For the latter case,
you would have specific commands to import/export the gis.m region
from/to the WIND file.

If gis.m uses GRASS_REGION as the sole method for forcing specific
regions, then manually setting WIND_OVERRIDE to the name of a saved
region before starting gis.m will solve this. However, if gis.m uses
WIND_OVERRIDE for any reason, it should set it back to the value which
it had at startup rather than "unset"ting it.

OTOH, whatever gis.m does, the user can always force the shell to use
a separate region by setting WIND_OVERRIDE manually.

One final point: using WIND_OVERRIDE (instead of GRASS_REGION) for the
display regions (i.e. giving each display its own saved region) would
have the advantage that the user can directly access those regions
from the shell, either using WIND_OVERRIDE= or "g.region region=".

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

4

Michael Barton wrote:

I guess I didn't explain this as well as I thought (or maybe I did and don't
quite understand your comments).

The latter.

The only thing in gism that uses GRASS_REGION is interactive panning and
zooming in the display. The only time this is invoked is just before
rendering the display images to PPM files. It is then immediately unset.

WIND_OVERRIDE is unset all the time.

So all commands (including g.region) called from the menus behave exactly
the same as if they were called from the command line with respect to region
geometry. Hopefully, this makes gism behavior consistent with the rest of
GRASS behavior as far as regions go.

Your point about being able to access a file of region info for the display
is dealt with in 2 ways. With the new zoom menu item, you can save the
display geometry to a named region in the windows folder (and access it from
other displays or from g.region). You can also set the WIND file from the
display with another selection from the zoom menu. In both cases, however,
you must do this intentionally. It is not done for you unexpectedly.

I hope this explains it better.

The above is essentially how I assumed it works from your previous
email, although it does clarify some of that.

My comments were primiarily pointing out some of the pros and cons of
different approproaches, and to suggest possible enhancements.

If gis.m never sets or unsets WIND_OVERRIDE, the user can choose to
isolate gis.m from the WIND file with:

  g.region save=gism
  WIND_OVERRIDE=gism gis.m &

The user can then manually synchronise the two by running:

  g.region region=gism # gis.m region -> shell region
or:
  g.region save=gism # shell region -> gis.m region

and can enable/disable synchronised operation with:

  export WIND_OVERRIDE=gism # enable synchronisation
and:
  export -n WIND_OVERRIDE # disable synchronisation

[By "gis.m region", I mean the region which will be used by any
command for which gis.m doesn't set GRASS_REGION, i.e. non-display
commands.]

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