Requested clarification in section 9.4: rgrass7

[florisvdh]

(General note: this is the last one! Sorry for the long-time accumulated, and at-once-submitted issues!)

I think the statement:

The GRASS spatial database system is based on SQLite. Consequently, different users can [...]

is either not correct, or is at least misleading. From the current text, it appears as if everything is organized within an SQLite database file, which sits in a specified folder.

The GRASS documentation reads:

A GRASS GIS Database is simply a set of directories and files with certain structure which GRASS GIS works efficiently with. Location is a directory with data related to one geographic location or a project. All data within one Location has the same cartographic projection. A Location contains Mapsets and each Mapset contains data related to a specific task, user or a smaller project.

All data for GRASS GIS must be in GRASS GIS Database which is a directory (visible on the disk) containing subdirectories which are GRASS Locations. User can have one or more of Databases on the disk. Typically users have one directory called grassdata in their home directory. In multi-user environment users often have a grassdata directory mounted as a network directory (network file system). For teams, a centralized GRASS DATABASE would be defined in a shared network file system (e.g. NFS). GRASS GIS Databases can be safely copied or moved as any other directories. Don't be confused with (relational) databases which are used in GRASS GIS to hold attribute data and might be part of the GRASS GIS Database. From user point of view, GRASS GIS Database with all its data in it is similar to, e.g. PostGIS, database, as it stores all information inside in a specific format and is accessible by specific tools. GRASS GIS Databases is in GRASS GIS often called GISDBASE or DATABASE.

I think it should be made clear to the reader that 'the GRASS spatial database system' itself is a strict folder hierarchy in a local or network filesystem, represented by the folder grassdata.

[Robinlovelace]

Thanks for the comment @florisvdh. I think @jannes-m wrote that so we'll await feedback. Lots of comments, this is the first I've read. Hope the others are as well-informed as this one. If so they are very welcome: they will make the book stronger.

[jannes-m]

I think I've read that the GRASS database is built/based on SQLite, most likely in https://www.springer.com/de/book/9780387357676. I don't have the book right now but will look it up on Monday. But @neteler, could you please clarify if you have a moment?

[neteler]

Sorry for the confusion.

Attributes Yes, the default database driver used by GRASS GIS 7 is SQLite. Explanations now added to the manual: https://github.com/OSGeo/grass/pull/33

(as soon as being accepted, it will show up at https://grass.osgeo.org/grass77/manuals/vectorintro.html )

Geometry Geometry is stored by default in the specific, optimized GRASS GIS vector format. See https://grass.osgeo.org/grass77/manuals/vectorintro.html#vector-model-and-topology and https://grasswiki.osgeo.org/wiki/Vector_Database_Management#GRASS_GIS_vector_management_model

[Robinlovelace]

Many thanks Markus!

[florisvdh]

Thanks a lot for shedding more light! As I see it now, I think from the book text there is potential confusion between:

1. the format in which a layer is by default stored in GRASS, i.e. using an SQLite database as I understand it.
2. the GRASS GIS Database, which is the folder grassdata (strict folder hierarchy in a local or network filesystem)

I think the text at least means the second point (but that's not mentioned), perhaps also the first. For me it needs clarification in the text. It is this part:

Now that we have the data, we can go on and initiate a GRASS session, i.e., we have to create a GRASS spatial database. The GRASS spatial database system is based on SQLite. Consequently, different users can easily work on the same project, possibly with different read/write permissions. However, one has to set up this spatial database (also from within R), and users used to a GIS GUI popping up by one click might find this process a bit intimidating in the beginning.

For example, in Consequently, different users can easily work on the same ..., don't you rather mean the consequence of the data folder being in a shared network folder?

[jannes-m]

No, I don't mean that. I was referring to the transaction mechanism of databases which allow multiple users to work on the same file (somewhat similar to git). To clarify I will rewrite.

[neteler]

If you discuss GRASS GIS and SQLite here: each mapsets contains a file sqlite/sqlite.db. Each location can be used by multiple users at the same time (esp. if stored in a network drive) while a mapset can only be edited by the respective owner (think ACL).

The situation is partially different when using PostGIS as the database management backend for attributes.

Or when using this (prototype) GRASS GIS-PostGIS integration, see https://grasswiki.osgeo.org/wiki/PostGIS

[Robinlovelace]

@jannes-m is this issue sorted now?

[jannes-m]

Finally, I have addressed this issue, and rewritten as follows:

GRASS stores the input data in a GRASS GIS database. With regard to vector data, GRASS GIS is by default a topological GIS, i.e., it only stores the geometry of adjacent features once. SQLite is the default database driver for vector attribute management, and attributes are linked to the geometry, i.e., to the GRASS GIS database, via keys (GRASS GIS vector management).

@florisvdh, indeed, my usage of GRASS GIS database and SQlite was confusing, if not, incorrect, Thanks for pointing out. And @neteler thanks for updating the GRASS documentation and clarifying multi-user editing.

[Nowosad]

👍🏻