Proposed features/Rivers Classification

From OpenStreetMap Wiki
Jump to: navigation, search
Rivers Classification
Status: Proposed (under way)
Proposed by: Zverik
Tagging: river=*
Applies to: Way
Definition: Subjective classification of rivers
Drafted on: 2017-08-29

Proposal

Let's have a subjective river classification, so we could tell a big river from a small one.

It could be based on measurable (google-able) parameters, like length or width. The attribute would be useful for making low-zoom maps: for simplification, for rendering and for querying. It should be understandable to casual mappers, and should not affect any other tags.

Tagging

The following tags are proposed, along with the way to separate these:

  • river=major — a major river, more than 1500 km in length, or with basin of more than 300 000 km², or that contains any major rivers in its drainage basin. Basically, the first 91 rivers from wikipedia:List of rivers by length should be tagged with this.
  • river=big — a big river, more than 300 km in length, or with basin of more than 15000 km², or that contains any big rivers in its drainage basin.
  • river=small — all other rivers. This is considered a default value: when there is no river=* tag, a river is considered to be small.

These should be used together with waterway=river. Smaller waterways should still be tagged with waterway=stream, thus making it a fourth category of waterways.

Note that rivers form a network, and the size must only increase: streams flow into small rivers that flow into big rivers that flow into major rivers that flow into big lakes and oceans. Some of these steps may be omitted, but never a river flows into a river with lesser size. Lakes inbetween do not matter.

The threshold for big rivers could differ by continent or by country: for example, in UK it could be lowered to 200 km, and in US — increased to 500 km, to omit many smaller rivers. This proposal introduces the fixed value to serve as a rule-of-thumb.

Rationale

Copying from the alternative proposal:

OSM has only one way of general categorization waterways - streams and rivers (other than canals, drains and other well defined entities). It's very handy at the small scale, but at the large scale all the rivers are basically the same in our database. It should be possible to have general categories like we do with roads network, so we could for example render world map with only the most important rivers.

The obvious thought is to calculate the size of a river automatically or use a waterway relation. But the first way is complex and would benefit only a few mapping styles that are maintained by skilled developers. The second way is better, and you could use a distance=* tag from a relation. But these relations are mapped inconsistently, and even if you could maintain a hundred relations for major rivers, I doubt all the big rivers would have their relations mapped in at least a decade, without breaking any of these.

Thus I think that tagging river ways is the better option. But it could involve mass-tagging after the proposal is accepted.

Examples

  • Ways in River Volga (3645 km) and Rio Japurá (2615 km) should be tagged with river=major.
  • Ways in River Wisła (1047 km) and River Le Tarn (381 km) should be tagged with river=big.
  • Ways in Neva River should be tagged with river=big, since despite the small length (only 74 km), this river has an enourmous drainage basin, 281 thousand km². It may even be considered for a major class, to be shown on all maps that have Lake Ladoga.
  • Ways in River Yauza (48 km) and River Nene (161 km) should be tagged with river=small or not tagged with this key.

Applies to

The attribute should be used only on ways tagged waterway=river. Possibly also on waterway relations, though it is optional.

Rendering

The value of river=* would basically tell on which zoom level the river should be rendered.

Existing tag values

Taginfo shows around 150 uses of the river tag on ways. Most common values are river=yes, river=pond and river=riverbed. I assume we can safely disregard these.

Comments

Please comment on the discussion page.

See Also