[GRASSLIST:7206] Re: Mapset Access
d.orme at imperial.ac.uk
Fri Jun 17 05:40:36 EDT 2005
On 17 Jun 2005, at 00:34, Hamish wrote:
>>> Can someone give me a quick overview of how mapset access control
>>> works in grass. I have a location with a number of mapsets, all of
>>> which I now need to share with coworkers but I can't seem to get it
>>> working. I've moved the mapsets onto our server machine (Apple G5
>>> running 10.4 and Grass 6.0 using Lorenzo Moretti's binary) and put
>>> them in /Users/Shared/Grass. I own the location:
>> I think the point is that you can only select a mapset as your
>> mapset if you own it. If other users need to access maps in that
>> mapset then they use the map at mapset notation.
> You must own the working mapset (so you can create new maps,
> *change the
> region*, apply your own color maps to other's raster maps, etc.). Once
> each user has their own working mapset, use g.mapsets to add the other
> mapset to the search path so you don't need to use the "@othermapset"
> notation all the time. That should be it.
OK - thanks. So you can't have a mapset which allows more than one
user to develop maps without having to change the ownership before
starting grass? I'm working with a group on a series of projects
within the same location and I've been using mapsets to separate maps
from the different research lines. Some of these lines are
collaborative so I was expecting there to be a way that a mapset
could be open to more than one user - that way all the maps relating
to that line of research are kept within a single mapset. From the
way Hamish and Paul describe it, anyone except the mapset owner would
have to do all development, regardless of the line of research,
within their own mapset(s), rather than adding/amending to the
existing body of work wiithin a single themed mapset.
I suppose one way would be to create a new shared 'developer' user
who owns all the research mapsets but grants group access. That way
any user can use grass, work within their own personal mapset and see
the full range of existing data. Logging in as grass_dev would then
allow anyone in the team to work on one of the core mapsets and
the .gislock would prevent multiple access to the same mapset.
Am I right in thinking that:
- the mapsets marked with a plus if you use 'mapset: list' on startup
are simply those which you own.
- g.access simply controls whether other users can see anything
within a mapset you own (and hence whether they can use
mymap at mymapset, or mymap following g.mapsets)
[Excuse the 'simplys' - was going crazy yesterday envisioning all
sorts of odd rules to misexplain the behaviour I was misinterpreting]
I'm not clear on how this works with sharing a grass database from a
server: when one of the group mounts the shared folder (via afp) then
the permissions of the mount are changed such that although he only
has access to one mapset when working directly on the server, all
mapsets are marked as accessible when mounted on a different machine.
However, the lock check for mapset/.gislock is not permitted so the
mapsets aren't actually accessible.
Forgive me if this all seems a bit clueless - I've been working
happily using grass as a single user in developing a database but now
I need to open the database up to multiple users to work on. I
haven't been able to find a document detailing how to administer a
multiple user grass environment - terse messages just containing a
link to documentation are as welcome as anything!
>> Have never really worked much with multiple mapsets so I don't have a
>> clear idea of the type of problems you can encounter but I don't
>> there is that much to it.
> I use them extensively (although mostly single user access). No
More information about the grass-user