Short answer

A terrain intelligence platform is what you get when terrain GIS stops being a series of project folders and becomes a maintained system: source DEMs and vectors flow through a defined pipeline into normalized storage, derived products (slope, aspect, hydrology, susceptibility) are generated reproducibly, and everything is published through standard interfaces so the same dataset can power a download, an API query, and a dashboard without being rebuilt each time. The strategy is mostly architecture and discipline, not a single tool. Below is a concrete layered design with the standards and components that make it work.

The five-layer architecture

Think of the platform as five layers, each with a single responsibility. Coupling them loosely is what lets you change one without breaking the others.

1. Ingestion

Pull source data on a schedule or trigger: national/global DEMs (Copernicus GLO-30, SRTM, national lidar), satellite imagery, and authoritative vectors (geology, hydrography, cadastre). Catalogue each source with a STAC (SpatioTemporal Asset Catalog) item so you always know the provenance, resolution, acquisition date, and license. Ingestion should be idempotent — re-running it on the same source must not create duplicates.

2. Normalized storage (the system of record)

This is the authoritative layer. Vectors live in PostGIS with a deliberate schema, a chosen projected CRS per region, spatial indexes (CREATE INDEX ... USING GIST (geom)), and constraints. Rasters live as Cloud Optimized GeoTIFF (COG) in object storage, tiled and overviewed so a client can read a window over HTTP range requests instead of downloading the whole file:

gdal_translate dem.tif dem_cog.tif -of COG -co COMPRESS=DEFLATE -co OVERVIEW_RESAMPLING=BILINEAR

Keep this layer normalized and clean. Everything downstream is derivable from it; if the platform burned down, this layer plus the derivation code is what you would rebuild from.

3. Derivation

Reproducible products generated from the system of record by code, never by hand. Terrain derivatives use GDAL/SAGA/WhiteboxTools, for example:

gdaldem slope dem_cog.tif slope.tif -compute_edges
gdaldem aspect dem_cog.tif aspect.tif
gdaldem hillshade dem_cog.tif hillshade.tif -multidirectional

Hydrology (flow accumulation, stream networks, watersheds) and susceptibility models also live here. The rule that defines a platform: a derived product is an output of versioned code over a versioned input, so it can always be regenerated and never has to be reverse-engineered.

4. Publishing

Expose data through standard interfaces, chosen by access pattern:

  • OGC API - Features for queryable vector access (bbox, datetime, and property filters over HTTP/JSON). A common stack is pg_featureserv or pygeoapi in front of PostGIS.
  • Vector tiles (MVT), served from PostGIS via ST_AsMVT or pre-generated, for fast web rendering of large feature sets.
  • COG + a tile/coverage endpoint (e.g. a titiler-style service or OGC API - Tiles) for dynamic raster visualization and analysis windows.
  • GeoPackage / GeoParquet snapshots for bulk download.

5. Access and experience

Downloads, an API, embedded maps, and dashboards sit on top of the publishing layer. Critically, the dashboard is a consumer of the API, not a separate data path — so the chart and the download always show the same numbers.

Metadata and versioning: the spine

Two cross-cutting concerns determine whether the platform is trustworthy.

Metadata. Every dataset carries discovery metadata (ISO 19115 / OGC records or STAC) and inline lineage: source, source date, CRS, processing steps, resolution, accuracy, and license. Without lineage, a consumer cannot judge fitness for use, and the platform is just a faster way to ship unverifiable files.

Versioning. Treat releases as immutable. Use a semantic-style version plus a date (geology_v2.3.0_2026-01-15) and keep prior versions resolvable. When new source tiles arrive, re-derive only the affected products and publish a new version with a changelog — never silently overwrite, because a consumer who pinned v2.2 must keep getting v2.2. PostGIS makes incremental updates manageable with transactional writes and, if needed, audit/history tables.

A concrete example: a regional slope-risk service

Say clients keep asking "what is the slope and landslide susceptibility for this parcel?" As a platform:

  1. Ingest Copernicus GLO-30 tiles for the region; record each in STAC.
  2. Store a mosaicked, reprojected COG in object storage and parcels in PostGIS (projected CRS, GIST-indexed).
  3. Derive slope and a susceptibility raster with versioned scripts; load classified susceptibility polygons into PostGIS.
  4. Publish parcels and susceptibility via OGC API - Features; serve the susceptibility raster as COG-backed tiles.
  5. Access: a parcel lookup endpoint does ST_Intersects between the parcel geometry and susceptibility polygons and returns JSON; the same endpoint feeds both a one-line API response and the dashboard map.

When the DEM is updated next year, you re-derive slope and susceptibility, publish v2, and every consumer gets current data without a single manual re-export.

Common pitfalls and why they happen

  • A "data product" that is a shared folder. No metadata, no version, no update path. It happens because shipping files is the path of least resistance; it fails the moment someone asks "is this current?"
  • Building the API or dashboard first. Without a clean system of record, the API just exposes a mess. The order is storage → derivation → publishing → experience.
  • Overwriting in place. Convenient, but it breaks every downstream consumer and destroys reproducibility. Version instead.
  • Rasters as monolithic GeoTIFFs over the web. Forces full downloads; COG with overviews and HTTP range reads fixes it.
  • Ignoring license and redistribution rights. Some source DEMs and imagery have attribution or non-commercial constraints that must travel with the product.

QA and validation

  • Reproducibility test: delete a derived product and regenerate it from the system of record plus code; the output must be identical (byte-for-byte for deterministic GDAL operations, or within tolerance).
  • Schema and CRS checks on ingestion: reject inputs with missing CRS or unexpected geometry types before they enter storage.
  • API contract tests: confirm OGC API - Features responses validate against the schema and that bbox/datetime filters return expected counts.
  • Metadata completeness: every published asset has source, date, CRS, resolution, and license, enforced in CI.
  • Version integrity: old versions remain resolvable after a new release; changelog entries exist.

Bathyl perspective

The shift from deliverable to platform is mostly a shift in where the truth lives: from a finished map to a maintained system of record plus the code that derives products from it. We design that boundary deliberately so that updates compound — each new DEM or geology release improves a durable asset rather than spawning another one-off rebuild — and so the science stays traceable from a dashboard pixel back to the source tile and its license.

Related reading

Sources