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

[Michael Barton]

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 at gclements.plus.com>
> Date: Thu, 24 Aug 2006 22:12:33 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: grass-dev <grass-dev at grass.itc.it>, grass list <grassuser at 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 at gclements.plus.com>