On 9/3/07 12:21 PM, "Glynn Clements" <[EMAIL PROTECTED]> 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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
