Talk:Key:waterway

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Key:waterway here:

Streams

More information now at Tag:waterway=stream

Currently, the renderers seem to render rivers larger than canals, making them about the right size for mid sized river. Some smaller ones (which might be called "streams" or similar) come out too large.

Really small waterways

I think a river of 3 meters width is not the same as a 50cm wide one. They should be tagged separately IMHO. --Bkr 15:38, 6 June 2008 (UTC)

Well the definition which has been written for a long time on Tag:waterway=stream is "Too small to be classed as a river. Maybe you can jump over it". This <3 metre rule is maybe a bit more solid, except that we have to remember that rivers/streams vary in width. There's wide pools and narrow channels. What's more the flow varies with weather conditions / time of year / rainfall / snowmelt / drought (can dry up altogether). ...so maybe we should stick with "Maybe you can jump over it" ...or define it terms of flow in cubic metres per second! In fact I propose we drop the mention of 3 metres. It's misleading us into thinking we can be accurate in that way.
You're suggesting a third category? Rivers -> Streams -> Diddly little trickles? I don't think that is necessary. The idea of 'streams' is that they are very small rivers. Too small to be classed as a river. So that should satisfy what you are describing. I imagine 3 metres seems too wide as a cut off point if you're picturing a gushing 3m wide torrent... depends how fast it's flowing over that 3 metre width.
Just noticed that Talk:Tag:waterway=stream has a lot on this topic too
-- Harry Wood 08:33, 7 June 2008 (UTC)
To show that there are big differences between "stream"s and the very small variants, I just created Key:waterway/Narrow_variants. Alv 08:33, 12 May 2010 (UTC)

Mapping waterways

How does one maps a river, lake, canal or other waterways? You can driver over roads and even take the train to map railways. Rivers are different. I could take my kayak and try to map it but the river doesn't has the same width on all places and some smaller waterways are simply to small to take a kayak. I could walk around a lake but would the GPS reception be precise enough when I have to duck under trees, walk around stones, etc.? Last problem, some parts are simply not reachable, the river in my town is enclosed by buildings or it runs through some private area... Cimm 6 Nov 2006

Coastline(ie the boundary between the land and sea, and river estuaries) data can be imported into OSM using the PGS coastline scripts. For other waterways, lakes rivers etc, I'd use JOSM and the Landsat plugin. This shows a satellite image of the area you are working on, and you can draw nodes over the top, wherever you need them. There may be a shift of up to 100m between the real position and the position shown by the Landsat photo, if there is an identifiable feature in the photo which can also be mapped by GPS then this will show the size and direction shift in the Landsat image, and all nodes which you have drawn can be moved in JOSM to compensate for the shift. Dmgroom 16:21, 6 November 2006 (UTC)

Waterway as area

Proposed_features/Large_rivers only mentions rivers. Near my area, someone traced the outline of a canal (presumable using Yahoo! Imagery). This is currently tagged as natural=water in order to render properly, but this is obviously incorrect. Replacing this canal with a linear way is a possibility, but I'd hate the person's effort to go to waste. Is there a possibility that waterway=canal could also apply to an area? --Gyrbo 19:02, 13 January 2008 (UTC)

The area should be tagged as natural=water, water=canal (see: http://wiki.openstreetmap.org/wiki/Key:water#Possible_values). --Dru1138 (talk) 18:20, 20 November 2014 (UTC)

Aqueducts

Having a waterway=aqueduct tag doesn't allow you to specify what sort of waterway the aqueduct is carrying. Wouldn't something more akin to the bridge tag be better? (i.e. waterway=canal, aqueduct=yes), or should bridge=yes be used instead?

In fact, you should use bridge=aqueduct -- I've updated the article. Robx 17:26, 12 June 2008 (UTC)

tunnel

what about a small stream running under a big motorway oder crossing a village in a canal (or sewer?) but under the ground - how to tag these? -- Schusch 22:41, 15 July 2008 (UTC)

Similar to bridge=aqueduct how about tunnel=culvert? http://en.wikipedia.org/wiki/Culvert --EliotB 06:11, 18 January 2009 (UTC)
Isn't a tunneled waterway not by definition a culvert? So would tunnel=yes as is done now by most people not be sufficient? --Eimai 13:31, 18 January 2009 (UTC)

Intermittent and ephemeral streams

Many maps display intermittent and ephemeral streams different from "regular" (called perennial) streams (see wikipedia:Stream#Intermittent_and_ephemeral_streams for a definition). I would like to propose an additional tag to the waterway=* called intermittent=yes (which would include ephemeral streams). Any objections? --Colin Marquardt 15:37, 18 September 2008 (UTC)

Safety equipment?

Is there any way to tag safety equipment such as life-belts next to canals, rivers, docks etc? Bruce mcadam 14:34, 28 January 2009 (UTC)

Some use amenity=life_ring. Alv 07:22, 30 April 2010 (UTC)

Areas

On Seamaps you find many areas. (Roadsteads,military area, restricted area, nature reserve...). I think we need a tagging-schema for this.

I found an interesting proposal for such special issues: Proposed_features/marine-tagging

and i started a discussion about areas: Talk:Proposed_features/marine-tagging#Areas

--Klabattermann 22:23, 30 July 2009 (UTC)

Former rivers?

How should a river that no longer exists be mapped? In this specific area, canals have been built to modify the flow of water, and the former river alignment (in the middle of a swamp) no longer carries flowing water. --NE2 17:34, 20 January 2010 (UTC)

Arbitrary Labels?

I feel there is a need for a general label for ad-hoc water features, like place=locality. Such features are generally very local names for sections, inlets, bends, moorings and the like. Place=locality will do, but it is usually rendered in a land style (black text) rather than a water style (water-blue text). Thoughts?

Really narrow canals?

Hello. I started mapping a few days ago some acequias, which are man-made waterways used for transportation of irrigation water, common in Spain and the Americas. The problem is that I've been tagging them as waterway=canal but, acequias are sometimes no more than a few centimetres wide, being the widest I know about one metre wide. The canal rendering is quite big for those purposes, so how do I get a narrower rendering or, otherwise, a more adequate tag for these acequias? --Schumi4ever 22:54, 26 December 2010 (UTC)

PS: Compare the size of the acequia to the people beside it: [1]

Ideally you'd use tags that describe its purpose, like boat=no and something for irrigation. Maybe waterway=drain is good enough for now? --NE2 02:06, 27 December 2010 (UTC)

Why that 12 m remark for riverbanks?

"For larger rivers (defined as more than 12m across) see waterway=riverbank." Defined by whom? Riverbank ways make sense when the banks are irregularly shaped, it doesn't matter how wide the river is. --Tordanik 15:27, 6 January 2011 (UTC)

the edit was by User:Trs998 back in 2008, so it survived for a while without anyone complaining (and unnoticed by me)
Such measurement specs are fraught with problems. There were some debates about how to distinguish "stream" from "river". Eventually somebody came up with "Maybe you can just jump over it", which remarkably seemed to settle the argument for a while at least. I see somebody's written something far more pedantic on there now.
So we can have similar arguments about how wide a river needs to be before it gets a riverbank. I'm not sure where 12m definition comes from. Mailing list somewhere probably. I can immediately think of all sorts of problems with it, but then again... it's probably as good as any other idea.
We should definitely add a section to Tag:waterway=riverbank going into the details about consensus (or lack thereof) about making this distinction. This discussion should then be moved to that page, and perhaps we might decide to remove such details from the tag summary where it currently is.
-- Harry Wood 17:29, 6 January 2011 (UTC)
It clearly is more appropriate to have such a section on Tag:waterway=riverbank, so I agree with your suggestion. As far as the definition itself is concerned, my personal opinion is that riverbank := a river where someone bothered to draw the actual banks, rather than just the centerline. --Tordanik 00:20, 8 January 2011 (UTC)
I think this definition could also vary by country and custom. In New Zealand, the concepts of the "Queen's Chain" and "paper roads" means that waterways wider than 3 metres were often designated as legal roads in early land surveys. More recently local councils may own the river banks for flood protection and other reasons. This means there is often a legal public access right within a 20 metre (or 1 chain) marginal strip or esplanade of a river or the coast. Because many of these marginal strips are not marked, showing where the river banks are can be important, even in the case of smaller streams. - Huttite (talk) 21:30, 3 December 2016 (UTC)

Waterway continuity

We have big discussion on czech talk about waterway continuity. I think, we need continual tree for many purposes. So if have river with some lake for example, then river continue in lake with aprox way (there are only few lakes where we know exacly way - ie from historic materials). Without this, we have nice pictures maybe, but no map - no nav, hard to say river length ... User:Jezevec 13:52, 7 March 2011

How do you define the "length" of a river across a lake? If you put the way in the middle (because there are probably tributaries on both sides), then you're probably wrong anyway. Unless there are defined "lanes" for traffic, and do we really want to get into mapping that? Seems like the only nav solution is raw GPS across a free-movement area, similar to a plaza (highway=pedestrian area=yes), which admittedly is rarely handled correctly either. StephenTX (talk) 15:59, 20 November 2016 (UTC)

Water divide or watershed

Which one of both (or is there better expression) should we use? I just start with waterway=water_divide Greetings, -- Schusch 09:23, 11 January 2012 (UTC)

Watershed is unfortunately ambiguous (it can refer to the divide or the basin). I used natural=divide on the Continental Divide in Colorado, but I have no particular attachment to this. I do think it's not necessarily a good idea to use a waterway value. --NE2 10:34, 11 January 2012 (UTC)
well ok ... here is the example. It is a waterway which splits up, see the article. And there exist a lot of these water divides for smaller waterbodies. -- Schusch 11:18, 11 January 2012 (UTC)
What is it you want to map? If it is the streams/rivers then simply map their ways. If it is the land that divids the waterways then don't use waterway tags! Use land tags - natural=ridge for example. Warin61 (talk) 20:45, 17 January 2016 (UTC)

Strait

'A narrow channel of water between two larger bodies of water'. Does this belong here or natural=* ?

Not my understanding of 'strait', which is ditto but between two larger bodies of land (and afaik in UK English usage, only at sea, never for inland use).
I'd favour natural=* and add a waterway=fairway through it if there is one. Eteb3 (talk) 15:02, 31 August 2019 (UTC)

Ditch

I think it is odd that the waterway is a ditch. Having ditch as a property of the riverbank/watershore would be more logical, it would also fit better when a stream goes through a ditch part of its way. RicoZ (talk) 16:48, 30 November 2013 (UTC)

Would be useful to have a drinkable=yes|no|emergency attribute

When crossing a stream or river on a hiking trail, it would be really useful to have some indication of whether or not the water is safe to drink.

I'd propose a "drinkable" attribute, taking one of the following values: yes = safe to drink in large amounts. emergency = not the cleanest water, but unlikely to do serious harm. Better than nothing in an emergency. no = avoid drinking even in an emergency.

the only I would agree to is "drinkable=no" when it is a clear case.
Better approach to your case would be to map likely/possible upstream pollutants and combine that with "water_characteristic" (part of hot_spring proposal) to get an assessment of possible problems and dangers. RicoZ (talk) 11:29, 11 April 2014 (UTC)

Stream Order

I think an optional order tag would be a good idea, see http://geography.about.com/od/physicalgeography/a/streamorder.htm. Josh_G 17:11 31 October 2014

The linked article is very vague, how do I tell that a river is stream_order=7? Is it the plain water flow in cbm, some authority saying so, relative importance? RicoZ (talk) 10:14, 31 October 2014 (UTC)
http://usgs-mrs.cr.usgs.gov/NHDHelp/WebHelp/NHD_Help/Introduction_to_the_NHD/Feature_Attribution/Stream_Order.htm is a better article - but I think that there would be a better way of tagging the streams I had in mind. Josh_G ((talk) 10:34, 6 November 2014
This kind of stream order can be derived from existing data pretty easily so there is no reason to do it manually. Also this stream order is likely to change very often if someone would map an additional creek upstream or even move one confluence of streams, highly unpractical for mapping. RicoZ (talk) 11:00, 6 November 2014 (UTC)

I have started discussion about it here: https://lists.openstreetmap.org/pipermail/tagging/2017-August/032986.html --Kocio (talk) 15:34, 6 August 2017 (UTC)

Boatyards

The present wiki says these are on land only. If that is so they are not part of a water way and should not use waterway tags.

Possible tags are landuse=industrial, industrial=boatyard or industrial=shipyard. Warin61 (talk) 20:48, 17 January 2016 (UTC)

riffle=yes

According to https://en.wikipedia.org/wiki/Riffle : A riffle is a shallow section of a stream or river with rapid current and a surface broken by gravel, rubble or boulders. At least in relativly plain areas in streams and ditches these places are easy to find and clearly defined. I was searching for a tag - and didn't find one. Here I don't want to tag something which has to do with rafting or other sports but with nature. I used to tag these places with rapid=yes - but according to the whitewater sports people this is "wrong". I'm not at all interested in difficulties, grades etc. Most of the ditches are even not appropriate for boats. So I propose tagging these nodes (or short ways) with riffle=yes. (if somebody wants to make this a proposal, you are welcome) -- Schusch (talk) 07:37, 31 March 2016 (UTC)

I've used natural=shoal in one place as that is consistent with nautical chart use at sea (and the purpose of mentioning the riffle is to aid navigation? eteb3 (talk) 05:57, 27 May 2021 (UTC)

Use of the oneway tag on waterway=*

In a revert of an edit I made the other day (italics what was removed)

By definition, a waterway is assumed to have a direction of flow , and therefore oneway=yes is implicit for waterways. The direction of the way should be downstream (from the waterway's source to its mouth).

...the following explanation was given in the history change log. "The oneway key does not refer to water flow direction."

I'm not saying that this isn't true, but what I am saying is this: A documented use for what oneway=* on a waterway does mean isn't documented anywhere on the Wiki. Saying "The oneway key does not refer to water flow direction." implies that it does refer to something, so I ask that what that something is be documented so that

  • it's understood by editors when it's encountered, and almost as important,
  • so that data consumers (osmand+, OSRM, whatever others) know how to interpret a waterway with a oneway= tag that may be contrary to the direction of flow.

Here's a count of the union of waterway=* and oneway=*.

  • oneway=-1 (375)
  • oneway=1 (3596)
  • oneway=alternate (7)
  • oneway=interval (2)
  • oneway=no (222)
  • oneway=reversible (1)
  • oneway=yes (23454)

(After doing the exercise of looking through tag usage, I think I get that it's probably referring to allowed navigation of watercraft, ships, etc., but again, the point is, it's not documented on this page, so it's only a guess. Even if that's so, then it should be documented, and I would guess that the assumed default should be oneway=no, since it's typically not "the rule" to enforce traffic flow on a waterway in this manner, beyond 'see and avoid'.)

Generalizing waterways to refer to more than the direction of flow to a waterway, and instead to 'approved navigation channels' might require a new relation or new way of describing these things in the future. I don't know how compatible the mapping purpose of "waterways to watersheds" and 'navigation channels' will be in using the same ways and keys for both, but that's a different topic. Skybunny (talk) 15:00, 1 December 2017 (UTC)

I knew there was a reason I put that into the article. If there's a belief out there that oneway=* 'means something' in the context of a waterway, then the JOSM project needs to be told, because as far as they're concerned, 'oneway' on a way without a 'highway', 'railway', or 'aerialway' tag is warned about in the verification step, implying it should be removed or at the very least is nonstandard. Since it isn't described here, I very much understand their rationale. Skybunny (talk) 01:06, 2 December 2017 (UTC)
My interpretation of oneway on waterways would indeed be that it refers to traffic, and I believe that this has been the overall outcome of discussions on the topic in the past. However, I didn't manage to dig up any of those hazily remembered discussions with an internet search, so I didn't want to assert this meaning without proof. What I am reasonably certain about, though, is that oneway shouldn't be used for the flow direction, which is why I phrased the edit comment that way. (There's the key flow_direction which would fit, although only the value flow_direction=both is approved at the moment – there's no value intended to explicitly affirm the default.) --19:15, 4 December 2017 (UTC)

Debris screens

I'm using waterway=debris_screen for debris screens on waterways such as Figure 8.25 and Figure 8.26 on [2]. These are commonplace in the United Kingdom at entrances to culverts to prevent bits of debris blocking them up and causing local flooding. The name "debris screen" is the name used by the Environment Agency on information boards and in press releases. --Lakedistrict (talk) 17:28, 3 April 2018 (UTC)

Mapping them is a good idea, I agree with this.
It would be great to move all those water management features to another key than waterway=*. It may be hard to achieve, but mapping dams as waterway=dam is not very consistent, as concrete and man_made structures. Then, would you accept to use other key than waterway? Fanfouer (talk) 18:58, 3 April 2018 (UTC)
I tend to agree with you: watermanagement=* would be good, and reserve waterway=* for a true 'way' - ie, something you (or the water) can pass along. So the water travels down the waterway, but it may pass over/through/under features of watermanagement. Please also see below under 'Outfalls' for a link to a suggestion by TimCouwelier for a tag category waterway=flow_control + flow_control=*. I disagree with him, for reasons stated, but it seems to touch on your issue. --Eteb3 (talk) 14:16, 31 August 2019 (UTC)

waterway=riverbank vs natural=water + water=river

Please see the discussion in the ml. For whatever reason, the "new" and approved scheme is increasingly strongly lagging behind the "legacy" method. It has been suggested as the "preferred" scheme for long enough and is meanwhile losing taginfo percentage. I believe it makes no sense to try to push it as the suggested scheme here. RicoZ (talk) 20:45, 7 September 2018 (UTC)

Outfalls/discharge points

I'd like to propose waterway=outfall and/or waterway=discharge_point for the many examples of features like this one and this one on UK rivers. (I appreciate one also has a debris screen, but I think the outfall itself is more significant.) TimCouwelier has here suggested waterway=flow_control + flow_control=*, where * can be: flap_valve; orifice; sluice_gate; vortex - and his suggestion would seem to fit these cases. I'll restate (some of) my thinking expressed there, that imo this views the feature too much from the engineering/purpose point of view, and not enough from what is visible on-the-ground. It also adds needless complexity. --Eteb3 (talk) 14:08, 31 August 2019 (UTC) EDIT: I see a related issue above at 'Debris screens' Eteb3 (talk)

I see one important point to have in mind: we should avoid cluttering waterway=* with numerous punctual features. waterway=flow_control or waterway=valve would have benefits regarding this particular point.
As discussed here, waterway=valve would make valve=* usable for sluice gates and any other flow control devices seen on waterways.
I agree on the need to map what is seen on ground. Should we focus on specific equipment seen on pipes/drains outlet instead of outlet themselves? Fanfouer (talk) 14:26, 31 August 2019 (UTC)
Your point about 'punctual features' is very well taken, especially as I'm new to all this. At the risk of forking the discussion, what do you think of my response to your suggestion above at #Debris screens?
I can see the benefit of a subkey waterway=flow_control (or waterway=valve) to avoid the cluttering you mention. However, my experience as a new mapper is that two layers of tags (A=B + B=C) is a serious deterrent - it more than doubles the documentation needed, and the tagging system is already mindblowingly complex. I also find it unintuitive: the ordinary person sees a 'sluice', not 'a type of valve'.
Moreover a 'sluice' is indeed a type of controlled valve but an 'outfall' is so only sometimes - so flow_control=* would only sometimes be suitable for an outfall. Complicated!
Sluices and outfalls (and pumping stations, debris barriers, etc) all seem to me to be species of the the genus 'concrete and steel structures with water passing through them', ie, watermanagement=* . Maybe even just man_made=* would serve??
To your point re specific equipment, I agree, as long as it is optional detail. This *is* the place for a subcategory, imo: we could have a tag outfall=pipe_end, =flap_valve, =walled; etc.
What do you think? Eteb3 (talk) 16:20, 31 August 2019 (UTC)
Thank you for this elaborated answer. Despite A=B + B=C sounds more complex than other possibilities, it's the base of sane semantic modelisation. This is more desirable because it allows to give better links between concepts. From my experience of both tagging builder and contributor, it's the approach I find the most convenient. It draws a kind of path between a global idea (water management) and the particular device you describe (valves, gates...). See running example node 4608675737
I'd be in favour of water_management=* to define man made (always) devices that modify the flow of water in a (sometimes) man made waterway. water_management=valve + valve=gate could be used for sluice gates (incompatible with pipeline=valve to distinguish open-flow waterways with pipe-flow pipelines). Outfall would come beside valves with water_management=outfall (are they proper water management equipment?) as a valve can't be a proper outfall : they'll require a different node each. This valid if and only if outfalls are always man made. Outfalls may indeed be subcategorized with outfall=* or other related term.
I must say it's a medium term work that would require formal proposals. Even if talks can sometimes be tough and time consuming, we're here to help and will certainly produce valuable things together :) Fanfouer (talk) 12:53, 1 September 2019 (UTC)

Let me be the first to admit my take was ENTIRELY from an engineering point of view. Reasoning behind such logic: who else then someone in a such field would actually do something with the data? waterway = outfall or waterway = discharge_point : those indicate basically that that's where you data stops, and water 'runs out of the system at this point'. We don't really have those here. As for waterway = flow_control + flow_control = * : it's to avoid cluttering the 'waterway = *' options. You're looking a a POINT on a waterway. What's happening there is waterflow being managed somehow, leading me to waterway = flow_control, which is fairly straightforward even without in-depth knowledge of of the different types. Optionally, should you know which type of flow_control we're dealing with, you can specify it with flow_control = *. TimCouwelier (talk) 09:47, 4 September 2019 (UTC)

I see! My perspective on this is as a canoeist, and we would use this data for navigation. Down on the river there are often few landmarks visible, so overhead lines, side channels and outfalls are useful indicators of where we are. We don't mind at all that these things do X or Y, beyond being able to give them a name we all understand. The outfalls we're interested in, then, are those which empty into the river we're paddling. (We could almost say that's where the data begins, rather than where it stops, since we're looking at the in-coming waterway from the other end :-)
Could I ask for some clarification on what counts as the 'clutter' that you and Fanfouer are concerned about? Is the concern that the key waterway=* is acquiring tags that aren't really 'ways' at all (Fanfouer's 'punctual' features), or is it more simply that it's getting too many values, period? Eteb3 (talk) 17:50, 6 September 2019 (UTC)
To me, it's more about consistency than the amount of values. Things like waterway=fuel are just meaningless and should be moved to another tag, because it's not about waterway business Fanfouer (talk) 20:17, 10 September 2019 (UTC)
I agree with the original post that it would be best to have tags for specific features. The end of a pipe that's discharging water into a river isn't a really a waterway=flow_control or waterway=valve, at least to a non-expert like me. There's not a real problem with adding more tags to waterway=*; tags and keys are basically free. There are already 37 documented values of waterway=* and only a dozen are actual watercourses, and there are 61 values of waterway=* that are used over 100 times. But it's also possible to use the key man_made=* if that's clearer. --Jeisenbe (talk) 02:52, 13 September 2019 (UTC)

Waterway without specific destination

There cases (specially in dry areas) in which there are seasonal streams which are not ending in any specific destinations. They get get dry at some point or get absorbed by earth. Other occasion would be waterways made by men for taking water into farms. How such waterways should be drawn? Should the warning regarding the waterway not ending to another waterway? Ahangarha (talk) 19:25, 22 June 2020 (UTC)

https://wiki.openstreetmap.org/wiki/Key:seasonal may be an option for your first case. See notes on that page regarding 'intermittent', also. Your second case has been covered elsewhere in the context of the 'acequias' of Spain, I believe, but I'm afraid can't tell you where. (Acequias are man-made watercourses, sometimes just 20cm across or so, for bringing water from natural flowing water to agricultural land.) Here they are calling such a waterway a 'ditch': https://www.openstreetmap.org/way/319285981#map=17/42.13428/-0.45721 eteb3 (talk) 20:52, 22 June 2020 (UTC)
Thanks. I already use `intermittent` for such waterways but based on being natural or man-made, I was using stream or canal. I think ditch is more appropriate for man-made waterways in this case. I will try to find what you referenced here as acequias. But still this question remains: is it necessary for a waterway to end into some other waterway or lake of something like this? Should I ignore validation water? Ahangarha (talk) 07:58, 23 June 2020 (UTC)
It is not necessary for a waterway to end in a lake or waterway. Rivers can disappear into sinkholes in areas with limestone, and they can disappear into sandy or rocky areas on deserts. If there is an intermittent lake, it should be mapped, but this is not always the case in deserts or areas with very porous rock. --Jeisenbe (talk) 20:47, 23 June 2020 (UTC)
For sinkholes, see natural=sinkhole and sinkhole=* Fanfouer (talk) 22:38, 23 June 2020 (UTC)

Addition of spillway

I suggest that we could add waterway=spillway to design the structure that allows the evacuation of flood waters (https://en.wikipedia.org/wiki/Spillway). Some can be weirs, those should remain tagged waterway=weir, but concerning those with let's say, sluice gates are distinct from weirs. waterway=canal + usage=spillway does not represent the feature at all as it concerns the spillway canal, not the building itself. --Yann Tombmyst Tremblay (talk) 22:23, 26 May 2021 (UTC)

Agree would be useful. Presumably with intermittent=yes eteb3 (talk) 05:55, 27 May 2021 (UTC)

This proposal seems interesting: https://wiki.openstreetmap.org/wiki/Proposed_features/sluice_gate --Yann Tombmyst Tremblay (talk) 12:35, 27 May 2021 (UTC)

waterway=yes

Why is it not accepted to tag a waterway just as waterway=yes? I was discussing with other geography students in University of Turku that often a waterway / part of drainage network can't be further categorized with whatever imagery or other data is available. --Paavobave (talk) 16:16, 18 November 2021 (UTC)

To me that would be ok if and only if waterway=* refer to water ways only and it's not its current meaning due to dam, fuel and so on. With current lack of consistence we can't be sure is a water way or a peripheral feature. Fanfouer (talk) 15:07, 20 November 2021 (UTC)

waterway or waterbody?

OSM's "waterway" is not restricted by navigability, as in the dictionary and Wikipedia definition, so eventually the tag should be renamed to waterbody. Fgnievinski (talk) 03:20, 23 January 2022 (UTC)

waterway=* should regard first of all ways that carry water from one point to another. Even in waterbodies, water comes in at one point and get out elsewhere. Waterbodies are described with natural=water + water=*. I don't agree to mix them in a single key. Fanfouer (talk) 08:11, 24 January 2022 (UTC)

Change Docks to use the natural/water schema?

As enclosed water features "has largely been replaced by natural=water + water=river", what, if any, are the reasons for maintaining 'dock' as a waterway? --DaveF63 (talk) 15:12, 30 March 2022 (UTC)

Any other question couldn't be more accurate! Fanfouer (talk) 19:30, 30 March 2022 (UTC)
waterway=dock is used for dock=floating and dock=drydock in Tag:waterway=dock#How_to_Map. intermittent=yes alone won't describe this well. Some other tag is needed for controlled water level.
natural=water is mostly for "inland" water, which needs salt=yes and tidal=yes added for salinity and interface with sea in coastal docks. (I think?)
This and waterway=fish_pass are related to their structure. Ideally there should be tagging for this as well.
--- Kovposch (talk) 11:20, 31 March 2022 (UTC)
The dock tag can still be used on the natural/water schema. The natural/water schema doesn't assume/imply location. I concur with your third point, but that's another discussion on another day. --DaveF63 (talk) 17:18, 31 March 2022 (UTC)

Are boatyards even water?

Boatyards appear to be mostly areas of dry land with buildings for storage & maintenance. Wouldn't a landuse tag be more appropriate? They should be considered similar in concept to marinas, and rendered equivalently to allow any water areas to display (ie a boundary render with no infill --DaveF63 (talk) 15:12, 30 March 2022 (UTC)

Not limited to Key:waterway#Facilities, you will have to ask the same for Key:waterway#Barriers_on_waterways and Key:waterway#Other_features_on_waterways. waterway=fairway and waterway=turning_point themselves are not the water either, despite being on water.
To me, using waterway=* for water-related facilities and structures is fine. This is consistent with other *way=*.
--- Kovposch (talk) 11:10, 31 March 2022 (UTC)
Despite it's consistent with history, it's not really accurate. We already spent some time to restrict some *way features to flows ways only (riverbanks, reservoirs...). That was the point of pipeline=marker deprecation for instance.
It currently forces consumers to look for a defined set of values for anywhere something flows (and force them to complete it each time a new value is added or an existing is refined) instead of somethingway=* and that sounds bad. Fanfouer (talk) 17:33, 31 March 2022 (UTC)
Please keep discussion relevant to the subject. In this instance, Boatyards as *areas*, not linear ways. --DaveF63 (talk) 17:50, 31 March 2022 (UTC)

waterway:type redirect

I've created a redirect to this article for the waterway:type=* key. From what I can tell, although usage is high, it has only been used in only a couple of imports (Canada and Indonesia) and should not be used. Instead type should be specified using waterway=*. Casey boy (talk) 12:42, 9 April 2022 (UTC)

Taginfo is returning zero. You're redirecting to 'waterway' --DaveF63 (talk) 14:42, 9 April 2022 (UTC)
Sorry, I'm not clear on what you mean. There are ~54k uses of the waterway:type=* key. Rather than create a wiki page for that key, since I don't think usage is widely accepted, I create a redirect to this article - or at least I think I did. Have I missed something? Casey boy (talk) 13:47, 9 April 2022 (UTC)
Aargh! You're correct. I forgot Taginfo doesn't remove whitespaces. --DaveF63 (talk) 14:42, 9 April 2022 (UTC)

Direction uncertain

By definition, a waterway is assumed to have a direction of flow.

Sometimes, especially when using air photos of short waterways in cities, the direction is uncertain. Mention how to deal with such cases. Jidanni (talk) 12:48, 22 June 2023 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:waterway&oldid=2546403"