From OpenStreetMap Wiki
Jump to: navigation, search

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

--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


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)