OS Open Rivers
What it is
OS Open Rivers is Ordnance Survey's open dataset of the connected watercourse network of Great Britain — rivers, streams, canals, and the links between them — published under the Open Government Licence as part of OS OpenData. It is the go-to open layer for answering "is there a watercourse on or near this site?"
How it's produced
Derived and generalised from Ordnance Survey's detailed mapping into a connected network model. It is a cartographic/topological network product, not a hydrological survey — it tells you where watercourses are and how they connect, not their ecological condition or flow.
Update frequency & currency
Refreshed on OS's periodic OpenData release cycle. Good positional currency for the network; check the OS release date for the edition in use.
Spatial resolution / precision
Good positional accuracy for a national open product. Geometry type: as published by Ordnance Survey, OS Open Rivers contains exactly two feature types — WatercourseLink (line) and HydroNode (point), marking junctions, sources, ends, and tidal-limit changes. OS is explicit that the product does not represent river width — there is no polygon feature type in the source data; a separate, different OS product (the Water Link feature type in OS NGD) exists for width/polygon representation.
Because the source layer is line-only, area cannot be taken directly from a
linear feature. A footprint has to be derived (e.g. by buffering) before any
area-based calculation — computing area straight off a LineString yields zero and
silently corrupts downstream scoring. This is a known handling requirement in the
WildStack pipeline. (Note: if the WildStack-ingested habitat_rivers table shows
polygon geometry alongside lines, that reflects WildStack's own post-ingest
processing — e.g. buffered footprints already added — not a property of the raw OS
download; re-run ogrinfo against an untouched download to confirm before treating
"mixed geometry" as a source-data fact.)
Known limitations
- Network, not condition. It shows presence and connectivity, nothing about water quality or ecological status — that is the WFD dataset's job.
- Generalised geometry. Suitable for presence/proximity, not for precise bank delineation.
- No width/polygon representation in the source product — see above.
How it compares to WFD Waterbody Classifications
They are complementary halves of "the water picture":
| OS Open Rivers | WFD Classifications | |
|---|---|---|
| Answers | Where is the watercourse? | What condition is the waterbody in? |
| Publisher | Ordnance Survey | Environment Agency |
| Nature | Network geometry | Ecological/chemical status per waterbody |
| Use together | Presence + proximity | Attach status to the reach |
Use OS Open Rivers to establish presence, then WFD to describe the reach's assessed status.
Role in BNG assessment
In WildStack's stack, OS Open Rivers drives the watercourse-present signal and provides watercourse geometry in the dataset hierarchy (sitting above the general land-cover layer for the specific question of watercourse features). Because the source is line geometry, area contribution is derived carefully (via buffering) rather than read off the geometry directly.
OS Open Rivers is a reliable, unglamorous workhorse — and line-only source geometry is the place naive spatial code quietly breaks. Buffer a line to get an area and forget to check whether your own pipeline has already added a derived polygon somewhere upstream, and you either double-count or zero-out. We treat "is this geometry the OS source or something my own pipeline derived?" as a first-class question for this dataset, not an afterthought. On the ecology side, remember its limit: it tells you a watercourse is there, never whether it's healthy. Pair it with WFD before you say anything about condition.
A real example of this trap, from our own build. For a while, WildStack's
internal engineering notes stated as fact that "OS Open Rivers contains mixed
geometry types (LineString + Polygon)" — supposedly confirmed by running ogrinfo
against the downloaded data. This wiki page repeated that claim. It was wrong, and
the way it was wrong is instructive: OS's own product spec is unambiguous that the
source dataset is line + point only, no polygons. What almost certainly happened is
that the ogrinfo run was pointed at our own PostGIS table, after our ingest
pipeline had already buffered the lines into polygon footprints — so we were
reading back our own derived output and mistaking it for a property of the OS
source data. A field-confirmation step that's meant to catch bad assumptions
(ogrinfo before writing code) still produced a wrong "fact" downstream, because it
was pointed at processed data rather than the untouched download.
The lesson isn't "don't trust ogrinfo" — it's "trust ogrinfo against the actual
source file, and be precise about which file that is." A confirmed fact that quietly
drifted to mean "confirmed against something in our own database" is a subtler
failure mode than an unverified guess, because it looks verified. We're leaving
this note here rather than quietly fixing the claim, because the interesting error
wasn't the wiki text — it was upstream of it.
Official source
Last reviewed
5 July 2026. Revisit on a new OS OpenData release or any change to the product's geometry model.