Optimal sensor placement in gravity sewers

Optimal sensor placement in gravity sewers

An interactive sandbox, three simulations and two explainers, built on openly published South Australian network data.

Water utilities put level sensors in sewer maintenance holes to catch blockages before they become overflows. There are far more chambers than sensors, so the question is which chambers. This is a working tool for exploring that, running on a real network rather than a synthetic one.

Interactive

OSP Sandbox

Place a budget of sensors on 1,002 real gravity mains and 360 real maintenance holes. Seven algorithms scored against the same objective, including a practitioner rule of thumb and a slot for your own JavaScript. Includes an assumptions register, the method and its sources, and a glossary.

Interactive, latest

Simulation 2.5: which manholes see growth, whatever the unknowns

The growth model rebuilt on the whole council network below the catchment, solved in EPA SWMM, with outside inflows where other areas join. Twelve cases vary what cannot yet be measured: infiltration, peaking, older pipes leaking more, and outside inflow. The finding: under a fixed 150 mm alarm the best sensor moves with every case, but judged on a rise of 10 or 25 mm over each manhole's own level, one pair of sensors keeps most of the achievable coverage in all twelve. The threshold itself is what real level records would settle.

Earlier version of 2.5

Simulation 2.5 as first published (25 Sep 2026)

The first Simulation 2.5: the 71-chamber segment draining to node 583, twelve cases, one roughness on every pipe and pump stations passed straight through. Kept so its results can be compared with the current whole-area model.

Superseded by 2.5

Growth and sensor placement

A whole drainage catchment in 3D, 157 pipes and 71 chambers, solved in EPA SWMM with the connected properties counted from the published record rather than assumed. Choose where new dwellings connect and watch which chambers tip into surcharge, then see the fewest sensors that would catch every case. The finding it is built around: growth does not surcharge a sewer, it eats the headroom the sewer needs to absorb wet weather.

Earlier version

Warning time, from a wet weather event

The question this model asked before it moved to growth: four chambers around one junction, a surge passing through, and how many minutes of warning a sensor in each chamber would give before the network spilled. Kept because it answers a different question, not a worse one, and because it is where the finding that a level sensor barely beats a float switch at these thresholds came from.

Explainer

What a maintenance hole is

Three rotatable 3D sections. What one chamber looks like inside and where the sensor sits; why every chamber along a run is a different depth; and where the water goes when a blockage forms. Start here if the vocabulary is new.

Explainer

Why observability is limited

A draggable long section showing the backwater wedge behind a blockage, and the arithmetic that decides how far upstream a sensor can still see it.

What is interesting here

Two things came out of building this that are worth more than the tool itself.

A published method's own parameterisation was doing most of the damage. The placement condition uses a water-depth capacity term. Substituting pipe diameter for it, which is what you do when manhole depth is not published, understates the term by roughly a factor of nineteen. That single substitution is the difference between most of the network appearing unobservable and almost none of it:

Depth used in the modelObservable universeChambers observing nothing
Pipe diameter, 0.15 m157 / 1010840 (83.2%)
Measured depth, median 2.92 m813 / 101032 (3.2%)

The invert fields are labelled by flow, not by geometry. On both publishers examined, START_INVE is the upstream-of-flow invert whichever way the line was drawn. Reading it as a geometric label silently reverses the majority of pipes while leaving every record, node and edge count identical, so the error is invisible to the usual sanity checks. Verified by testing which reading makes inverts agree at shared chambers: 95.3% exact against 35.2% and 37.0% for the alternatives.

It also means the common check START_INVE > END_INVERT returning every record is true by definition of the field names. It is a naming convention, not evidence that a network runs downhill and not evidence that it is acyclic.

Where the data comes from

Everything here is built from services that answer anonymous queries, so every figure can be re-checked independently. The network is a council's open republication of the operator's sewer asset register: 1,002 gravity mains with invert levels on every record, 360 mapped maintenance holes, and a 1 m contour layer.

Chamber depth is published almost nowhere, so it is reconstructed as cover level minus invert, with cover interpolated from those contours. That reconstruction was validated three ways and lands within about 0.23 m against surveyed values, on chamber depths of roughly 2.9 m. The assumptions tab lists every figure, every remaining assumption, and what data would remove it.

Honest limits

Nothing here has been validated against a recorded blockage: no public source lists historical chokes or overflows, so the tool can say which chambers would see a blockage under this model, not whether they did. The detection threshold is a declared parameter rather than a calibrated one, because no sensor readings for this network are public. And the network is clipped to a council boundary rather than a drainage catchment, so anything near an edge is wrong in a known direction. All of this is stated in the tool itself.

Built from public data. Runs entirely in the browser, no server and no tracking.