Water Quality Monitoring and Contamination Alerting

The problem with fixed limits in water testing

Utilities, environmental agencies and water NGOs test rivers, wells and supply points regularly and produce large volumes of results. Most of those results are checked against one fixed regulatory limit and otherwise filed away. A well whose nitrate readings have tripled over two years but are still just under the limit is a developing problem that nobody sees until it crosses the line. In places where many households depend on groundwater and testing is patchy, as in parts of Pakistan and South Asia, spotting a trend early is the difference between a warning and an outbreak.

Unsafe drinking water is a public health issue everywhere, and the data to detect trends often already exists; it is simply not analysed.

What already exists and the gap

• The Water Quality Portal, run by USGS and the US EPA with hundreds of partner agencies, publishes discrete water quality results with an API and bulk downloads.
• The England Water Quality Archive from the Environment Agency publishes sampling results from thousands of sites.
• Commercial monitoring platforms from sensor and laboratory information system vendors track results for utilities, usually tied to their hardware or lab software.
• GEMStat, from UNEP, collects freshwater quality data from many countries.

The data is published, but tools on top of it are mostly look-up interfaces or threshold checks. Smaller utilities, municipalities and NGOs rarely have anything that models each site's own normal behaviour. The gap is a lightweight analytics layer that turns existing test records into early warnings with reasons.

What you build

• Ingestion from a published dataset for one region: sites, coordinates, dates, parameters and values, with units harmonised and a log of what was dropped.
• Per-site baselines: for each site and parameter, a model of normal seasonal behaviour, for example a seasonal decomposition or a regression on month and trend.
• Anomaly detection: each new reading is scored against its site's baseline, flagging "unusual for this site in this season" separately from "above the legal limit".
• Interface: a map of sites coloured by status and a time series view per site showing the baseline band, the limit and the readings.
• Alerts: a list of new anomalies with reasons, and a feedback button so an analyst can confirm or dismiss each one.

The technically interesting part

Two things make this FYP-worthy. The first is seasonality. Many parameters rise predictably after rainfall or in warm months. Without deseasonalising, your detector fires every monsoon and is ignored by the end of summer. The second is irregular, sparse sampling. Real sites are tested monthly at best, with gaps of months, and some have only a handful of readings. Show your supervisor how your baseline handles a site with five years of data compared with one with ten readings, for example by borrowing strength from nearby similar sites, and how uncertainty is shown when data is thin.

How to evaluate it

• Historical events: find documented contamination events in the record, hold them out, and report how many your system would have flagged and how many days earlier than the first exceedance of the limit.
• False alarm rate: alerts per site per year on periods with no known incident.
• Comparison: a fixed-threshold baseline against your per-site method on the same data.
• User check: 3 people with a water, environmental or public health background review ten alerts and say which they would act on.

Suggested plan

1. Weeks 1 to 3: choose the region and dataset, ingestion, unit harmonisation, data quality log.
2. Weeks 4 to 6: seasonal baselines per site and parameter.
3. Weeks 7 to 9: anomaly scoring, reasons, threshold baseline for comparison.
4. Weeks 10 to 12: map, time series views, alerts.
5. Weeks 13 to 15: historical validation, user check, report.

Path to a product

The first users are likely an NGO running water testing programmes or a municipal water department that already has spreadsheets of lab results. Offer the analysis as a hosted dashboard with a per-organisation subscription, or a grant-funded pilot, which is common for public health tools. Later, connect it to a laboratory's result exports so new readings flow in automatically.

Scope warning

This is analysis of existing published data. Deploying sensors is a different project with different problems, and mixing them will leave you with neither done well. Do not present the tool as a replacement for regulatory testing or health advice; it prioritises attention.

Learn what you need on Sefism

• Data analytics roadmap : cleaning, time series and visualisation skills.
• Machine learning roadmap : anomaly detection and evaluation basics.
• Machine learning cheat sheet : precision, recall and model validation at a glance.
• PostgreSQL Documentation : storage and spatial queries for sites and readings.
• Our World in Data : context on water access and health for your report's introduction.

Get help with this idea

Validation against real events is what makes this project credible. Tauseef can help you choose a dataset, frame the evaluation and keep the scope achievable in one semester. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session