Short answer

There is no single "mining GIS." A working stack pairs a desktop GIS (QGIS or ArcGIS Pro) for mapping, editing, and styling; GDAL/OGR for repeatable batch processing in scripts; PostGIS as the shared system of record once more than one person touches the data; and specialist mine-modelling software (Leapfrog Geo, Micromine, Datamine, Surpac) for drillhole desurveying, block models, and orebody wireframes. Web delivery sits on vector tiles, GeoServer, or a Mapbox/MapLibre layer. The right combination depends less on brand and more on where you are in the project lifecycle.

The mistake is choosing tools by license preference. Choose by the workflow: who edits, how often processing repeats, how much data, and what must be auditable years later.

Map the stack to the lifecycle

A mining project is not one job; it is four phases with different data centres of gravity.

Exploration and targeting

The data is regional and varied: satellite and airborne imagery, geophysics grids, stream-sediment and soil geochemistry, regional geology, tenement boundaries. The work is interpretive and changes fast.

  • QGIS is the natural home — free across a growing team, strong raster styling, and the Semi-Automatic Classification Plugin plus Google Earth Engine integration for imagery.
  • GDAL reprojects and mosaics imagery and reprojects DEMs to a local metric CRS before terrain analysis (critical — slope and lineament work are wrong in geographic coordinates).
  • Geochemistry sits in interpolation tools (IDW, kriging via the SAGA/QGIS processing providers) and is symbolised against geology.

Resource definition

Now the centre is the drillhole database: collar, downhole survey, and interval (lithology, assay, geotechnical) tables.

  • These tables belong in PostGIS or a managed drillhole database, not loose CSVs, so validation rules (no overlapping intervals, valid hole IDs) can be enforced.
  • Desurveying and 3D modelling move into specialist software — Leapfrog Geo, Micromine, Datamine, Surpac — which apply minimum-curvature desurvey and build block models and wireframes. GIS provides spatial context (terrain, infrastructure, constraints) and exchanges tables with these tools.
  • QGIS with the Geoscience plugin or qProf handles sections and downhole visualisation when full mine-modelling software is overkill.

Operations

Many editors, daily updates, survey pickups, and reporting.

  • PostGIS is now mandatory: spatial indexing (GiST), concurrent multi-user access, SQL analysis, and a single source of truth. Desktop files cannot safely support a team editing the same data.
  • ArcGIS Pro / Enterprise earns its place here for organisations already invested in it — geodatabase versioning, field apps (Field Maps), and dashboards. The trade-off is licensing cost and lock-in.
  • Automated pipelines (GDAL + Python, or FME if budget allows) keep terrain models, haul-road grades, and pit-progress layers current.

Closure and monitoring

Long-lived, audit-focused: environmental monitoring, rehabilitation tracking, water and dust layers, and archives a regulator may inspect a decade later.

  • Emphasis shifts to standardised, indexed, well-documented storage (GeoPackage for portable deliverables, PostGIS for the live database) and reproducible processing so results can be defended.

The core tools, and what each is actually for

  • QGIS — desktop mapping, editing, styling, ad-hoc analysis. Free, extensible, excellent raster handling. The default analyst workbench.
  • ArcGIS Pro / Enterprise — desktop plus an enterprise ecosystem (geodatabase, versioning, field apps, dashboards). Strong where the organisation is already Esri-based and needs managed, supported infrastructure.
  • GDAL/OGR — the engine under almost everything. Command-line gdalwarp, gdaldem, gdal_merge, ogr2ogr for reproject, mosaic, terrain derivatives, clip, and format conversion. Script it for anything that repeats.
  • PostGIS — spatial database on PostgreSQL. Spatial indexing, SQL analysis (ST_Intersects, ST_Transform, ST_DWithin), multi-user editing, the system of record.
  • Mine-modelling software (Leapfrog, Micromine, Datamine, Surpac) — drillhole desurvey, implicit and explicit 3D geological modelling, block models, resource estimation. GIS does not replace these.
  • Web delivery (GeoServer, vector tiles, MapLibre/Mapbox, Leaflet) — for dashboards and stakeholder portals once data must reach browsers.

A concrete pipeline example

A reprojection-and-terrain step that recurs every time new survey data lands, scripted with GDAL so it is identical each run:

# Reproject a new DEM tile to the project UTM zone, then derive slope
gdalwarp -t_srs EPSG:32735 -r bilinear -tr 5 5 dem_new.tif dem_utm.tif
gdaldem slope dem_utm.tif slope_deg.tif

Loading validated drillhole collars into PostGIS as 3D points, with an index:

CREATE TABLE collars (hole_id text PRIMARY KEY, x double precision,
                      y double precision, z double precision, td double precision);
-- after COPY from CSV:
ALTER TABLE collars ADD COLUMN geom geometry(PointZ, 32735);
UPDATE collars SET geom = ST_SetSRID(ST_MakePoint(x, y, z), 32735);
CREATE INDEX idx_collars_geom ON collars USING GIST (geom);
ANALYZE collars;

That database then feeds both QGIS (for context maps) and the modelling package (collar/survey/assay export), with one authoritative copy.

Common pitfalls and why they happen

  • Picking "best GIS" before naming the workflow. The honest answer is always "for which phase and which data?" A targeting team and an operations team need different stacks.
  • Running repeatable jobs by hand in the desktop GUI. Manual reproject-and-clip for every new tile is slow and unauditable. Move recurring steps into a GDAL/Python script.
  • Keeping drillhole data in spreadsheets. No referential integrity, no overlap checks, no concurrency. It belongs in a database.
  • Treating GIS as mine-modelling software. GIS does spatial context, not block models or resource estimation. Forcing it leads to brittle, wrong 3D.
  • License-cost-only decisions. Choosing or rejecting ArcGIS purely on price ignores team skills, support needs, and migration cost. Prototype the riskiest step before committing.
  • Skipping the metric-CRS reproject for terrain. Slope and lineament analysis on a geographic-CRS DEM is simply wrong; bake the reproject into the pipeline.

QA and validation

  • Confirm one authoritative copy of each dataset (the PostGIS table, not three diverging shapefiles on three laptops).
  • Verify drillhole tables pass integrity checks (unique hole IDs, no overlapping intervals) before they enter the model.
  • Keep CRS, vertical datum, and processing steps documented so an audit can reproduce a layer.
  • Prototype the single riskiest step — usually drillhole integration or large-imagery handling — before standardising the whole stack.

Bathyl perspective

We judge a mining GIS stack by whether it produces results another team can inspect, reproduce, and defend, not by which logo is on the splash screen. The durable pattern is consistent across projects: desktop GIS for interpretation, GDAL for repeatable processing, PostGIS as the system of record, and specialist software for the 3D orebody — chosen to fit the lifecycle phase you are actually in.

Related Bathyl reading

Sources