Post-mortem · Géomatique et ingénierie linéaire

Fusion bathymétrique et topographique

Water authority · flood-prone river corridors · one continuous bathy-topo surface across 86 river km · Python, PDAL, PostGIS, QGIS

Réserver une revue de périmètre →Tous les dossiers de livraison
Contexte

La situation.

Une autorité de l’eau cartographiant des corridors fluviaux sujets aux inondations, où les couvertures lidar et sonar doivent s’aligner.

Périmètre

Traitement conjoint des levés de lidar bathymétrique à grande longueur d’onde et de sonar multifaisceaux : fusion des points corrigés de la réfraction à la ligne d’eau, une seule surface continue à travers la limite mouillée, et rasters de changement entre époques de levé pour le bilan sédimentaire.

Résultat

Une seule surface bathy-topo continue sur 86 km de rivière, acceptée comme intrant du modèle hydraulique sans reprise.

Stack
PythonPDALPostGISQGIS
Topologie

Two survey streams arrive separately: green-wavelength bathymetric lidar flown over the corridor and multibeam sonar run in the channel. A PDAL pipeline ingests both point sets, applies refraction correction where points cross the waterline, and merges them into one continuous surface spanning the wet-topped boundary. A stage-correction model keyed to gauge readings aligns each epoch to a common water level before comparison. Where vegetated banks absorbed the green lidar, photogrammetric points from the same sortie fill the gaps, and every cell carries a confidence flag for how it was filled. PostGIS stores the epochs; change rasters between epochs are computed for sediment budgeting and served into the authority's desktop tooling.

Arbitrages
  • Envisagé : interpolating across the gaps where vegetated banks absorbed green lidar

    Choisi : fusing photogrammetric points from the same sortie and flagging confidence per cell

    Parce que : modelled water would read the interpolated cells as measured ground, which is the error you cannot see

  • Envisagé : treating the 14 m waterline shift between lidar and sonar passes as bad data

    Choisi : an observed-stage correction model keyed to gauge readings

    Parce que : the shift was the river, not the sensor, and epoch comparison only becomes valid once stage is normalised

  • Envisagé : delivering separate wet and dry surfaces

    Choisi : one continuous surface across the wet-topped boundary

    Parce que : the hydraulic model consumes a single terrain, and a seam at the waterline would inject a false boundary into every run

  • Envisagé : accepting only cells covered by both lidar and sonar

    Choisi : keeping the full corridor with per-cell confidence

    Parce que : the authority maps flood-prone corridors, and full coverage with honest confidence serves that better than a patchwork of perfect cells

Choix de stack

PDAL owns the point-cloud handling because both streams are points with different physics and it treats them as one problem. Python carries the refraction correction and the stage model, where the work is physics and statistics. PostGIS holds the epoch store and the change-raster arithmetic because sediment budgeting is a standing query over epochs. QGIS stays in the stack because the desktop the authority's modellers already work in opens the surface directly, with no new tool to learn.

Télémétrie

One continuous bathy-topo surface across 86 river km, accepted for hydraulic model input without rework. The waterline moved 14 m between the lidar and sonar passes; the observed-stage correction model, keyed to gauge readings, is what made epoch comparison valid. Cells where vegetated banks absorbed the green lidar carry per-cell confidence flags for the photogrammetric fill.

Section 1

Discovery findings

The water authority maps flood-prone river corridors, and the mapping depends on lidar and sonar coverage that must align. Green-wavelength bathymetric lidar covers the corridor from the air; multibeam sonar covers the channel from the water. The two passes do not share a waterline: each was flown or run under its own river stage, and the authority's sediment budgeting needs change rasters between survey epochs, which only means something when the epochs describe the same river. Discovery also put the physics on the table: at the wet-topped interface the green lidar refracts through the water surface, and the sonar and lidar footprints have to meet there or the merged surface carries a band of fiction along the shoreline.

Section 2

The hard problem

Between the lidar and sonar passes, the waterline moved 14 m. Merged naively, the surface would report riverbed where the sonar pass ran and dry ground where the lidar pass ran, and every epoch comparison would inherit that shift as change. We built an observed-stage correction model keyed to gauge readings: each pass is normalised to a common stage before points are compared, which is what turns epoch comparison from decorative into valid. The second problem sat on the banks. Vegetated banks absorbed the green lidar, leaving gaps exactly where flood modelling needs terrain. Interpolating across them would manufacture plausible ground, so we fused photogrammetric points from the same sortie and flagged confidence per cell.

Section 3

The build

The pipeline ingests both point sets in PDAL, with Python carrying the refraction correction at the waterline and the stage model. Corrected points from both sensors merge into a single continuous surface across the wet-topped boundary. Photogrammetric fills land in gap cells with confidence flags, so a modeller reading the surface can tell measured lidar, measured sonar and filled ground apart. PostGIS stores each epoch, and change rasters between epochs derive from it.

Section 4

Verification

Verification ran against the authority's acceptance criterion: the surface had to enter the hydraulic model without rework. It did, across all 86 river km. The stage-correction model earned its place in review because a reviewer can trace the gauge readings behind any normalised epoch, and the 14 m waterline shift is documented as the reason the model exists, with the lineage visible behind every normalised epoch. Change rasters between epochs fed the authority's sediment budgeting from that same store, so the numbers quoted for budgeting come from the epochs the surface was built from.

Section 5

Handover

Handover left the authority operating the pipeline with outputs in their existing QGIS workflow. The epoch store grows with each survey season, and the stage model reads gauges the authority already maintains, so epoch alignment does not depend on us. Runbooks cover the PDAL ingestion, the refraction correction, the confidence flagging and the change-raster generation, and the studio's standard 30 days of post-launch support covered the first production questions. Corridor mapping continues on one bathy-topo base where the waterline is a stage-keyed boundary rather than a survey artefact.

Un problème similaire ?

Périmètre fixe, ingénieurs seniors, staging en ligne dès la première semaine.

Réserver une revue de périmètre →