[GRASS-dev] another not quiet GRASS command

[Michael Barton]

On 9/3/07 12:21 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>>>> In the above case of georect.tcl, we may ask 1) if switching between
>>>> mapsets in the script is really the best solution; 2) if that warning
>>>> should be a warning.
>>> 
>>> 3) If g.mapset is the right way to switch mapsets, or whether gis.m
>>> should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc".
>>> 
>>> If you're going to modify the existing $GISRC with g.mapset, the user
>>> had better not be running GRASS commands on the terminal in the
>>> meantime.
>> 
>> Because of the way GRASS works, it is necessary to switch between mapsets.
>> i.e., a display command will only work with the current environment and an
>> accessible mapset. Any operation that changes something (e.g., i.group) will
>> only work in the current mapset.
>> 
>> However, with more experimentation, it looks like g.mapset won't work as a
>> way to do this. I've had to revert to using g.gisenv
>> set=LOCATION_NAME=[xy_location].
> 
> I'm not questioning whether it's necessary to switch mapsets. I'm
> questioning whether modifying the existing $GISRC is the right
> approach, or whether gis.m should create a new $GISRC solely for use
> by the georectifier.
> 
> Personally, I'd suggest the latter.

OK. I see what you're getting at now. I'm not sure how to accomplish it.

The active GISRC is a tempfile ( /tmp/grass6-cmbarton-6824/gisrc on my
machine). 

Will simply creating a new temporary file with different values for
LOCATION_NAME and MAPSET have the effect of 'switching' to a different
working location/mapset? If so, how to get the current GRASS session to
recognize this? 

Does it even have to be a text file on disk somewhere or can it simply be
set to a variable (e.g., Python data object) with the appropriate values?

Can I just make a minimal GISRC with only location and mapset, or is it
safer to copy whatever is in the currently active one and then modify
location and mapset.

My active one currently contains...

DIGITIZER: none
GISDBASE: /Users/Shared/grassdata
GRASS_DB_ENCODING: utf-8
GRASS_ADDON_PATH: 
/Applications/Grass/GRASS-6.3.app/Contents/Resources/etc/gm/script
MONITOR: x0
LOCATION_NAME: xy
MAPSET: test
GRASS_RENDER_IMMEDIATE: TRUE
GRASS_GUI: wx


Michael


> 
> In general, global state (e.g. $GISRC, WIND) is undesirable. For
> command-line use, it's a necessary compromise, as having to manually
> specify database/location/mapset (and others, e.g. monitor and
> database) for each command would be a major nuisance.
> 
> A GUI doesn't have this problem; it can maintain its own state.
> Moreover, it can maintain as many different states as it wishes, and
> use the appropriate one for each individual command.
> 
> See also: past discussions of $WIND_OVERRIDE and $GRASS_REGION vs the
> WIND file.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton