# GRASS GIS: a C processing engine for raster, vector and time series work

> GRASS GIS is an OSGeo-hosted geoprocessing engine with a C core, a Python API and a temporal framework. It rewards scripted, large-scale analysis and punishes anyone who wants a point-and-click desktop tool.

**OSGeo/grass** — GRASS - free and open-source geospatial processing engine

- Repository: https://github.com/OSGeo/grass
- Website: https://grass.osgeo.org
- Stars: 1,173 · Forks: 447
- Language: C
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/osgeo-grass

## Who GRASS GIS is actually for

The README frames GRASS as both a desktop GIS and a geoprocessing engine reachable through command line, Python or R. Those are two different products with one codebase, and the second one is where the project earns its place. GRASS is for people who run the same analysis over many tiles, many dates or many model iterations, and who want the operation expressed as a command rather than a sequence of clicks. The topics list on the repository points the same way: earth observation, remote sensing, timeseries analysis, parallel computing, machine learning. That is a scientific computing audience, not a map-making audience. If you are producing one map for a report, GRASS is more machinery than the job needs. If you are producing the four hundredth map from the four hundredth input, the command-line model pays for itself almost immediately.

## Mapsets, regions and the LOCATION directory

GRASS organizes data around a LOCATION, which is a directory tied to a coordinate reference system, and inside it one or more mapsets. A mapset is the working unit: you open one, and the maps you create land in it. This is the design decision that confuses newcomers and the one that makes long analyses reproducible, because the data lives as files on disk in a known tree rather than inside a project file. The second concept is the computational region. Raster modules do not operate on the full extent of an input by default; they operate on the region you have set, and the region has a resolution. A module that resamples to a coarser region will happily produce a smaller answer than you expected. This is not a bug, it is a deliberate separation between what data exists and what area you are computing over, and it is the single most common source of wrong-looking output in GRASS. Read the region before you run anything that produces a raster.

## Installing GRASS GIS and running a first raster command

The README does not carry install steps. It points to the download page at grass.osgeo.org/download for platform packages, and to INSTALL.md plus the wiki page for compiling from source. The repository also ships a Dockerfile at the top level and a docker/ directory with its own README, so a container build is a documented path. The Dockerfile pins Ubuntu 24.04 as the base, Python 3.12, and specific versions of GEOS, PROJ, GDAL, PDAL and the GDAL-GRASS driver. That pinning matters: GRASS sits on top of the PROJ and GDAL stack, and version drift there is a real source of build failures.

If you build from source, the top-level Makefile is the entry point. Its default target writes a compilation log and then descends into the module directories.

```bash
make
```

The Makefile header states that INSTALL.md documents usage, so read that file before running the target. The DIRS list in the Makefile shows the module families that get built: raster, raster3d, vector, imagery, temporal, display, gui, visualization, ps, db, general, misc and scripts. That list is a fair map of what the engine covers.

Once GRASS is running, the shape of a session is: pick or create a LOCATION, pick a mapset, import data, set the region, then run modules. Module names are prefixed by family, so r.* is raster, v.* is vector, t.* is temporal, i.* is imagery. A first useful step is to read the current region before doing anything else. The g.region module is the one that reports and sets it, and the README's manual index is where its flags are documented. What you should see is the projection, the number of rows and columns, and the resolution. If the resolution is not what your analysis assumes, set it with g.region before running any module that writes a raster. This one habit prevents most of the surprises people report when results come out coarser than the input.

## Where GRASS GIS is the wrong tool

The GPL licensing of GRASS is not the constraint people usually hit. The constraint is the build and runtime surface. GRASS is a C engine that links against GDAL, PROJ, GEOS, PDAL, FFTW, GSL, Cairo and more, and the Dockerfile installs a long list of development packages to make that work. Embedding GRASS inside a closed product, or shipping it as a dependency of a small utility, means carrying that stack. There is a GDAL-GRASS driver pinned in the Dockerfile, which is the intended bridge for reading GRASS rasters and vectors from GDAL-based tools, and that is usually the cleaner integration point than linking the engine itself. The second limitation is conceptual rather than technical: the region and mapset model is not optional, and a user who treats GRASS like a file-based tool will get answers for the wrong extent. The third is that the README does not document rollback, downgrade paths or version pinning for the Python API, so if you depend on a specific release you should pin it in your own environment rather than assume the project guarantees compatibility across minor versions.

## GRASS GIS against QGIS and raw GDAL

QGIS is the obvious comparison and the difference is architectural. QGIS is a desktop application with a plugin ecosystem, and it can call GRASS modules through its processing framework. The relationship is not competitive: QGIS gives you the interface, GRASS gives you the engine, and many users run GRASS algorithms from inside QGIS without ever opening a GRASS shell. The trade-off is that going through QGIS adds a layer between you and the region settings, and when a result looks wrong it is harder to tell whether the problem is in your parameters or in how the host application configured the region. Running GRASS directly removes that ambiguity at the cost of the interface. The other comparison is GDAL alone. GDAL is a translation and I/O library; it reads and writes formats and offers some raster operations. GRASS is an analysis engine with a data model, a temporal framework and hundreds of modules. If your problem is format conversion, GDAL is the smaller answer. If your problem is hydrology, terrain analysis or time series over rasters, GDAL does not have the modules and GRASS does.

## Release cadence, licence and the cost of keeping up

The repository shows 8.5.0 released on 2026-05-08, an 8.5.0RC1 on 2026-04-17, and 8.4.2 on 2025-11-21. The last push to the default branch was on 2026-09-10, so the tree is moving. That cadence has a cost: the Python API and the module set evolve, and a script written against one minor release is not guaranteed to run unchanged against the next. The practical answer is to pin the GRASS version in whatever container or environment you deploy, which the Dockerfile's pinned base image and dependency versions already model. On licensing, the README states GRASS is available under the GNU General Public License and the Makefile headers carry SPDX-License-Identifier: GPL-2.0-or-later. The repository's GitHub licence field reads NOASSERTION, which reflects that the tree contains files under several compatible terms rather than one uniform declaration. If you plan to redistribute GRASS or link it into a product, read COPYING and GPL.TXT in the repository root and get your own legal review; nothing here is legal advice. The project is fiscally sponsored by NumFOCUS and hosted by OSGeo, and the README describes a custom governance model documented in GOVERNANCE.md.

## Conclusion

Adopt GRASS GIS if your work is scripted, repeatable and heavy on raster or temporal data, and you are willing to learn its region and mapset model before writing anything serious. Do not adopt it if you need a single self-contained binary that reads a shapefile from a dialog box, or if your team has no appetite for a C build toolchain. Before committing, verify three things yourself: that the region resolution you set matches the analysis you intend, that your data volume fits the mapset layout you plan, and that the version you install matches the release you are citing in your methods section.

## FAQ

### How do I install GRASS GIS?

The README does not list install steps itself; it points to the download page at grass.osgeo.org/download for platform packages and to INSTALL.md and the wiki for compiling from source. A Dockerfile and a docker/ directory are also present in the repository for container builds.

### Is GRASS GIS a desktop application or a command-line engine?

Both. The README says you can use GRASS as your desktop GIS or as a geoprocessing engine through command line, Python or R interface, and the Makefile builds a gui directory alongside the raster, vector and temporal module families.

### What licence does GRASS GIS use?

The README states GRASS is available under the GNU General Public License, and Makefile headers carry SPDX-License-Identifier: GPL-2.0-or-later. The repository's licence field reads NOASSERTION, so check COPYING and GPL.TXT for the full picture.

### Which Python version does GRASS GIS require?

The repository's pyproject.toml sets requires-python to >=3.11 and lists target versions py311 through py314 for formatting. The Dockerfile builds against Python 3.12.

## Sources

- [Issues](https://github.com/OSGeo/grass/issues)
- [OSGeo/grass on GitHub](https://github.com/OSGeo/grass)
- [Project website](https://grass.osgeo.org)
- [README](https://github.com/OSGeo/grass/blob/main/README.md)
- [Releases](https://github.com/OSGeo/grass/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/osgeo-grass