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

[Radim Blazek]

On 5/12/06, Glynn Clements <glynn at gclements.plus.com> wrote:
> > Of course, I moved it to G_get_window(). But then g.region -p
> > prints WIND file, not GRASS_REGION variable, I am not sure
> > what it should. Probably it should print GRASS_REGION?
>
> I would say so.
>
> g.region doesn't use G_get_window() to get the current region, but
> uses:
>
>         if (G__get_window (&window, "", "WIND", G_mapset()) != NULL)
>         {
>                 G_get_default_window (&window);
>                 G_put_window (&window);
>         }
>
> The logic here is that if the WIND file is invalid, the only way to
> set it is to run g.region, so so g.region can't just just call
> G_get_window() (which will generate a fatal error if the WIND file is
> invalid).
>
> Note that it does this before calling G_parser(), so that it can use
> window.proj in the option definitions.
>
> After G_parser() returns, it replaces the region with the default
> region if the -d flag is used, or with the named region if region= is
> used. Otherwise, the previously-obtained region is retained and
> modified according to the other options.
>
> There are a few possible solutions.
>
> One is to obtain the initial region using G_get_default_window().
> After G_parser() returns, if the -d flag isn't given, it would use
> G_get_window() to replace this with the current region. That would
> allow the use of "g.region -d" to fix a missing/invalid WIND file,
> while causing GRASS_REGION and WIND_OVERRIDE to work normally.
>
> The other is to explicitly test for GRASS_REGION and/or WIND_OVERRIDE
> in g.region.

In theory the module should know nothing about GRASS_REGION.
I would prefer the first possibility.
In any case I am not going to work on g.region.

> > > 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.
> >
> > Do you mean GRASS mapset variable (in VAR)?
>
> Well, I meant that G_get_window() would become use G_getenv("REGION")
> rather than G__get_window(..., "WIND"). It wouldn't really matter if
> it was a mapset or GISRC variable; the main point was not to store
> state in a form which can only have a single instance. Actually, the
> same issue applies to the VAR file; what uses that? Just QGIS?

Standard GRASS variables (GISRC) are stored in  ~/.grassrc6
and reloaded when a new mapset is opened. It does not make sense
to store a region of one mapset and reload it in another one (which can be
even in a different projection).

In VAR file are stored variables specific for the mapset. For example
connection to database. It is not used by QGIS at all.

> If all "session state" goes into $GISRC, you can just create a new
> $GISRC file for each operation, without worrying about conflicts
> (providing that the operations only read the data; supporting
> concurrent modification is a long way off).

Yes, I like the idea, but we have to store the state of the last
session for mapset somewhere. And the session state which includes
WIND is mapset specific.

> > I am using WIND as test for mapset in QGIS, exists another way
> > to test if a directory in location is a mapset?
>
> You could test whether ../PERMANENT/DEFAULT_WIND exists. Or even just
> whether ../PERMANENT exists.

I use that as location test, but location can contain directories
which are not mapsets.

Radim

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