[GRASS-dev] [bug #4368] (grass) g.parser: pass through --o

Glynn Clements glynn at gclements.plus.com
Wed May 10 19:07:40 EDT 2006


Radim Blazek wrote:

> > Actually, the "fixes" have also been rather ad-hoc. It might be better
> > to do away with WIND and store the name of a saved region in $GISRC
> > instead, remove MONITOR_OVERRIDE and WIND_OVERRIDE, and just create an
> > alternate $GISRC file whenever you want to change any of those
> > parameters.
> 
> Note that it is also possible to set region with GRASS_REGION
> environment variable.

I wasn't aware of that feature. That would be simpler for running
commands with a specific region from gis.m.

However, I don't think that the way it is currently implementated is a
good idea, as it overrides all saved regions as well as the current
region. I would suggest moving it to G_get_window(), so that programs
which use G__get_window() to read a specific named region aren't
affected.

I've recently fixed a small number of modules which gratuitously used
G__get_window(..., "WIND") to get the current region.

[Most of these did so in order to handle the case where the current
region was undefined, and use the default region instead. If that's
considered a good idea, it should be done in G_get_window() so that it
works for every module, not by a handful of specific modules.]

Modifying G_get_window() should now suffice for everything which
actually wants "the current region", except for g.region (which has a
legitimate need to specifically handle the case where the current
region is invalid). Everything else that still uses G__get_window()
does so because it wants a named region, or the default region, or the
current region for some other mapset.

For future development, I'm wondering if it would be a good idea to
replace the WIND file with a GRASS variable (e.g. REGION) using the
same syntax as GRASS_REGION.

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




More information about the grass-dev mailing list