GIS Case Study
River Basin Hydrological Monitor — Automated River Monitoring
A hydrological monitoring system that finds, downloads, processes and visualises river basin data on an automated schedule.
Domain
Hydrology / River Basin Monitoring
Role
Full-Stack GIS Developer
At A Glance
What Makes It Work
Near-real-time water level and discharge for river basin stations
Automated product discovery and download driven by cron jobs
Station hydrographs plotted directly in the map pop-up
Processing status matrix showing exactly what was generated or missed
Data that arrives whether anyone fetches it or not
River basin monitoring depends on data that is published by several agencies on their own schedules, in their own formats, at their own URLs: gauge readings here, satellite-derived products there, forecast grids somewhere else. The hydrology team was spending its mornings finding and downloading the day's products by hand, then processing them before anyone could look at a hydrograph. On a busy day the processing did not finish before the next day's data arrived. The system was commissioned to make that pipeline disappear. Discover what has been published, download it, process it, and put it on the map: on a schedule, without a person in the loop, and with a clear record of what happened when something failed.
An ingestion pipeline with a status matrix
The platform runs on Django with PostgreSQL and PostGIS, and Leaflet for the map. The core is a scheduled ingestion pipeline driven by cron jobs: each job knows where a product is published, discovers new releases, downloads them, runs the processing step and writes results to PostGIS. Retry logic handles transient failures; permanent failures are reported rather than swallowed. The piece the hydrologists value most is the processing status matrix: a grid of products against dates showing exactly what was found, downloaded, generated or missed. When a hydrograph looks wrong the first question is always whether the data behind it is complete, and the matrix answers it in one glance. On the map, a gauge-station layer covers the basin with location and status, each station opening a pop-up hydrograph of recent water level, and station cards link directly to level and discharge series. Near-real-time water level and discharge are the headline products; the pipeline handles the rest.
What changed for the hydrology team
Mornings are no longer spent fetching files. Data is on the map when the team arrives, and when it is not, the matrix says why. Analysts spend their time on interpretation rather than acquisition, and the record of what was processed is complete enough to answer audit questions months later. This is, at heart, a data engineering project with a map on top. The scheduling, retry and status-tracking work is unglamorous and it is where the value sits: a monitoring system is only as trustworthy as its record of what it did and did not ingest.
Capabilities
Core Functionality
Gauge-station layer across the river basin with location metadata
Pop-up hydrograph showing the recent water-level time series
Station cards with direct links to water level and discharge views
Processing status matrix: generated, downloaded, found, not found, offline
Scheduled ingestion pipeline with retry and failure reporting
User accounts with sign-up, sign-in and password recovery
Station metadata: latitude, longitude, sensor, elevation and datum
Technologies
Tools & Stack
Product
From The Working Application
Questions
Frequently Asked Questions
How often does the pipeline run?
On a schedule defined per product, matched to how often each source publishes, some hourly, some daily. Schedules are cron-based and adjustable without code changes. Each run discovers new releases, so a product published late is picked up on the next cycle rather than missed.
What happens when a download or processing step fails?
Transient failures retry with backoff. Permanent failures are recorded in the processing status matrix and reported, so the team knows what is missing rather than discovering a gap in a hydrograph later. Nothing fails silently.
Can we add a new data source?
Yes. A source is a configuration describing where it is published, how to discover releases, and which processing step applies. Adding one is a configuration task plus, where the format is new, a processing adapter. Several sources have been added since launch.
Why Leaflet rather than a vector-tile stack?
The map layer here is a few hundred gauge stations and basin boundaries. Modest data where Leaflet is simple and sufficient. The engineering effort belonged in the ingestion pipeline, not the renderer, and the map engine was chosen to match that.
Contact Us
Have A Project?
Let’s Build ItHave a project in mind? Tell us what you're building and we'll get back to you within 12–24 hours with a clear plan.
🔒
100% Confidential
⚡
12–24 Hr Response
🛡️
60-Day Bug Fix
✅
Free Consultation
💬
Start Your Project
Fill in the details below or book a call