[GRASS-dev] g.mapset problems

[Glynn Clements]

Michael Barton wrote:

> I've gotten around this (hopefully without hidden issues) by creating
> procedures that use g.gisenv to change environmental settings for location
> and mapset, and then changing TclTk global environmental variables
> env(MAPSET) and env(LOCATION_NAME)--then changing them back.

Tcl/Tk code shouldn't be using environment variables for these, just
normal Tcl variables.

Using environment variables was a hack to make shell scripts work; we
got rid of that because it made switching mapsets impossible.

What matters to GRASS is the GRASS variables in $GISRC.

> It seems to be
> working pretty smoothly to get me in and back out of an xy location, though
> it's not as straightforward as using g.mapset.
> 
> Any reason you think I should switch back to trying to make g.mapset work?

g.mapset actually does locking so that you don't end up with two
sessions using the same mapset directory.

OTOH, if you're only reading the other location, then you shouldn't be
making it the active mapset, just changing the GRASS variables.

r.proj, r.in.gdal, i.points etc all modify the internal environment
using G__create_alt_env(); obviously, you can't do that for external
commands. I suggest creating a temporary $GISRC file for accessing the
X/Y location rather than modifying the "normal" $GISRC file.

If you aren't locking the X/Y mapset, you shouldn't be modifying its
WIND file; use the GRASS_REGION environment variable instead.

I wouldn't have thought that you would need to do much in the X/Y
location except dump out the map as an image, along with its bounds.

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