[GRASSLIST:7206] Re: Mapset Access

[David Orme]

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  
>> working
>>
>> 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!

Thanks

David




>
>> 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  
>> think
>> there is that much to it.
>>
>
> I use them extensively (although mostly single user access). No  
> problems.
>
>
>
> Hamish
>