[GRASS-dev] g.mapset problems

GRASS GIS GRASS GIS developer
1

I’m trying to use g.mapset in a TclTk script and am having problems. I hope that someone can help with this.

First, when I run it, it sends out text output stderror that seems to lock it up if I try to redirect to /dev/null
Second, if I try to run it to switch to a new location/mapset, and it doesn’t work, the next time I try to switch the same location/mapset, I get the error…

“cmbarton is currently running GRASS in selected mapset or lock file cannot be checked.”

…even if I am not working in that mapset. Does anyone know what is going on?

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¹m trying to use g.mapset in a TclTk script and am having problems. I hope
that someone can help with this.

First, when I run it, it sends out text output stderror that seems to lock
it up if I try to redirect to /dev/null

No idea as to the cause, but if you add "2>&1" to the command, stderr
will be redirected to stdout. That will prevent Tcl from treating it
as an error.

Second, if I try to run it to switch to a new location/mapset, and it
doesn¹t work, the next time I try to switch the same location/mapset, I get
the error...

³cmbarton is currently running GRASS in selected mapset or lock file cannot
be checked.²

...even if I am not working in that mapset. Does anyone know what is going
on?

It's possible that $GISBASE/etc/lock creates the .gislock file but
returns a non-zero exit status, resulting in g.mapset not updating
$GISRC. If that happens, the new mapset will be locked but won't be
made the current mapset. Further attempts to switch to it will fail
due to the lock.

Also, I note that the lock handing in etc/Init.sh assumes that the
current mapset doesn't change throughout a session. I.e. when you exit
GRASS, it deletes the .gislock file which was created at startup, not
the one for the current mapset at termination time.

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

3

Thanks Glynn.

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. 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?

So I'm about 75% (I think) along the way to creating a pure TclTk
georectifying system.

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: Wed, 31 May 2006 17:43:21 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: GRASS developers list <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] g.mapset problems

Michael Barton wrote:

I¹m trying to use g.mapset in a TclTk script and am having problems. I hope
that someone can help with this.

First, when I run it, it sends out text output stderror that seems to lock
it up if I try to redirect to /dev/null

No idea as to the cause, but if you add "2>&1" to the command, stderr
will be redirected to stdout. That will prevent Tcl from treating it
as an error.

Second, if I try to run it to switch to a new location/mapset, and it
doesn¹t work, the next time I try to switch the same location/mapset, I get
the error...

³cmbarton is currently running GRASS in selected mapset or lock file cannot
be checked.²

...even if I am not working in that mapset. Does anyone know what is going
on?

It's possible that $GISBASE/etc/lock creates the .gislock file but
returns a non-zero exit status, resulting in g.mapset not updating
$GISRC. If that happens, the new mapset will be locked but won't be
made the current mapset. Further attempts to switch to it will fail
due to the lock.

Also, I note that the lock handing in etc/Init.sh assumes that the
current mapset doesn't change throughout a session. I.e. when you exit
GRASS, it deletes the .gislock file which was created at startup, not
the one for the current mapset at termination time.

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

4

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@gclements.plus.com>