Short answer

For environmental projects, a dependable open stack is QGIS for analysis and cartography, PostGIS for shared multi-user data, GDAL/OGR for scripted and batch processing, Google Earth Engine for large-area satellite work, and a web mapping library (Leaflet/MapLibre) for delivery. You rarely need all of it. The right stack is the smallest set of tools that covers your project's lifecycle and keeps the processing reproducible — the failure mode is not choosing the wrong brand, it's a workflow that only one person can rebuild.

Match the tool to the job

These tools overlap, but each has a job it does better than the others.

QGIS — the analyst's desktop

QGIS (open source, the natural alternative to ArcGIS Pro) is where you inspect data, digitise, style maps and run interactive analysis. Its Processing Toolbox exposes hundreds of algorithms — native (native:buffer, native:clip), plus GDAL, GRASS and SAGA providers — and the Graphical Modeler chains them into a reusable model. For environmental work it handles habitat mapping, constraint overlays, terrain analysis and print layouts in one place. Reach for QGIS when a human needs to look at the data and make judgements.

PostGIS — shared, queryable storage

PostGIS extends PostgreSQL with spatial types, a GiST spatial index and a large library of functions (ST_Intersects, ST_Buffer, ST_Union, ST_Transform). Switch to it when files stop coping: multiple editors, concurrent access, datasets too large for a GeoPackage, or analyses better expressed as SQL. A constraint intersection that crawls across files runs in seconds against an indexed table:

SELECT s.site_id, SUM(ST_Area(ST_Intersection(s.geom, h.geom))) AS overlap_m2
FROM sites s JOIN habitats h ON ST_Intersects(s.geom, h.geom)
GROUP BY s.site_id;

QGIS connects to PostGIS directly, so the database is your store and QGIS the window onto it.

GDAL/OGR — the processing engine

GDAL (raster) and OGR (vector) underpin almost every GIS tool and are unbeatable for scripted batch work. Reproject a whole folder, mosaic tiles, convert formats, clip rasters — all from the command line and therefore all reproducible:

gdalwarp -t_srs EPSG:32630 -tr 10 10 -r bilinear in.tif out_utm.tif
ogr2ogr -t_srs EPSG:32630 -f GPKG out.gpkg in.shp

When the same operation must run identically every month, or over hundreds of files, GDAL beats clicking through a dialog. Wrap it in a shell script or call it from Python (rasterio/Fiona/GeoPandas) for full pipelines.

Google Earth Engine — planetary-scale imagery

Earth Engine hosts petabytes of satellite data (Landsat, Sentinel-1/2, MODIS, climate layers) and runs the computation on Google's servers — you script the analysis, not the download. For environmental monitoring across large areas or long time series — deforestation, NDVI trends, surface-water extent, land-cover classification — it is unmatched. A few lines compute a multi-year median composite or a change index over a whole region. Use it when the area or the time depth is too big to pull down and process locally; export only the result.

Web mapping — delivery

Leaflet or MapLibre GL serve the result to stakeholders. Decide the data model and tile strategy first: vector tiles (e.g. via a tile server or pre-generated PMTiles/MBTiles) for interactive thematic layers, raster/COG tiles for imagery. The library is the last decision, not the first.

A reference stack for an environmental study

A typical regional environmental assessment wires together like this:

  1. Ingest: GDAL/OGR reproject every input to one project CRS (a metric UTM zone or national grid) and load into PostGIS.
  2. Large-area context: Earth Engine derives land-cover and vegetation-change layers; export GeoTIFFs of the study area.
  3. Analysis: PostGIS does the heavy overlays and proximity queries via SQL; QGIS handles interactive interpretation and terrain work.
  4. Automation: a Python script (GeoPandas + rasterio, or PyQGIS) re-runs the constraint pipeline whenever an input changes.
  5. Cartography: QGIS Print Layout for report figures.
  6. Delivery: publish selected layers as vector tiles to a MapLibre viewer for the client.

The ArcGIS equivalent (ArcGIS Pro + Enterprise Geodatabase + arcpy + ArcGIS Online) covers the same ground; the principles are identical, the difference is licensing and ecosystem.

When to escalate from files to a database

Stay on GeoPackage files while work is single-analyst, portable, or genuinely small — it is an OGC standard, holds many layers in one file, and travels well (including offline to QField). Escalate to PostGIS when you hit any of: concurrent editing, datasets that make file operations slow, a need for spatial SQL and joins, versioning, or serving data to a web app. Avoid Shapefile as a working format — the 10-character field-name limit, 2 GB cap and multi-file fragility cause silent data loss.

Common pitfalls and why they happen

  • Picking the tool before the workflow. "Which GIS is best?" has no answer without the lifecycle. Map raw-data-to-decision first, then choose.
  • Clicking what should be scripted. Repeating a manual QGIS sequence monthly invites human error and is unauditable. Move recurring processing to GDAL/Python.
  • Files where a database belongs. Several people editing one GeoPackage on a shared drive leads to locks and lost edits. That is the signal to adopt PostGIS.
  • Downloading what Earth Engine should compute. Pulling years of Sentinel tiles to a laptop is slow and fragile; do the reduction in EE and export only the answer.
  • Choosing a web library first. Picking Leaflet vs MapLibre before deciding the tile strategy and data model forces rework. Decide the data flow, then the viewer.
  • CRS drift across tools. Each tool handles reprojection slightly differently; let layers wander between CRSs and overlays silently misalign. Set one project CRS and reproject on ingest.

Validation and QA

  • Confirm every layer is in the agreed project CRS after ingest, regardless of which tool created it.
  • Keep processing in scripts/models so any figure can be regenerated from raw inputs.
  • Version data and code (PostGIS schemas, Git for scripts) so results are reproducible months later.
  • Test the riskiest step — the largest dataset, the trickiest reprojection — on real data before committing to the stack.
  • Document the handoff points between tools so the pipeline does not live only in one analyst's head.

Bathyl perspective

We choose stacks by whether the work can be rebuilt by someone else next year, not by brand loyalty. The right combination of QGIS, PostGIS, GDAL, Earth Engine and a web viewer is the one where every output traces back to a script, a versioned database and a stated CRS — so the environmental conclusions remain reproducible long after the project closes.

Related reading

Sources