Short answer

Most of what geologists need in QGIS is already built in — Processing's raster-terrain algorithms, the Field Calculator, and GDAL cover slope, aspect, hydrology and attribute work without a single plugin. Plugins earn their place for the gaps: structural plotting (stereonets, rose diagrams), cross-sections and profiles, field-data sync (QField), and bulk import/QA helpers. The discipline that matters is not finding plugins but vetting them — checking maintenance, compatibility and source before they touch project data.

What to install versus what is already there

Before reaching for a plugin, know what ships natively. The Processing Toolbox includes Slope, Aspect, Hillshade, Ruggedness Index, Fill sinks, drainage and watershed tools, raster calculator, and the full GDAL/OTR/SAGA/GRASS algorithm providers (enable GRASS and SAGA in Settings ▸ Options ▸ Processing ▸ Providers). GRASS alone adds r.watershed, r.slope.aspect and hundreds of analyses. So the genuine plugin gaps for geology are narrower than people assume:

  • Structural orientation plotting — QGIS has no native stereonet.
  • Cross-sections / serial profiles beyond the single Elevation Profile panel.
  • Mobile field capture sync — QField and its companion.
  • Specialised import — borehole logs, LAS/lidar, well data, third-party survey formats.

Structural geology: stereonets and rose diagrams

For dip/dip-direction and lineation data, the two outputs geologists need are rose diagrams (azimuth frequency) and equal-area (Schmidt) stereonets (poles to planes, great circles, density contours).

Several plugins in the official repository generate rose diagrams and basic stereonets directly from a point layer's orientation fields. They are convenient for a quick look. For publication-grade plots, however, the most controllable route is the QGIS Python console with the mplstereonet library (built on matplotlib). You can read the active layer's dip and dip_dir columns, plot poles and planes, add Kamb or exponential density contouring, and export vector PDF — all reproducibly in a script you keep with the project:

import mplstereonet, matplotlib.pyplot as plt
from qgis.utils import iface
layer = iface.activeLayer()
strikes = [f['dip_dir'] - 90 for f in layer.getFeatures()]
dips    = [f['dip'] for f in layer.getFeatures()]
fig, ax = mplstereonet.subplots()
ax.pole(strikes, dips, 'k.')
ax.density_contourf(strikes, dips, measurement='poles')
plt.show()

This keeps the analysis auditable, which a one-click plugin export does not.

Terrain and cross-sections

QGIS 3.x ships an Elevation Profile panel (View ▸ Elevation Profile) that draws a topographic section along a digitised line from any DEM or 3D layer. For geology you usually want more: vertical exaggeration control, multiple DEMs, and projected boreholes or contacts on the section. Profile/cross-section plugins fill this, letting you build serial sections and annotate intersected units. Where a plugin is overkill, the native profile plus a Field-Calculator-derived distance-along-line attribute often suffices.

For hydrology and morphometry, prefer the native GRASS r.watershed / r.stream.* chain over abandoned plugins — it is maintained, scriptable, and produces flow accumulation, stream order and basin delineation in one provider.

Field data: QField and capture

If field crews collect structural readings or mapping on tablets, the QField ecosystem (QField for mobile plus the QFieldSync plugin on desktop) is the standard. QFieldSync packages a desktop project for offline use, handles the round-trip of edits, and respects your styles and forms. This is the one plugin combination that genuinely changes a geology workflow: digital strike-and-dip capture with attribute forms, synced back into the same GeoPackage you style and map from.

Vetting a plugin before you trust it

A plugin runs arbitrary Python with full access to your files and network. Treat installation as a supply-chain decision:

  1. Install only from the official repository (Plugins ▸ Manage and Install Plugins). Avoid loading random ZIPs unless you have read the code.
  2. Prefer stable over experimental. Experimental plugins are hidden by default; only show them (Settings tab) when you accept the risk.
  3. Check the last-updated date and the supported QGIS version. A plugin untouched for several major releases may break silently or rely on removed APIs.
  4. Read the repository. Most plugins link to a GitHub/GitLab page. Skim the issues and the code that touches the filesystem or network.
  5. Test on a copy. Run any bulk-editing plugin against a duplicate GeoPackage first; many bugs corrupt geometry or attributes in ways that are hard to undo.

Pin your working set: note the plugin names and versions in the project README so the environment can be reproduced. The standard processing and the Geometry Checker / Topology Checker (built-in core plugins) belong in every geology QA workflow and need only enabling.

Common pitfalls and why they happen

  • A plugin breaks after a QGIS upgrade. It used internal APIs that changed between releases. Pin a QGIS LTR (long-term release) for production and upgrade plugins deliberately, not automatically.
  • Stereonet plugin gives wrong poles. Strike-vs-dip-direction convention mismatch — the plugin expected strike (right-hand rule) but you supplied dip direction. Confirm the convention before trusting the plot; this is why a scripted mplstereonet workflow you control is safer.
  • Field edits don't sync back. QFieldSync was used to export but the project layers were not GeoPackage/offline-editing-capable, so edits stranded on the device. Package to GeoPackage first.
  • Slow project after installing many plugins. Each adds startup code and toolbar items. Disable what you are not using; fewer plugins also means fewer break on upgrade.
  • Plugin can't find the algorithm. A plugin that wraps GRASS/SAGA needs those providers enabled and their binaries installed. Check Processing ▸ Providers.

QA and validation

  • Run Topology Checker and Geometry Checker (core plugins) on geological linework before any analysis — overshoots, dangles and self-intersections wreck buffers and polygonisation.
  • Validate plugin output against a native method on a small sample: a plugin-computed slope should match gdaldem slope; a plugin rose diagram should match a manual azimuth histogram from the Field Calculator.
  • Record plugin name and version in project metadata so a reviewer can reproduce results.

Bathyl perspective

We keep the plugin footprint small and the provenance clear. For terrain and hydrology we lean on native Processing, GDAL and GRASS because they are maintained and scriptable; for structural plotting we prefer a mplstereonet script over a black-box button; and for field capture we standardise on QField into a GeoPackage. Every plugin we depend on is pinned by version in the project so the analysis can be rebuilt next year.

Related reading

Sources