A flood model is only as defensible as the terrain layer underneath it. The headline run-times and the hydraulic schemes get all the attention — but every meaningful result hinges on whether the underlying DTM honours the bridges, levees and culverts that water actually has to flow over, under and through.
If you've ever watched a flood model route inundation through a suburb the council insists has never flooded, you've usually got a terrain-layer problem rather than a hydraulic-scheme problem. The levees are flattened, the road embankment is missing, the culvert under the highway is being treated as a solid wall and the result is a model that confidently predicts something that physically can't happen.
The fix isn't in the model — it's upstream of it. This article walks through how drone LiDAR produces the hydro-enforced DTM that 1D and 2D hydraulic models actually need, and how that DTM hands off cleanly into TUFLOW, HEC-RAS, MIKE, XP-SWMM and the rest of the modelling toolset.
In a 2D hydraulic model, every cell of the model grid stores a ground elevation. At each timestep the solver computes flow between neighbouring cells based on water depth, slope and roughness. The elevation grid is the topology — it tells the solver where water can go and where it can't.
Get the elevation right at every cell and the model can produce defensible answers about depth, velocity, peak time and inundation extent. Get the elevation wrong anywhere and the model produces confidently-wrong answers in the same area, because the solver has no way of knowing the topology is incorrect.
Two things make terrain layer accuracy hard:
Bare-earth recovery under vegetation — flood is going to flow over the ground beneath the canopy, not over the canopy itself. Without LiDAR's multi-return capability, the DTM includes canopy as ground in vegetated areas.
Hydro-enforcement at structures — bridges, culverts, pipe inlets and weirs are real features that the elevation grid alone cannot represent honestly. They need explicit treatment.
Most of this article is about that second category.
A standard LiDAR DTM is the bare-earth surface — every ground return classified, every non-ground return removed, the remainder interpolated into a continuous surface.
A hydro-enforced DTM is the same surface with explicit modifications to honour hydraulic flow paths:
A DTM without hydro-enforcement is technically "correct" — every elevation is real. It's also operationally wrong for flood modelling, because the elevations include features (road decks, fill embankments over culverts) that the water has to go around in real life but goes over in the model.
The hydro-enforcement work ships as a breakline pack alongside the DTM. Standard contents:
The pack typically ships as a DWG file (for AutoCAD-based workflows), a SHP file (for ArcGIS-based workflows) and / or 12da for 12d-based workflows. Each polyline carries elevation at every vertex.
A capture quoting "DTM with hydro-enforcement" should ship this pack. A capture quoting just "DTM" almost certainly hasn't done the work.
The terrain requirement differs by hydraulic framework:
1D models (HEC-RAS 1D, MIKE 11, RORB, WBNM) route flow along defined channels. They need:
A LiDAR-derived DTM provides all of this — cross sections are generated at any chainage interval, structures are picked from the breakline pack, channel centreline traced from the network.
2D models (TUFLOW, MIKE 21, HEC-RAS 2D, ICM, XP-SWMM 2D) run on a grid (or unstructured mesh) of elevation cells. They need:
The 2D pipeline is more data-hungry but the result is generally the better representation of overland flow in urban or floodplain environments.
1D / 2D hybrid models (TUFLOW most commonly) use 1D for in-channel flow and 2D for overland flow, with linked interface nodes. The terrain requirement is essentially the union of the above — both the 1D cross sections AND the 2D DTM, plus careful treatment of the 1D/2D interface.
For most contemporary urban flood studies in Australia, TUFLOW 1D/2D hybrid is the working framework. The LiDAR scope reflects that.
For 2D models, the DTM cell resolution drives both the runtime and the result fidelity:
| Resolution | Per-km² file size | Runtime impact | Use case | | ---------- | ----------------- | -------------- | ------------------------- | | 0.25 m | Very large | Heavy | Urban detailed design | | 0.5 m | Large | Moderate | Standard urban modelling | | 1.0 m | Medium | Light | Rural and regional | | 2.0 m | Small | Very light | Coarse regional / sweep |
Half-metre is the default for most Australian urban flood work in 2026 — it's the sweet spot between resolving streets and gutters (which influence flow paths) and keeping runtimes acceptable for multi-AEP scenario modelling.
The DTM doesn't need to be re-flown to change resolution; the same captured cloud can produce DTMs at any resolution down to its intrinsic point density. Specifying multiple resolutions in the deliverable (e.g. 0.5 m for the inundation cells + 1 m for the boundary buffer) is routine.
The terrain elevation tells the solver where water goes; the Manning's roughness coefficient tells it how fast. The hydro-DTM pack typically ships with a paired land-cover raster classified into roughness categories:
LiDAR + a paired aerial ortho gives enough information to classify land cover at the model cell resolution. Some captures use the NDVI from RGB-NIR cameras to refine the vegetation classification. The deliverable is a roughness raster the modeller can edit at specific cells if local knowledge differs.
A modeller who has to hand-digitise land cover from satellite imagery is doing a lot of work the capture could have done for them. Specifying land-cover at scoping saves the modelling team 1–2 days per project.
Property-level inundation modelling needs more than the DTM — it needs to know which cells are inside buildings and what the floor-finished level is at each one:
Building footprints fall out of the LiDAR cloud classification naturally. FFLs are typically validated against an independent survey of the buildings expected to be inside the inundation envelope — a quick ground-survey pass on the night before the LiDAR flight, with FFLs tied to AHD.
For council inundation studies, the FFL register is often the deliverable that gets the most stakeholder attention — every property owner wants to know whether their house is inundated in the 1% AEP, and getting the FFL right is what determines whether the answer is defensible.
Different tools have slightly different ingestion expectations. The standard hand-off package by tool:
TUFLOW — DTM as ASCII grid (or hydraulic-elevation file), breakline pack as 12d or DWG, Manning's n as ASCII grid or material polygons, buildings as gauged-Z polygon SHP.
HEC-RAS — DTM as GeoTIFF, cross sections as RAS Mapper geometry, structure tables as CSV, terrain modifications as RAS Mapper terrain-edit layer.
MIKE 21 / MIKE FLOOD — DTM as DFS2 grid, dynamic boundary nodes as DFS0 time-series, land cover as DFS2 grid.
XP-SWMM — DTM as ASCII grid, hydraulic conduits and links as SWMM input file, sub-catchment boundaries as polygon SHP.
ICM — DTM as GeoTIFF, river network as ICM-native geometry, mesh as TIN or polygon SHP.
A capture quoting the right formats for the modelling team avoids the modeller spending days on data conversion. We work backwards from the tool to package the deliverable correctly at handover.
Drone LiDAR also has a role after a flood event:
The same control regime that the baseline used keeps the comparison apples-to-apples. The deliverable is typically a change-detection raster + a damage register + per-property inundation depth.
Three patterns we see in projects that go sideways:
DTM delivered without hydro-enforcement. The terrain layer opens in the modelling tool and looks like a DTM. The modeller runs the first scenario. Flood water goes over the highway because the culvert was never enforced. Three days of debugging later, someone realises the hydro pack was never specified at quote time. Cheap to specify upfront; expensive to retrofit.
Wrong cell resolution for the framework. A 0.25 m DTM delivered for a regional rural model — runtimes balloon, no extra fidelity is gained. A 2 m DTM delivered for an urban detailed-design study — streets aren't resolved, flow paths are wrong. Match resolution to use.
FFL register absent or stale. Property-level inundation is the part of the modelling report that gets cross-examined at council. FFLs from the most recent ground survey are part of the package; FFLs from 15-year-old council records aren't sufficient for a current inundation study.
Flood modelling lives on the terrain layer. LiDAR provides the bare-earth DTM that hydraulic modellers actually need — hydro-enforced at structures, paired with Manning's n land cover and a building / FFL register, packaged in the format the modeller's tool expects.
A capture specified for flood modelling (rather than generic DTM) lands with all of the above. A capture specified as just DTM requires retrofit work that's often more expensive than specifying it correctly upfront. Worth getting right at quote time.
Tell us the framework (1D, 2D, hybrid), the modelling tool, and the AEPs of interest. We'll scope the capture + breakline pack + land cover + FFL register to drop straight into your modeller's workflow.