Talk:Tag:waterway=river

visibility of rivers

I'd really like to see rivers show up in mapnik at a higher zoomlevel than only ≥ z12. Even riverbank/water are only showing up as early as z7 ! Rivers can be seen from space much earlier than any motorway. why not show them as early as z6 ?!? --katpatuka 08:36, 23 August 2008 (UTC)

The problem is that we don't have any classification above stream/river difference (look here). I try to create it here: Proposed_features/Waterways_classification --Kocio (talk) 15:08, 10 August 2017 (UTC)

Direction of flow

Is there any guidlines to which way to track a river? For instance the direction of flow. I have always tracked rivers the way the water flow, that is from the mountains to the sea. --Skippern 13:22, 19 October 2008 (UTC)

The article says "Direction of the way should be downstream." axk 17:29, 8 April 2009 (UTC)

I just got involved in a "don't use oneway=yes on waterways" discussion. I've read some information about it and find it unsatisfactory. The rule "direction of the way should be downstream" is easy enough, but what about waterways that are tagged from satellite images where the flow of direction isn't known? And can it be guaranteed that people tagging waterways do it correctly? I wouldn't say so and I think an additional tag is needed. Although I consider using oneway=yes only "creative" some people seem to consider it plainly "wrong". So an alternative tag would look like a good compromise, but the discussion so far doesn't seem to have led to any generally accepted result (or at least there is no such result mentioned in "map features" as a tag). Should a new discussion be started? Tesche 10:00, 24 August 2012 (UTC)

There seems to be a disagreement on this, still. To-Fix says that rivers (inherently one-way, as opposed to an estuary, which is bi-di) which are tagged oneway=yes are incorrect and need fixing. And yet, there seem to be a bunch of rivers in a Canadian import (GeobaseNHN_Import_2009) that got imported with oneway=yes. It is reasonable to tag a river as oneway=yes, and not tag an estuary as oneway. Or maybe we should introduce a waterway=estuary which is implicitly bi-directional, while a river is implicitly oneway. RussNelson (talk) 22:57, 9 November 2014 (UTC)

IMHO, this use of the tag oneway=yes is contradictory to the current definition of oneway : This means that this tag should be used when this way can only be used in one direction. Beeing "used" isn't something to be consider from the water standpoint, but from humans point of view (And even if, water doesn't "use" the river). So the oneway tag should have nothing to do with the rivers's flow but the humans access restrictions on that said river. In other words, if I find a oneway=yes tag on a waterway, I'd consider this waterway beeing only allowed to boats in the direction of the flow (which might really be an extremly rare situation beside maybe some rare canals), and most likely a mapper's mistake.

The need to record the fact that the river's flow is unknown by the armchair mapper still remains. I guess a fixme=unknown flow direction could do the work. sletuffe (talk) 16:42, 10 November 2014 (UTC)

Rivers near their source

I have been tracing rivers from NPE lately and followed them back to close to their source. However, I am not clear on whether I should really be tagging them as streams once they get pretty thin. Often the NPE continues to mark them as "River Clun", etc. Should I be tagging those thin stretches near the source as streams, but keep the "River Clun" name tag, or just stick to river for the whole length? --Davespod 09:34, 30 July 2009 (UTC)

When they disappear into a cave

• tag the end-node of the way as waterway= {soakhole|sinkhole|karst|dolite} ?

This is the end node of a stream where it disappears into a hole/cave, as you might find in limestone country. Presumably it pops back out somewhere else as a spring. Possible aka's: "soakhole", "sinkhole", "dolite", or "karst". Sinkholes (with or without water flowing into them) can be quite big, so can be both areas and nodes. --Hamish

Why not use natural=cave_entrance? In combination with waterway=stream(e.G.) and tunnel=yes the objects could be described pretty exact imo. No need to invent too specific tags. -- Malenki 12:05, 25 April 2010 (UTC)

PS: I imply you mean it's the end of the waterway on layer=0, continuing on layer=-1, not really the end of the waterway at all.

this looks good myfanwy 01:32, 23 April 2010 (UTC)

Uploaded as waterway=soakhole for the LINZ bulk import, and will merge those nodes into the river ways once the rivers are uploaded. (we have no info about where the streams go underground, so not bothering with layer=-1) --Hamish 00:20, 27 December 2010 (UTC)

River Confluence

I've been thinking about how to make specific reaches of rivers searchable. For example, in older paleontological literature the position of a fossil locality is sometimes given in relation to a river confluence. For someone unfamiliar with the region, it would be useful to be able to search on this type of relationship.
Maybe some combination of these tags would work?
confluence=river a name;river b name
name=confluence of river a and river b
waterway=confluence

--Mattbk16:25, 21 September 2011 (BST)

More detailed classification

The current classification between stream and river is not very satisfactory. How can we improve it, drawing on established practice elsewhere

https://riverrestoration.wikispaces.com/Stream+classification+techniques

---

Distance

I don't agree including it into the list of useful combinations, it would be much better used in Relation:waterway. In fact it is documented to be used in that relation. The use with waterway=river is inconsistent with the description in Key:distance, needles duplication of information and prone to confusion and errors. What happens if some segments are missing the distance? What happens if due to some typo, confusion of a mapper or national prides the distance of some segments of a river differ for some segments? Total waste of effort. RicoZ (talk) 14:52, 10 August 2017 (UTC)

You're saying that if you want to tag distance, you always must use relation. While relation is in general great for any bigger object, there can be some smaller objects which don't need it. The problems you are concerned about are the same as with any other tag, including name - that's why we use relations for complex objects, yet it doesn't mean that we should always use relations to avoid every possible segment error. Kocio (talk) 15:03, 10 August 2017 (UTC)

Yes, we have enough problems with "name", both wrong spelling and regional variations - and I think that one is enough. Imagine the confusion if someone tags half a river with distance=653 and suddenly some local geographic body decides oh no - it is 649. Btw isn't the waterway relation perfect for you? Many bigger rivers have it and I would rather add waterway relations for other big rivers than tag all of their segments with distance. RicoZ (talk) 15:51, 10 August 2017 (UTC)

Indeed, most of the biggest rivers in the world I've checked lately are tagged with relation. Still they have tags added for segments (names in different languages, Wikipedia/Wikidata entries, etc.), which needs some cleaning (moving it carefully to relations). What do you think about moving relation:waterway info from "See also" section to the definition section, to make people aware of using relations whenever possible and avoid such problems? --Kocio (talk) 16:06, 10 August 2017 (UTC)

I would certainly mention that if such data is added it should go preferentially to the waterway relation wherever it exists - with the possible exception of local names valid only for certain segments. The waterway relation itself has been criticized as unnecessary but I guess it is now well established so it could be moved up.. mention in the overview that it is used for "important" rivers and give it a short overview somewhere else?RicoZ (talk) 11:39, 11 August 2017 (UTC)

OK, feel free to improve my proposition. Last sentence in the definition section could go like:

If the river is drawn with more segments, use relation:waterway with common values (including names in different languages, Wikipedia/Wikidata entries, distance etc.) to avoid data fragmentation and inconsistencies.

and the subsection after "River area" called "Using relations":

When the river is longer, it's good to join its segments (ways) into relation. Like for other complex objects, it reduces the number of data duplication and helps keep them synchronized. Use relation:waterway, where all the common values like names in different languages, Wikipedia/Wikidata entries, known distance=*, destination etc. can be stored. Please remember to remove duplicated values from the segments (including waterway=river tag), if they are the same for the whole relation. Segments should be tagged only with values that are specific to them. For example width=* value may belong here, because width of the river usually changes a lot from its source to the mouth.

--Kocio (talk) 14:09, 11 August 2017 (UTC)

looks good. I would reorder the intro piece - the potential problem I see is that many smaller rivers frequently consist of very many segments as they go through culverts and some mapper might think he is supposed to make waterway relations for those. I would think this should happen only for rivers either of some significance or having multiple attributes that make it worthwhile.

For rivers drawn with more segments sharing multiple attributes (like names in different languages, Wikipedia/Wikidata entries, distance etc) a relation:waterway should be used to avoid data fragmentation and inconsistencies.

While at it, we should also look at the various attributes listed in Tag:waterway=river#How_to_map and see if we can make any recommendations which ones are better on the relation (if used) and which ones belong to the particular segments. RicoZ (talk) 10:17, 12 August 2017 (UTC)

Thanks for your comments! I'm currently working on various aspects of default map style on medium and low zoom levels. Improving rivers tagging is just a side job related to this activity, so I'm not focused on it enough to review and propose myself. However if you want to improve some other things about rivers and if you would give propositions, I'm ready to discuss it. --Kocio (talk) 00:43, 13 August 2017 (UTC)

Shouldn't we use length=* for rivers rather than distance=*? Or perhaps this should be calculated from the geometry of the constituent ways, rather than being estimated by mappers or imported from wikipedia. --Jeisenbe (talk) 15:04, 6 July 2019 (UTC)

Destination

destination is used 17451 times on waterways, e.g. into which other river the first one flows. This is not reflected on this page. Should it?--Polarbear w (talk) 11:38, 28 February 2018 (UTC)

Something used 10k+ plus times always can be described (though not always as a good idea, sometimes it is a popular tagging mistake or result of poorly done import). In such case there is no need to ask. Mateusz Konieczny (talk) 13:02, 28 February 2018 (UTC)

Thanks for encouraging. Though, for the reasons you mention in brackets, I prefer to discuss first, as somebody might be aware of them, or know where the tagging had been discussed. --Polarbear w (talk) 13:47, 28 February 2018 (UTC)

It doesn't seem very helpful. The geometry clearly shows the destination of a river if it flows into another river or a lake, and shares a node. If the river ends at the coastline, the destination could be an ocean or sea, but again this information is available from the geometry with some work. --Jeisenbe (talk) 15:06, 6 July 2019 (UTC)

Implies access=no and boat=yes?

The current page (in the ValueDescription box) has listed access=no and boat=yes as "implied" tags since 2008. Is this correct? While I can see how it's reasonable to assume that most rivers allow access to small boats such a canoes and kayaks, I don't understand how "access=no" fits in. I plan to remove "access=no" from the list the implied features. --Jeisenbe (talk) 14:50, 6 July 2019 (UTC)

Maybe somebody thought that "routing pedestrian across this ways is a poor idea" should be specified explicitly? I agree that it amkes no sense to list it here, you may as well as it as implied value of power=minor_line. Mateusz Konieczny (talk) 14:59, 6 July 2019 (UTC)

Sounds reasonable ;) --katpatuka (talk) 05:23, 7 July 2019 (UTC)

Waterway going through a lake

There is some disagreement about how to map a river that enters a lake and then exits the lake. The distance between the entry and exit points might be only a few meters or in some cases, several kilometers. Some mappers draw the waterway=river through the lake while others, including myself, don't do this. Some mappers only draw the waterway through the lake/pond, if the river is of a certain size. My practice is to draw the waterway and terminate it on the way describing the lake and then start drawing the exit river from the lake outline at the other end. This prevents the name of the river from showing up in the middle of the lake with the downside being that it breaks the river into sections that aren't connected.

I have also seen imports from the NHD in Alaska that consist of hundreds of short sections and if there are tiny feeder streams that lead to a lake, they are extended into the lake to join the major stream somewhere inside the lake shores. I don't like the clutter that practice produces. In fact, I don't much like the NHD imports but like Tiger data for streets, they're better than nothing. Sometimes I remove those "extra" ways reasoning that they are small contributors and aren't usually navigable or even visible as currents in the lake.

So, what is the best way to handle these different practices? Even if we can't decide that question, I believe those practices should at least be mentioned on the Wiki pages for both waterway=river and water=lake/pond.

Opinions? AlaskaDave (talk) 19:34, 20 October 2021 (UTC)

Good point! I always map rivers connected, that is from entrance in a lake to exit using a tunneled river under dams. The only annoying thing is that the river name might be rendered in the middle of the lake instead of the lake or reservoir name, right? One needs to ask the render cracks if there could be a way to suppress the rendering of the river name on a lake. --katpatuka (talk) 04:49, 21 October 2021 (UTC)

I map depending on whether river is considered as going through the lake, or being interrupted by lake. Second is typically combined with river changing name. Note also that if river is considered as going though lake, but that section of water not being considered as named after river - noname=yes waterway=river is an option Mateusz Konieczny (talk) 10:12, 21 October 2021 (UTC)

Definition of Ditch

Ditches are not for irrigation, and the definition should be changed: "this usage contradicts the original definition of waterway=ditch as a waterway used to remove excess water" (see definition on https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dditch).