Proposal talk:Hydropower water supplies

Bad use of waterway key

Resolved: Use brand new waterway=pressurized as to not collide with existing open air waterways Fanfouer (talk) 15:25, 4 March 2018 (UTC)

Please don't use the waterway key for anything that is not strictly free surface waterflow. Especially do not use waterway=drain (or other existing waterway tags) for pressure tubes. This would make life quite difficult for many data users and would unnecessarily blur the meaning of tags used quite consistently in that regard at the moment. --Imagico (talk) 17:34, 2 December 2017 (UTC)

The proposal may be miswritten, but I don't change definitions of existing values. My point is man_made=pipeline is not enough to get an accurate water topology.

waterway=drain is not used for high pressure tubes at all. But, as any confined space where water flows, it can be designed to bear a small pressure or not (pipe flow vs free-space flow). Typically, assuming an underground storm drain is only designed for free-surface flowing is wrong. And I don't see any compatibility issue between waterway=drain, location=underground and tunnel=culvert got waterway=* as useful combination on current wiki.

Furthermore, a tunnel is not a pipeline, then what other values than waterway=drain should be used for pipe-flow water tunnels ? Fanfouer (talk) 10:52, 3 December 2017 (UTC)

The distinction between free surface water flow (German: Freispiegelleitung) and pressure tubes (German: Druckrohrleitung) for covered/tubed water lines is both a commonly well identifiable distinction for mappers and an important distinction in hydraulic engineering. And as said it is an important distinction for data users.

man_made=pipeline + substance=water + usage=penstock seems perfectly sufficient for tagging such pressure tubes. Key:waterway does not specifically mention free surface water flow but with a flow of water from one place to another quite clearly implies free surface water flow.

I get your point about the importance of these features for the global hydrographic system but i think you miss that while some penstocks represent a water path in that systems others don't - like http://www.openstreetmap.org/way/351499334. Because of the widespread abuse of waterway=canal + tunnel=yes using waterway=penstock would indeed be an improvement - but it would not solve the problem of mapping the hydrographic meaning of such pipelines, i.e. if they channel a pre-existing natural waterflow locally into a pressure tube or if they divert water into a completely different flow regime.

The way of mapping that currently is probably best in line with established mapping practice is to include the penstock in the waterway relation. This is usually very clear in meaning.

Something to keep in mind in case of dams - you can argue that the spillway is actually what fulfills the function in the hydrographic system, not the penstock. Of course not all dams have a spillway. --Imagico (talk) 11:35, 3 December 2017 (UTC)

I agree on the need of distinction, but it doesn't require to dedicate a common word as waterway for a single of both.

Not all penstocks are pipelines, a tunnel isn't a pipeline. waterway=penstock nor waterway=drain doesn't strictly imply man_made=pipeline.

I don't get the free flowing implication from with a flow of water from one place to another. Could you elaborate a bit more please?

Importance is a business we can take care about once features are well identified. As you said, water channelization can't be accurately done in OSM and we need values (not keys) to improve this. Anyway, flowing water amount inside a penstock can't be add to OSM since is a variable data.

I'll add a mention to the proposal to add penstocks and feeding tunnels to waterway relations

Regarding dams, it's also in waterway=* key and not in man_made=*. Then it would be nice to add at least a waterway=stream on the spliiway. I allways add water path around dams, like this : https://www.openstreetmap.org/way/543378764 Fanfouer (talk) 14:15, 3 December 2017 (UTC)

Mapping such features, I could not find adequate tags and I think that this proposition is interesting to characterise waterway deviations for power stations. I dont think that anyone would argue that motorways in a tunnel are not free surface circulation. It should be the same for waterway sections that are derived in a tunnel. This is part of the hydrographic system but with particular characteristics to describe. Man_made should be for features who are not part of the hydrographic system. pierzen (talk) 14:23, 3 December 2017 (UTC)

man_made=pipeline does not imply tubing. The tag documentation specifically mentions underground pipelines which in rocky ground usually don't use tubing.

I cannot really prove that Key:waterway implies free surface water flow but it is clear that most mappers consider this implied. Anyway - i don't really mind if you create a tag specifically meant for water transport that is not based on free surface flow with the waterway key. But please don't blur existing tags that are almost exclusively used for free surface flow at the moment (waterway=drain) by adding that they can also be used for other things. This would massively devalue existing data. --Imagico (talk) 14:55, 3 December 2017 (UTC)

Fine, I thought using waterway=drain would ease adoption but I understand this would cause some issues with existing data.

Nevertheless, there are tunnels with free flowing and tunnels designed for pipe flowing. Can I go on with waterway=drain for free flowing and waterway=pipe for pipe flowing? This would be suitable for siphons too.

Regarding man_made=pipeline, given problem is it's not a water specific key, and consumer looking for waterway=* only to get water topology will miss some edges in the graph.Fanfouer (talk) 15:44, 3 December 2017 (UTC)

The waterway class is usually a matter of function and size. A tunneled section of any waterway gets a tunnel=yes. It does not change the waterway type. But if you funnel the water of a stream or drain into a pipe in my book it is not a waterway any more, it is a pipeline.

For data consumers i see no problem for filtering for man_made=pipeline + substance=water in addition to waterways. But as said if you prefer i have no big problem with waterway=penstock or waterway=pipe as long as it is well defined what this is supposed to mean.--Imagico (talk) 16:53, 3 December 2017 (UTC)

I've moved the proposal towards waterway=duct for both horizontal tunnels and penstocks. As you said, it's good to use man_made=pipeline + usage=penstock. It's important for me to have waterway=* on each segment. is it better now ? Fanfouer (talk) 17:27, 5 December 2017 (UTC)

The idea you want to implement seems to be that large volume encased water flows should get a common tag, independent of if they are pressure tubes or tunneled free surface flow and independent of if they are encased naturally flowing water or artificial. If you use the waterway key you remove the possibility to indicate these aspects since you cannot also tag them waterway=stream or waterway=drain for example - waterway=duct seems to be kind of waterway=artificial_or_natural_in_tunnel_or_pressure_tube and that would not work since it would overlap with all existing waterway types.

So - if you want to use something like waterway=penstock, waterway=pipe or waterway=duct that should be for pressure tubes only since for encased waterways with free surface flow we already have widely used existing waterway=* + tunnel=yes. --Imagico (talk) 17:56, 5 December 2017 (UTC)

The current situation is:

• waterway=river/waterway=stream without supplemental tags: open natural waterway large/small.
• waterway=canal/waterway=drain without supplemental tags: open artificial waterway large/small.
• waterway=river/waterway=stream + tunnel=yes: covered/encased natural waterway large/small with free surface flow.
• waterway=canal/waterway=drain + tunnel=yes: covered/encased artificial waterway large/small with free surface flow.
• man_made=pipeline + substance=water + usage=*: tubes carrying water, typically no free surface flow.

Separating out a new waterway class from the last with waterway=penstock, waterway=pipe or waterway=duct is not necessarily a bad idea - but that should not cut into the first four cases - which are widely used in the described meaning.--Imagico (talk) 18:43, 5 December 2017 (UTC)

I'm almost ok with this, waterway=duct would only cover pressurized pipe flow water paths. I find tunnel=yes akward since it implies for me that human can go inside. tunnel=culvert means the tunnel is flooded and dangerous for human even if the water flows freely. But tunnel=culvert sounds to be as short as drains under roads and won't be suitable for 10km long tunnels through mountains for water transmission, don't you?

Restricting waterway=duct to pipe flow is really an advantage to distinguish penstocks/siphons from drains. I'll update proposal to write this. Fanfouer (talk) 22:18, 5 December 2017 (UTC)

Add penstocks and tunnels to waterway relation

Regarding this particular remark, it's sometimes not possible to add penstocks and tunnels to waterway relation, since power operator doesn't release water to the river it took from.
Water can flow dozen of kilometers before power plant facility and be released in a different watershed.
If not, no problem to add man made facilities to waterway relation Fanfouer (talk) 16:24, 3 December 2017 (UTC)

Obviously only features that are part of a river may be added to the waterway relation. If you have a pipeline diverting water from a river to somewhere else this is of course not part of the river. The purpose of adding penstocks to a waterway relation would be to document they are a functional part of the river.--Imagico (talk) 16:56, 3 December 2017 (UTC)

Add infrastructures to regulate and deviate the water flow for Power Plants and Water Distribution

Add Dams, Weirs, Floodgates, Spillway and Fish Ladders as Waterway Relation Roles

Resolved: Fanfouer (talk) 15:25, 4 March 2018 (UTC)

To complete the Waterway schema and the Waterway relations, Water Management infrastructures to regulate and deviate water for power plants, water distribution or to protect some animal species should be added as waterway features.

Below are some Water Management infrastuctures not yet documented in a wiki page. This could probably be completed by other water managements to have a more complete waterway schema.

Floodgates are adjustable gates used to control water flow in flood barriers, reservoir, river, stream, There are 167 occurences waterway=floodgate in OSM ( See Wikipedia:Floodgate).

Spillway is a structure used to provide the controlled release of flows from a dam or levee into a downstream area, typically the riverbed of the dammed river itself. It can also be used to deviate water in an other riverbed. There are 114 occurences of waterway=spillway in OSM (See Wikipedia:Spillway).

A fish ladder, also known as a fishway, fish pass or fish steps, is a structure on or around artificial and natural barriers (such as dams, locks and waterfalls) to facilitate diadromous fishes' natural migration. There are 44 occurences of fish_pass (See Wikipedia:Fish ladder). pierzen (talk) 19:47, 5 December 2017 (UTC)

Hi Pierzen and thak you for such comments.

I wonder if we should continue to add man made structures as waterway features like dams, floodgates, weir... Those features are a great value added to OSM, but they are not actual waterways

Nevertheless, ok to define particular waterway=spillway since, it's not a proper river or stream and map a significant danger.

Also ok for waterway=fish_pass since there are always water flowing to allow fish passing the dam or weir. Fanfouer (talk) 22:18, 5 December 2017 (UTC)

Hi Fanfouer,

Ðo you suggest that all Water Management infrastructures should be in a distinct schema, not integrated with waterways ? pierzen (talk) 22:48, 5 December 2017 (UTC)

Yes, I would put dam, weir, lock_gate, dock in different keys than waterway=*. This is mainly man made structures. But this is out of the scope of this proposal. I'll only add the features you've suggested like spillway and fish_pass Fanfouer (talk) 23:36, 5 December 2017 (UTC)

My understanding, to represent the waterbed and the water management the Waterway relation should include all the water management facilities. pierzen (talk) 23:47, 5 December 2017 (UTC)

I agree regarding the relation membership and this doesn't force dams, weir, gates to be part of waterway=* key.

I'll only refine relation membership of features this proposal add or modify. This will eventually need further work in another opus. Fanfouer (talk) 00:02, 6 December 2017 (UTC)

Diameter

Resolved: Use of diameter=* Fanfouer (talk) 15:25, 4 March 2018 (UTC)

The tag diameter=* for pipelines and hydrants is the nominal diameter, that is related but not equal to the inner diameter. I think this definition is applicable to this proposal and it should be specified in the description. --Viking81 (talk) 22:37, 24 December 2017 (UTC)

I agree. I've edited the proposal to clearly stand for nominal diameter.

Nevertheless, mappers will easily access to outer diameter, eventually nominal diameter (written on pipes, or hydrants) but hardly to inner diameter. I wonder what is the best key for outer diameter, outer_diameter=* or diameter:outer=* ? Fanfouer (talk) 22:13, 25 December 2017 (UTC)

Mapping ability

As I understand the rationale, the main reason for the proposed new tag is to "ease access to waterway data for OSM consumers". I disagree that new tags make things easier when existing tags can bear the same information, and I don't see why OSM consumers shouldn't be able to include man_made=pipeline + substance=water when filtering data for waterways. Combining man_made=pipeline with waterway=* already causes a lot of trouble (e.g. the "1. Wiener Hochquellenwasserleitung" is tagged man_made=pipeline + waterway=canal + boat=no etc.). I would prefer to get rid of waterway=* on pipelines altogether. Another issue is that we use to map what we see, and we don't see the pressure inside the pipeline. This is something that even the engineers who work at those facilities may not know. Similar features should be distinguished by subtags, not by main tags. I think that usage=* and pressure=* deliver all the necessary information, and if not, you can create tags like pipeline:xxx=yyy. --Fkv (talk) 20:08, 22 January 2018 (UTC)

Problem between pipeline and waterway is exactly the problem I try to solve with a more correct value. It's all about values and not the key. As shown, all pressurised waterways aren't pipelines, but no waterway value for this at all, then should I use pipeline for natural siphons?

Forget about natural siphons in OSM. They are part of caves, and we cannot map the 3-dimensional structures of caves. You also need to consider the variable water levels in caves. Which parts are siphons depends on weather (recent precipitation, temperature) and season. There are also siphons where water is not pressed, but sucked. --Fkv (talk) 21:19, 22 January 2018 (UTC)

Variable water levels regard intermittent=*. Like pipelines, siphons can be empty if no water comes (thanks to captain obvious). Siphons remains full of water even if water stops flowing. Facts are some people map them in OSM, and tagging have to follow, not to prevent this. Fortunately, it's not mandatory to add a minimum number of siphon in OSM to be part of community. Fanfouer (talk) 21:35, 22 January 2018 (UTC)

Fantasy cities also have been mapped in OSM. That does not make them right. As a speleologist who has been to thousands of caves and surveyed a lot of them, I can tell you that cave mapping does not work that way. The voting section is not the right place to discuss this in detail. --Fkv (talk) 10:45, 24 January 2018 (UTC)

You can clearly know that a given pipeline is pressurised or not : look at the intake. If it's below the water surface, then it's pressurised since no air can get inside.

I normally don't see the intake. Look at your own sample photos. Even when no air can get inside, water may be sucked out, in which case it's not pressurised. --Fkv (talk) 21:19, 22 January 2018 (UTC)

It's all about static pressure, not dynamic one. When pipe flow, only the water height matters. If the intake is below the water level, then water is pipe flowing and waterway=pressurised applies in all situations. Fanfouer (talk) 21:35, 22 January 2018 (UTC)

if you don't see a feature, don't map it. for people that see pressurised waterway, this proposal avoid the "fake" canal. it is a useful improvement. Marc marc (talk) 22:06, 22 January 2018 (UTC)

Well, then I can never map a pressurised waterway, because all that I see is a pipeline. In order to avoid fake canals, I suggest you talk to validator developers (OSMI, keepright, JOSM builtin validator etc.) to implement a check. You'll be surprised how quickly the fake canals will be gone. --Fkv (talk) 10:45, 24 January 2018 (UTC)

Finally, you won't prevent mappers to use waterway with pipelines (or not), they will always be mapping underground facilities with waterway=canal, with or without pipeline, and issues won't be solved at all. Fanfouer (talk) 20:27, 22 January 2018 (UTC)

Fkv, first of all you should have explained your opinions before on discussion page, not only here at voting time. Then, I disagree with you because this proposal is an improvement. Simple siphons structure can be mapped in OSM and someone already does it. Then it is quite simple to determine if a pipeline is pressurized or not looking at the intake; if you can't see the intake, don't add the tags that you don't know, or add a fixme=* to explain that someone else should look for the intake for better tagging. --Viking81 (talk) 10:20, 23 January 2018 (UTC)

I don't have the time to participate in all tagging discussions, but I do have time to vote. When you disagree with my reasons, you can feel free to cast a different vote (as you did), but please don't pollute the voting section with complaints on other votes. --Fkv (talk) 10:45, 24 January 2018 (UTC)

Then feel free to approve, oppose or abstain but please avoid starting a discussion after the vote has started and in the vote section, your behaviour is disrespectful.--Nospam2005 (talk) 18:12, 26 January 2018 (UTC)

I agree, but please beware indentation level (you added one colon too much, as it's obviously not me whom you are addressing) and sign your text with --~~~~. --Fkv (talk) 00:05, 26 January 2018 (UTC)

You're right about one thing, I forgot the signature, now added with the current timestamp for clarity. I meant the guy writing "I don't have the time to participate in all tagging discussions, but I do have time to vote." and then starting a discussion inside the voting page. And this guy didn't forget to sign, it's Fkv. I don't see any indentation error here. BTW, Viking81 made previously a similar remark. Why don't you get it: there is a time for discussion and then a discussion for vote. If you missed the discussion time, you can still vote but should avoid starting to discuss. --Nospam2005 (talk) 18:12, 26 January 2018 (UTC)

It was me who voted, not who started a discussion by commenting on other votes. You certainly got it wrong because the discussion was moved to the talk page. For the same reason, your comments come late. What's your point in whining about a misplaced discussion after it has already been moved to the right place? --Fkv (talk) 07:04, 27 January 2018 (UTC)

You made a long comment on the feature page, vote section and therefore you started the discussion.

I made a vote and declared my reasons, as any voter should do, at least for "no" votes. Please read Proposal_process#Voting: "People should not just vote "oppose", they should give a reason for their proposal, and/or (preferably) suggestions." --Fkv (talk) 11:25, 27 January 2018 (UTC)

I understand both point of view here, and appreciate Fkv take time to express and discuss with us while he said he doesn't have much. Even if I can feel disappointed for having to justify maybe too much, the worst thing may be to have no one to discuss with. I'm sure we'll find a final improvement to this proposal Fanfouer (talk) 12:15, 27 January 2018 (UTC)

Once more Fkv missed the point. It's not about making a comment but as I said a long comment. Discussing about improvements is perfectly fine but better before the vote and in the discussion page. That's it. --Nospam2005 (talk) 14:01, 27 January 2018 (UTC)

The discussion was then moved to the right place. BTW I don't see your rationale when you say "I don't see why OSM consumers shouldn't be able to include man_made=pipeline + substance=water when filtering data for waterways". Able to, sure, but if I'm looking for waterways, I'm looking for... waterways! --Nospam2005 (talk) 10:29, 27 January 2018 (UTC)

Normally, people don't mean pipelines when talking about waterways. E.g. Wikipedia defines a waterway as "any navigable body of water", and "navigable" as "deep, wide and slow enough for a vessel to pass or walk". You don't navigate a pipeline with a vessel, do you? --Fkv (talk) 11:25, 27 January 2018 (UTC)

waterway=* definition is wider than Wikipedia article. It already includes man made waterways like drains or canals and structures like dams or weirs. I see this as a good thing for drains and canals (it's more questionable for dams) and my proposal only complete the established and years-long built schema. If you argue it's a poor idea to add pressurised ways, then you may have to remove many other established values to match Wikipedia definition. Fanfouer (talk) 12:08, 27 January 2018 (UTC)

To make it clear, you map service and cargo railways using the key railway, even if you don't travel on those rails. The mapping is not restricted to your way of using the data. For hydrology, water transfer is an important feature of waterways. In other words the changes proposed here are in line with *way keys.

BTW, riverbank, drain, ditch, dock, boatyard, dam, weir, stream_end, waterfall, water_point and fuel are other values not navigated by vessels nevertheless values for the waterway key. --Nospam2005 (talk) 14:01, 27 January 2018 (UTC)

@Fanfouer&Nospam2005: We all know that some OSM key names have acquired broader meanings than in the English language. E.g. highway=footway and highway=traffic_lights are not highways in standard English. However, OSM tags are just an internal representation. While conformity with standard English meanings helps to avoid confusion and misuse of tags, it is not a reqirement. We stick to highway=footway for 2 reasons: First because we currently don't have a better fitting key, and second because there are millions of objects with that tag, and migrating them to another key would cause too many troubles. When we look at waterway=pressurized/pressurised, the first reason does not apply, because we do have man_made=pipeline. The second reason does not apply either, as the tag waterway=pressurized/pressurised has not existed yet. The spelling discussion (z vs. s) underlines that fact, and you can expect that whatever spelling variations you choose in your proposal, many mappers will mistakenly write it the other way. This is a lot of trouble that we can avoid by using just man_made=pipeline + substance=water. --Fkv (talk) 19:30, 5 February 2018 (UTC)

Data consumers concern

Is there any example of data consumer where this change will "ease access to waterway data for OSM consumers"? And I am not convinced that overall it will help (even greater tag fragmentation). Proposed_features/Hydropower_water_supplies#Rationale has no explanation why current waterway=canal use should be eliminated. As data consumer making general maps I would prefer to have spillways mapped as waterway=canal + intermittent=yes rather than waterway=spillway. Also I would prefer waterway=canal + pressurised=yes + tunnel=* rather than waterway=pressurised. I abstain as I never mapped such structures Mateusz Konieczny (talk) 09:53, 23 January 2018 (UTC)

waterway=canal should be dedicated to free flowing open artifical waterways. There is no point to use canal for underground facilities which should be distinguished between free flowing (drain) and pipe flowing (pressurized). As mentioned, spillways are really dangerous and shouldn't be mapped as traditional canal at all. Even general render should indicate how dangerous they are Fanfouer (talk) 12:27, 23 January 2018 (UTC)

"There is no point to use canal for" - main point is that every new value makes tagging/using data more complicated and it should not be done without a good reason Mateusz Konieczny (talk) 13:32, 23 January 2018 (UTC)

On the other hand, data will be more accurate and words used according to their actual meaning. It's an occasion to have a more comprehensive documentation and precise preset handling in editors instead of a bunch of catchall values understandable in many different ways Fanfouer (talk) 14:32, 23 January 2018 (UTC)

"Even general render should indicate how dangerous they are" - is it a reason for introducing a new waterway value? Mateusz Konieczny (talk) 13:32, 23 January 2018 (UTC)

On this particular case, you won't be able to distinguish a spillway from another kind of canal with waterway=canal+intermittent=yes only. Spillways are flooded for particular reasons not only related to weather but industrial or environmental considerations. You may also find spillways permanently flooded (first example picture) with higher water flow rate at particular moments. Then intermittent=* isn't applicable here. Fanfouer (talk) 14:32, 23 January 2018 (UTC)

"you won't be able to distinguish a spillway from another kind of canal with" - if that is really necessary I would use a separate tag (canal=spillway? man_made=spillway? spillway=yes?) rather than break data consumers uninterested in what kind of man made waterway is at given location Mateusz Konieczny (talk) 11:21, 24 January 2018 (UTC)

@Mateusz Konieczny:: Are there any real data consumers or any map styles rendering spillways differently? IMHO not, so there is – from the perspective of potential data consumers – an urgent need to have a separate tag for spillways.

I'm not determined on fanfouers proposal, but penstocks have a very different function than canals or even pipelines (transport of mechanical energy vs transport of water). Many dams use their spillways only once in a few years, so intermittent=yes seams exaggerated to me.--Ryzen (talk) 13:53, 1 February 2018 (UTC)

different function sure but both transfer water. For rivers in desert (wadi) the recommended tag schema is "waterway=river" + "intermittent=yes". So it looks quite coherent: intermittent means not permanent. Not more, not less.

Races

Between the textual descriptions and the pictures:

• Mill race: The whole way the water goes down to feed a mill (or a turbine), from the intake to the release.
• Head race: The way the water follows from intake to a mill (or a turbine)
• Tail race: The way between a mill (or a turbine) and the water release into natural environment.

I see a small difference: the pen-stock. Or do you consider the pen-stock being part of the mill?

--Nospam2005 (talk) 18:52, 8 February 2018 (UTC)

The penstock is part of the mill race, between the head race and the tile race. Head race can be translated into galerie d'amenée in French, while tile race means canal de restitution. Fanfouer (talk) 23:53, 8 February 2018 (UTC)

Pumped storage power plants

Resolved: Use of direction=both on whole millrace of pumped storage power plants Fanfouer (talk) 15:25, 4 March 2018 (UTC)

In this proposal i miss tags for pumped storage hydro power stations. In this case, waterflow is in both directions.--Helmut Kauer (talk) 23:36, 27 January 2018 (UTC)

Simply add oneway=no, default is yes ;-). tidal=yes also means that both directions are possible, maybe a specific tag (else than oneway=no) is better. --Nospam2005 (talk) 19:47, 5 February 2018 (UTC)

Good point thank you, I've added optional direction=both for waterways related to water pumped storage plants.Fanfouer (talk) 15:25, 4 March 2018 (UTC)

tunnel=flooded?

I am surprised that the new proposal version claims to resolve issues, but instead introduces yet another doubtful tag without even explaining why.

First of all, this change has been announced several times on ML, please don't be surprised. Fanfouer (talk) 15:07, 7 March 2018 (UTC)

Viking81 wrote in his vote comment: "Tunnel=culvert and tunnel=flooded aren't in conflict because they apply to different objects, we have only to well document the two cases."

First of all, a new tag has to be documented before voting. What if we'll realize that there are different opinions on the meaning of that tag? People will possibly start an edit war right after the voting.

As to the "different objects" thought: These are not different objects, but different properties. The current tunnel=* values characterize the outer structure of the tunnel, whereas the suggested tunnel=flooded tag describes a temporary condition of its content. A culvert may be flooded or unflooded, or partially flooded, and almost every tunnel (even a tunnel=building_passage) may be flooded at times of disaster. --Fkv (talk) 11:53, 7 March 2018 (UTC)

Here is what I explained on ML last night : a culvert is directly intended to pass under a non-waterway feature, like roads or railway. Then it is as short as roads/railway are narrow.

We have to distinguish culverts from tunnels intended to carry water on kilometres, passing under mountains.

We need to consider those tunnels are not accessible in operation, but access=no only refers to legal accessibility, with signs and display towards general public and is not suitable.

Then, flooded only stands to say it's impossible to go inside, and it is designed accordingly (waterproof doors).

Finally, a culvert is smaller and a human can't go inside while tunnel=flooded is bigger.

Then, length, diameter and purpose are 3 big points to introduce a new value for tunnel. Can you propose a better terminology? Fanfouer (talk) 15:07, 7 March 2018 (UTC)

These are distinct properties. Distinct properties deserve distinct tags:

1. length: No tags are needed, because the length of a line is given by its geometry (or together with height=*, by calculating the hypotenuse). Sequences of ways can be concatenated in the same way as for the rendering of bridges and tunnels. I wonder why you only consider culverts "as short as roads/railway are narrow", and km long tunnels under mountains, with nothing in between. What about 396964473 396964473 and 194346576 194346576?
2. waterproof doors: barrier=door (or barrier=gate ?) with some subtag for "waterproof". We could overhaul and extend this proposal, which incorporated some good ideas. However, I can't imagine a tunnel with waterproof doors, except for side entrances. A waterproof door disables water flow, and who would need a flooded tunnel without water flow? Even for pisciculture, some intake of fresh water is desired.
3. diameter: diameter=*. I saw long pipelines with small diameter as well as short culverts with big diameter. The diameter mostly depends on maximum water flow and risk of congestion by sediments and litter. Of course, there are no narrow tunnels through a mountain, as the boring machines and engineers need some space to fit in at construction time, and space is also needed for later maintenance.
4. accessibility: You write that "flooded stands to say it's impossible to go inside", but on the other hand "a culvert is smaller and a human can't go inside". When humans can enter neither, this property does not help distinguish them. We need no tag for accessibility anyway, as it can be determined from other attributes (diameter, barriers, content...).
5. content: The word "flooded" seems ambiguous to me. Does it mean that the tunnel is flooded up to the ceiling (like a siphon) or that the floor is just covered with a nonzero amount of water? I am aware that you propose the waterway=pressurised tag for fully flooded tunnels, but this does not make the tunnel=flooded tag less ambiguous.

No matter whether whether a tunnel=flooded tag will be approved, I must admit that the tunnel=culvert tag needs some clarification anyway. As I am not a native English speaker, I know words like "culvert" not from daily use, but from the OSM wiki only. I have been using this tag for tube-shaped culverts only because this is how it is described and pictured in the OSM wiki. But now I realize that the Wikipedia article shows various images of angular culverts, one of them even looking more like a bridge than a tunnel. This totally contradicts the OSM definition, and I am confused now.

--Fkv (talk) 02:58, 9 March 2018 (UTC)

If I understand you well, tunnel=culvert is a special case of flooded conduits. Then it may be moved to tunnel=flooded and keys like diameter=*, material=* may complete its definition.

Some pictures of culverts on wikipedia look more like siphons (which is another kind of flooded conduit). A culvert is intended to be open-air channel (then waterway=pressurised and tunnel=culvert are incompatible) while a shiphon is pipe-flow.

Another possibility would be tunnel=culvert (+waterway=canal / waterway=river / waterway=stream) for open-air flooded conduits and tunnel=siphon (+waterway=pressurised) for pipe-flow flooded tunnels.

By the way, flooded starts when you can't walk dry inside the tunnel and have to walk in the water. Fanfouer (talk) 11:22, 9 March 2018 (UTC)

First vote archive from 2018-01-22 to 2018-01-25

• I approve this proposal. --EneaSuper (talk) 10:18, 28 January 2018 (UTC)
• I approve this proposal. --Atabaraud (talk) 20:50, 22 January 2018 (UTC)
• I approve this proposal. --Nospam2005 (talk) 21:42, 22 January 2018 (UTC)
• I approve this proposal. well documented. this proposal avoids problems with waterway=canal when it is not a canal. Marc marc (talk) 21:56, 22 January 2018 (UTC)
• I oppose this proposal. As I understand the rationale, the main reason for the proposed new tag is to "ease access to waterway data for OSM consumers". I disagree that new tags make things easier when existing tags can bear the same information, and I don't see why OSM consumers shouldn't be able to include man_made=pipeline + substance=water when filtering data for waterways. Combining man_made=pipeline with waterway=* already causes a lot of trouble (e.g. the "1. Wiener Hochquellenwasserleitung" is tagged man_made=pipeline + waterway=canal + boat=no etc.). I would prefer to get rid of waterway=* on pipelines altogether. Another issue is that we use to map what we see, and we don't see the pressure inside the pipeline. This is something that even the engineers who work at those facilities may not know. Similar features should be distinguished by subtags, not by main tags. I think that usage=* and pressure=* deliver all the necessary information, and if not, you can create tags like pipeline:xxx=yyy. --Fkv (talk) 20:08, 22 January 2018 (UTC)

Discussion goes on Talk page

• I oppose this proposal. man_made=pipeline + substance=* is an already established tagging system. I don't see why I have to also add a waterway=* --Adavidson (talk) 03:46, 23 January 2018 (UTC)

There are both artifical and natural pressurised waterways and both should get a waterway tag. It's not consistent regarding drain, canal values without Fanfouer (talk) 06:58, 23 January 2018 (UTC)

Adavidson, with man_made=pipeline + substance=* you can't cover natural siphons nor artificial pressurized "canals" (that are not canals but neither pipelines). --Viking81 (talk) 10:20, 23 January 2018 (UTC)

• I approve this proposal. It is an improvement. It covers objects that now are not easily mappable, like natural syphons and artificial pressurized canals (that are not canals). --Viking81 (talk) 09:50, 23 January 2018 (UTC)
• I have comments but abstain from voting on this proposal. Is there any example of data consumer where this change will "ease access to waterway data for OSM consumers"? And I am not convinced that overall it will help (even greater tag fragmentation). Proposed_features/Hydropower_water_supplies#Rationale has no explanation why current waterway=canal use should be eliminated. As data consumer making general maps I would prefer to have spillways mapped as waterway=canal + intermittent=yes rather than waterway=spillway. Also I would prefer waterway=canal + pressurised=yes + tunnel=* rather than waterway=pressurised. I abstain as I never mapped such structures Mateusz Konieczny (talk) 09:53, 23 January 2018 (UTC)

Discussion goes on Talk page

• I approve this proposal. --Rdesgrange (talk) 10:28, 23 January 2018 (UTC)
• I have comments but abstain from voting on this proposal. In this proposal i miss tags for pumped storage hydro power stations. In this case, waterflow is in both directions.--Helmut Kauer (talk) 23:36, 27 January 2018 (UTC)

Discussion goes on Talk page

First vote has been started on 2018-01-22 and interrupted on 2018-01-25 due to significant remarks made while voting. Work has to be done until new version