Gujarat Reservoir Watch
A daily view of Gujarat's 206 reservoir schemes that answers one question the source
does not answer for you: how does today's storage compare with the same calendar date in
previous years?
The Gujarat Water Resources Department publishes a storage report every day as a PDF. It
tells you where each dam stands today, and — at regional level only — how that compares
with the same day one year ago. It does not give you five years of daily history, a
per-dam comparison, or any way to tell whether a reservoir that is 40% full is recovering
or falling. This project builds that history from the published reports and shows it.
Latest report: 11 September 2026. Gujarat is 65.29% full against a four-year mean of
82.61% on the same date. The weakest prior year on this date was 2023, at 73.53% — 2026
is 8.24 points below even that.
Nothing here is a forecast. Every figure is a comparison of observed readings. No
number on any page states what storage will be on any future date.
What it shows
Open web/reservoir.html. Two views; the first is the default.
Season — a state headline, then five regional facets ordered worst-deviation-first.
Each facet plots % filling for 2026 heavily against the four prior years thinly, on an
aligned day-of-season axis (day 1 = 1 June), with a rainfall strip beneath sharing the
x-axis. Below the facets, two deviation tables that answer deliberately different
questions. A scheme search in the header opens any of the 206.
Each facet carries a crossover marker: the date 2026 fell below every prior year.
A day only counts if the current season and all four prior years have a value for it, and
the marker is the first day of the first run of ≥5 consecutive such days. Five days is
the one tunable parameter and the interface states it, because a shorter rule would turn a
one-day dip into a headline. On the current data:
| Crossed below all four prior years |
|---|
| Kutch | 19 July, and has stayed below — 55 days |
| Saurashtra | 20 July, still below — 54 days |
| South Gujarat | 25 July, recovered 2 Aug; 2 days below now, short of the rule, so no second crossing is claimed |
| North Gujarat | 29 August, still below — 14 days |
| Central Gujarat | never — below the prior mean, but never under all four for five days |
| Gujarat (state) | Below every prior year since 26 August — 17 days. Also fell below briefly on 27 July, recovering 2 August |
Schemes — all 206 dams as one point each, sized by design capacity and coloured by
deviation, with a region filter. Not a map; see Why there is no map.
Data source and licence
Source: Reservoir Data Management System, Narmada, Water Resources, Water Supply &
Kalpasar Department, Government of Gujarat — https://wrd-dam.gujarat.gov.in
The daily report is a download, not a scrape. The only URL parameter is the date, as
standard base64 of the plain ISO string, padding included:
https://wrd-dam.gujarat.gov.in/downloads/home_pdf.php?dt=MjAyNi0wOS0xMQ==
└─ base64("2026-09-11")
So the whole archive is directly addressable: no crawling, no pagination, no HTML parsing
to discover links. A backfill is a loop over dates.
Everything shown comes from that one file, including rainfall — pages 18–23 carry
per-scheme rainfall in the same PDF. (The IMD district feed in data/processed/ belongs to
the archived predecessor project, not to this one.)
Licence: not stated, so not asserted
The portal publishes no copyright policy, terms of use or data licence, and this
project does not claim one on its behalf. It is a Government of Gujarat departmental
publication. The Government Open Data Licence – India covers data published through
data.gov.in; this is a departmental download and I have not verified that GODL applies to
it. If you intend to redistribute the source PDFs or a bulk dataset derived from them,
check with the department first.
What this repository holds is the code, plus derived figures carried with their provenance
(report date, byte count and SHA-256 of each file). The PDFs themselves are cached under
data/raw/dam/ and are not redistributed here.
On transport security
TLS certificate verification is deliberately disabled for this host, which does not
validate in this environment. The mitigation is that the fetcher records the SHA-256 and
byte count of every file in the ledger, so content is auditable even though transport is
not. The 11 September 2026 report is 276,237 bytes, SHA-256
10F4783D…0B2C4C28. If you can validate the certificate, re-enable verification in
scripts/backfill.py:ctx_noverify.
Method
backfill.py → parse_cached.py → build_db.py → check_capacity.py
download parse (parallel) DuckDB THE GATE
↓
build_view_data.py ← report_deviation.py
↓
web/reservoir.html
Run it:
python scripts/backfill.py --download-only --months 6-10 --delay 1.0
python scripts/run_pipeline.py --date 2026-09-11 --skip-pin
python scripts/build_view_data.py
python scripts/serve.py --root web --port 8020
Download and parse are separate because they have opposite constraints. The server
generates each PDF on demand and takes about 33 seconds, so downloading must be serial and
polite — a fixed delay between network requests, cache hits never sleeping, one request
at a time, an identified User-Agent. Parsing is local and CPU-bound at ~13–17 s per
23-page file, so it runs across worker processes. Both are resumable: a cached PDF is never
re-fetched, a parsed day never re-parsed.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
