Are there any advantages to the use of GRASS Tools (Creating a new mapset and using GRASS modules) instead of using GRASS algorithms available in the processing toolbar with QGIS Data?

I think there might be a speed advantage because that way the layers are already in GRASS format and can be directly treated. I'd like to know if my guess is right. Did somebody compare?

I think there might also be more options (flags) when using GRASS tools instead of GRASS algorithms in the Processing Toolbox. Are there?

I also think that there might be more algorithms available or more up to date algorithms in GRASS tools than in the Processing Toolbox. Are there?

1 Answer 1


I've experienced the following:

First, there are certain structuring choices Grass makes that are different than QGIS does. You may conceptually prefer these choices, and pragmatically if you plan to use Grass functionality extensively in your workflow for a given task, your life will be easier if you use Grass tools and modules and therefore make the necessary translations only once, and you will save time since the Grass-QGIS interface is not doing rework everytime you invoke a Grass algorithm to set it up ad-hoc.

I'm sure others will add more, but the two biggest choices of this type I've experienced are:

  1. Raster analysis is/can be done in regions. See https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#id25.

  2. Grass works with topological areas (boundaries + centroids) rather than (nontopological) polygons. See https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#the-grass-vector-data-model. If your data is naturally topological (e.g. you are tiling your ROI, no intersections), you will save processing time and headache by working natively in a Grass mapset versus having your vector layers go through v.in.ogr (and implicitly I believe v.clean) every time you invoke a Grass processing algorithm.

Second, there are a few bugbears about QGIS-Grass interaction which seem to pop up far too often even if they are small, and require workarounds you will find annoying if you are repeatedly invoking Grass processing algorithms within QGIS.

  1. Custom CRS specifications. Maybe this has now been fixed, but with the passage to proj6 in QGIS 3.10.x in particular, working in a custom (non-EPSG) CRS with Grass processing algorithms was painful, with result layers having to have their CRS reset in QGIS in particular. I believe a Grass Mapset sets one CRS, so whatever you're doing with CRS, you only do it once if you go that route!

  2. Raster nodata values and mask parameters can take tweaking to pass to to raster algorithms invoked by QGIS, e.g. r.neighbors. If you do this often, it's easier to work within Grass and be clear what nodata is once and for all.

Finally, there is an important (potential) disadvantage - to use Grass tools you have to set up a mapset and adapt to Grass' mapset/location file model, and single CRS (versus reproject on the fly). You're clearly aware of this, but for the benefit of others reading this, see https://docs.qgis.org/testing/en/docs/user_manual/grass_integration/grass_integration.html#grass-location-and-mapset

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.