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. 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. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
