Hi Stefan
Not sure on your needs, but if not all projects run on GRASS, it might
be an option to run a spatial database as backend to store the data. At
ETH Zürich we have been running PostgreSQL to host our data. Access to
different software is running very well (GRASS, QGIS, R,..) and the
database works extremely stable.The advantage is that you can
access/alter the data with multiple users at the same time without
caring about consistency of the data. Furthermore you can set
permissions per user if needed.
However, to run GRASS with PostgreSQL you might need import of the data
(creation of vector topology) or you keep only your attributes in the
database.
Patrick
On 01.10.2015 21:00, grass-user-requ...@lists.osgeo.org wrote:
Message: 4
Date: Thu, 1 Oct 2015 10:19:01 +0000
From: "Blumentrath, Stefan"<stefan.blumentr...@nina.no>
To: "grass-user grass-user (grass-user@lists.osgeo.org)"
<grass-user@lists.osgeo.org>
Subject: [GRASS-user] Organizing locations and mapsets on NFS for
teams
Message-ID:<140852e86b4a4d3984c7108168891...@ninsrv23.nina.no>
Content-Type: text/plain; charset="us-ascii"
Hi,
I was wondering if someone knows some well-working solutions for collaborating on
locations and mapsets in teams ("best practice")?
Background: In my organization we have some 70 users working in different
projects (n~120) (not all use GRASS though), where new data is generated or
acquired which might be of wider interest throughout the organisation.
My aim is that data of common interest is shared in a common GRASS database on NFS. Yet
the problem is that things might get messy with all project-mapsets, user-mapsets and
"PERMANENT"-like mapsets in one location (in the light of the amount of
available GIS data, one PERMANENT mapset appears to be no longer sufficient I guess, esp.
when also space time datasets are hosted in the GRASS DB).
The solution described here:https://grasswiki.osgeo.org/wiki/Location_and_Mapsets with common
GRASS DB on NFS linked into users home directory is somewhat sexy in order to keep the "user
mapsets" out of the common GRASS GIS DB. The drawback however is, that users explicitly have
to switch between the two GRASS DBs if they want to share data on NFS, if I understood the
consequences correctly. Is someone aware of some nice "one-click- tools" which might be
used to sync between home and NFS GRASS DB. Would one need to write a wrapper script around
r./v.pack and r./v.unpack for such a job (if not entire (and tidy!) mapsets can be copied) to
simplify synchronization for basic users?
In addition, if users generate one mapset for every dataset they might be willing to share, this
may lead to way to many mapsets. Furthermore, such mapsets do not end up in the search path
automatically as data in PERMANENT would... I was considering to group data as far as possible
into INSPIRE themes / ISO topics (meaning one mapset per topic plus extra mapsets for time series
data). But then different users would need to be able to add data in those mapsets meaning modify
them (as it would be the case for PERMANENT cause there is not one person handling all data
anyway)... Does someone work with a "data janitor user" others may "su" to in
order to do general data maintenance?
How do you deal with mapsets for projects where different users collaborate? Do
you use project name as a prefix followed by user name or something like this,
so that mapsets for a project are grouped? Do you use project user accounts?
I am grateful for any recommendations or info on how others organize locations
and mapsets in a collaborative environment...
Cheers
Stefan
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
