Meeting minutes on interfacing GRASS GIS from QGIS

2024-06-17
Conversation as part of the GRASS Community Meeting in Prague 2024
Participated: Nyall Dawson (online), Markus Neteler, Vaclav Petras, Anna Petrasova, Floris Vanderhaeghe, Veronica Andreo, Martin Landa

Changes since last discussion

• Descriptions of GRASS tools in provider are currently in txt files. To speed up loading QGIS, QGIS creates a single JSON file during compilation. This file could become the primary file, the txt files would be dropped in that case.
• References as 'GRASS 7' have been updated to 'GRASS'. However quite a few 'GRASS 7' references still appear in the processing provider. Markus and Nyall will fix this.

Plugins' metadata

Nyall modified the description to better communicate that the C++ GRASS plugin is deprecated.
It is not removed yet, because certain features are not yet available in the GRASS processing provider, e.g., writing/reading data from GRASS mapsets within processing plugin, see Nyall's short-term goals from last year's discussion.
The changes summarized and merged in: https://github.com/qgis/QGIS/pull/57782

Issues in GRASS Data provider

Raster color management

In past versions of QGIS, GRASS raster maps didn't show up at all when displayed from the GRASS data provider. This seems to be resolved now. In any case, we'll test it further with different types of raster maps and the newest QGIS.

Some old related issues (not sure how relevant they are?):
https://github.com/qgis/QGIS/issues/13187
https://github.com/qgis/QGIS/issues/11111

Multiple vector layers

Vector map census from GRASS sample dataset was showing up with 2 layers in the GRASS data provider, although it only has 1 layer. Layer 0 was isles (holes), layer 1 was the correct one. This has been fixed during the call and is merged now:
https://github.com/qgis/QGIS/pull/57780

Addons in QGIS:

Nyall's recommendation is to expose all well-maintained, community-accepted GRASS addons as one extra processing provider (i.e. GRASS addons) distributed via the normal QGIS plugin channels (i.e. not built into QGIS). It would be based off the existing processing grass provider (which is built-in).

Another option is to provide individual addons as separate QGIS plugins (1 addon per plugin) that use the same base. If at some stage such addon breaks because it's less maintained, this will not affect other addons due to its isolation in a separate plugin.This would work well for addons that are shared outside of GRASS addons repository.

https://lists.osgeo.org/pipermail/qgis-developer/2019-February/056155.html

Threading

Currently, GRASS calls block the QGIS GUI since grass --exec g.something always locks the mapset. There is no reason for that, since Processing calls GRASS with grass --tmp-location.
Nyall plans to remove the restrictions, but he needs to implement a locking mechanism. Vashek discussed possible usage of the GRASS locking mechanism, with possibly adding a tool that would inform QGIS lock is gone.