GRASS Concurrence

Conn Copas C.V.Copas at lut.ac.uk
Tue Aug 4 16:48:49 EDT 1992


> Of  course,  the  grass4.0 command sets GISRC so if you wanted to
> have two sessions each using a different  GISRC  file  you  would
> need to write your own grass4.0 command and add code to set GISRC
> to a unique file name.  (One  consequence  is  that  grass  would
> "forget"  which  database  you were using from session to session
> unless you implemented a session save/recall database).
> 
> But this still isn't quite enough. Even if you managed  to  allow
> the same user to run GRASS with two distinct GISRC files, if both
> sessions chose the same database location and mapset, then  there
> would be trouble.  The region and mask are stored in files in the
> mapset and changing them  in  one  session  would  instantly  and
> automatically change them for the other session.
> 
> Michael Shapiro                        U.S. Army CERL                  
>
May I respectfully point out what seems to me to be a slight inconsistency
here? For each user-location, GRASS creates certain files which are designed
to preserve user viewing options from one session to the next. Some of these
options are map layer specific and others are not, eg, colour options refer to
individual layers, whereas resolution options apply to every layer (which is
sensible). Secondly, some of these options can be saved in user nominated files
(region, 3d viewing), whereas other options presume that current settings only
are saved at user exit (eg, colour, from memory). This is also the default for
region.

Concurrence makes the additional requirement that all of these options be
user process specific at run time. I don't see this as being particularly
demanding in a conceptual sense, although I am sure implementation would not
be trivial either. Secondly, at process exit, there would be the issue of what
to do with the currently active options, and the logical answer would be to
place this information in a file, for which precedents already exist. What I'm
trying to say (in a long winded fashion) is that it can't be that difficult, 
or am I missing something?
not conceptually challenging. The bigger issue is what to do at exit time, ie,


-- 
Loughborough University of Technology          tel : (0509)263171  ext 4164
Computer-Human Interaction Research Centre     fax : (0509)610815      
Leicestershire  LE11 3TU           e-mail - (Janet):C.V.Copas at uk.ac.lut   
G Britain                 (Internet):C.V.Copas%lut.ac.uk at nsfnet-relay.ac.uk




More information about the grass-dev mailing list