[GRASS-user] grass-user Digest, Vol 114, Issue 1

[patrick s.]

Hi Stefan

I see the problem, but have no solution for the organization in GRASS.

Concerning PostgreSQL- our data are in different schemas, to allow for 
access of all within our SQL-code. Example: One schema for initial data 
and others for processed data or different Versions. Views are used to 
represent different levels of aggregation and recognized by GRASS as 
normal PG-Layers. Different topics could be placed in different 
databases, but these will require dumping and restoring of data, if they 
have to be combined or processed commonly- which was the reason we 
avoided them. Latest PostGIS-extension has support for raster, which I 
heard to be pretty well. Only tested loading of GeoTiffs- which was easy.

Hope that helps and happy to hear on your final solution. Have a similar 
issue here.

patrick


On 05.10.2015 10:07, Blumentrath, Stefan wrote:
> Hi Patrick,
>
> Thanks for your reply!
> Yes, PostgreSQL/PostGIS is a nice addition to the GRASS GIS DB (where we currently run SQLite as backend).
> PostgreSQL however, is much less usable for (esp. heavy) raster data: terrain models and so on.
>
> In addition, the same organizational question arises within PostgreSQL where one only has one level of hierarchy for grouping the data within a database (namely schema). I am tempted to ask how you organize your data/schema within PostgreSQL (esp. name schema), but that is probably a question for another Mailing list...
> The main difference between PostgreSQL and GRASS in terms of data organisation is that in PostgreSQL any user can be granted the right to modify content of a schema, while in GRASS only the owners should (or can safely) modify a mapset - if I am not mistaken...
>   
> My main concern is: how do I prevent my (and my colleague`s) data to end up in a mess when several colleagues co-work on the same GRASS DB / the same LOCATION. As far as I can see there are three things one has to find a solution to:
> 1) Mapset naming conventions
> 2) sharing of data in team- or PERMANENT-like mapsets, and therewith access rights and maintenance of "PERMANENT-like" mapsets in a collaborative way
> 3) Archiving of mapsets (expired projects and up- / out-dated entities from data series)
>
> Cheers
> Stefan
>
> -----Original Message-----
> From: patrick s. [mailto:patrick_gis at gmx.net]
> Sent: 5. oktober 2015 09:21
> To: grass-user at lists.osgeo.org; Blumentrath, Stefan <Stefan.Blumentrath at nina.no>
> Subject: Re: grass-user Digest, Vol 114, Issue 1
>
> 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-request at lists.osgeo.org wrote:
>> Message: 4
>> Date: Thu, 1 Oct 2015 10:19:01 +0000
>> From: "Blumentrath, Stefan"<Stefan.Blumentrath at nina.no>
>> To: "grass-user grass-user (grass-user at lists.osgeo.org)"
>> 	<grass-user at lists.osgeo.org>
>> Subject: [GRASS-user] Organizing locations and mapsets on NFS for
>> 	teams
>> Message-ID:<140852e86b4a4d3984c71081688919b0 at 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