Bathymetric and topographic fusion
Water authority · flood-prone river corridors · one continuous bathy-topo surface across 86 river km · Python, PDAL, PostGIS, QGIS
The situation.
Water authority mapping flood-prone river corridors where lidar and sonar coverage must align.
ScopeConjoined processing of green-wavelength bathymetric lidar and multibeam sonar surveys: refraction-corrected point merging at the waterline, a single continuous surface across the wet-topped boundary, and change rasters between survey epochs for sediment budgeting.
One continuous bathy-topo surface for 86 river km, accepted for hydraulic model input without rework.
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.
Considered: interpolating across the gaps where vegetated banks absorbed green lidar
Chose: fusing photogrammetric points from the same sortie and flagging confidence per cell
Because: modelled water would read the interpolated cells as measured ground, which is the error you cannot see
Considered: treating the 14 m waterline shift between lidar and sonar passes as bad data
Chose: an observed-stage correction model keyed to gauge readings
Because: the shift was the river, not the sensor, and epoch comparison only becomes valid once stage is normalised
Considered: delivering separate wet and dry surfaces
Chose: one continuous surface across the wet-topped boundary
Because: the hydraulic model consumes a single terrain, and a seam at the waterline would inject a false boundary into every run
Considered: accepting only cells covered by both lidar and sonar
Chose: keeping the full corridor with per-cell confidence
Because: the authority maps flood-prone corridors, and full coverage with honest confidence serves that better than a patchwork of perfect cells
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.
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.
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.
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.
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.
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.
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.