Proposal talk:Pumping proposal

Clarify what tags are proposed and what tags will be deprecated in the first section

Resolved: Proposal and rational has been refined Fanfouer (talk) 22:25, 21 March 2020 (UTC)

Please simplify the "==Proposal==" section and make it 100% clear:

1. What new Keys and Tags (Key=Value) are being approved by the proposal
2. What old Keys and Tags are being deprecated
3. Move the Proposal section to the top, before Rationale, so people will be clear on what the proposal is going to do if it is approved. --Jeisenbe (talk)

Proposal chapter has been completed, hope it is more clear now. Introduced, modified and deprecated tags are also available in Edition management chapter.

Reading and understanding Rationale is useful to understand proposal. Order of chapters matters here Fanfouer (talk) 21:44, 19 March 2020 (UTC)

Re: " Order of chapters matters here". I agree. The standard order is "Proposal" first so that it is clear what the page is proposing: Proposal_process#Proposal_Page_Template --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

Don't you think it makes proposal less understandable when referring to something that will be written in rationale afterwards? The proposal is implied by the rationale, not the opposite actually.

Placing proposal before rationale will encourage to make rationale assertions in proposal just to be sure people will have all knowledge to understand what is proposed Fanfouer (talk) 17:11, 20 March 2020 (UTC)

Re: "encourage to make rationale assertions in proposal..." Resist the temptation. Be strong. :-) Please just say what you propose in the "proposal" section, then explain why it is proposed next, in the rationale.

That doesn't solve the real problem and that's not about me but anyone who wants to write a proposal. The first hint is I'll have to write about pumps in proposal and define what it is in rationale after it. IMHO it's inconsistent but I've refined the proposal and rationale with this in mind Fanfouer (talk) 22:25, 21 March 2020 (UTC)

Rationale is too long and not clear

Resolved: Rationale is still long but brings answers to essential questions asked Fanfouer (talk) 22:25, 21 March 2020 (UTC)

Right now your rationale section is long and not focused. It just needs to prove: 1) why mappers need the new tags 2) how the new tags can be confirmed (verified) by mappers in practice (Or are you planning to import this data from an infrastructure database?) 3) how database users might want to use the tags. And since you are deprecating tags, please explain 4) why the existing tags are bad and must die. --Jeisenbe (talk) 01:45, 21 March 2020 (UTC)

Rationale has been refined and now give answers to your 4 questions

why mappers need the new tags: Mappers can't currently describe pumps with such details since pump=* actually merge pumps with their drivers and encourage a confusion between two independant devices.

how the new tags can be confirmed (verified) by mappers in practice: Proposed values=* will allow mappers to determine which kind of pump they see on ground (see examples). Figures and capacities are got from public documentation or seen in place

how database users might want to use the tags: Consumers may have interest to know their function, to which pipes they are connected to, from which source comes incoming fluid or their figures.

why the existing tags are bad and must die: pump=* actually merges pumps with their drivers and encourages a confusion between two independant devices Fanfouer (talk) 22:25, 21 March 2020 (UTC)

Sorry, but you still failed to explain why simple and useful pump=manual, pump=powered needs to be deprecated Mateusz Konieczny (talk) 07:41, 20 November 2020 (UTC)

Clarify use with man_made=water_well

Resolved: Usage with water_well is clarified: pump will remain a valid combination with new values without creating an additional feature beside Fanfouer (talk) 21:39, 30 March 2020 (UTC)

Currently 88% of uses of pump=* are with man_made=water_well (the rest are with amenity=drinking_water only) and with the 3 values: pump=powered, pump=manual, pump=no. This is a simple and intuitive system for mapping wells in developing countries and rural areas.

1. Please clarify if you are asking mappers to add a separate man_made=pump feature or if that should only be used when there is no man_made=water_well feature.
2. Why should we drop the use of pump=powered, pump=manual, pump=no? Distinguishing pump=powered, pump=manual is easy: you can hear the sound of an electric or diesel motor, and a manual pump has an obvious handle or similar. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

Usage on (not only water) wells has been clarified: it's not proposed to create a separate man_made=pump but to use new values of pump=* in combination with water_well=*.

pump=powered, pump=manual are proposed to be moved towards driver=* as it's exactly what they describe. Furthermore they currently prevent to use pump=* to give more information about pump itself. driver=manual is equivalent to pump=manual and it won't be hard to choose between driver=electric_motor or driver=engine depending on the noise and smell you get at immediate proximity of the pump, will you? Fanfouer (talk) 21:44, 19 March 2020 (UTC)

The key driver=* is much better than actuator=*, but I think motor=* would be much clearer (in English, an Engine is a type of motor: e.g. motor vehicle is used for gasoline and diesel cars and trucks).

There are thousands of pump=powered which would have to be re-surveyed. I propose using motor=electric/etc. instead of driver=* and mechanism=piston/reciprocating/etc. instead of pump=siphon/piston/reciprocating/etc., in addition to pump=no, pump=manual and pump=powered.

A said below, drivers are much more then simpler motors. See new values and illustrations provided

The point of this proposal is to replace pump=powered because it prevents the common word pump to be used anywhere else it is relevent to deal with pumps instead of their drivers. pump=* covers approx 30% of existing man_made=water_well. Most of water wells remain to be surveyed for pump drivers, we'd better providing more appropriate terminology for that. Fanfouer (talk) 20:24, 21 March 2020 (UTC)

30% of 100k is 30,000. A large number of these are in the Phillipines, West Africa and Central Africa, where re-surveying will be difficult. https://taginfo.openstreetmap.org/keys/?key=pump#map. This proposal would take a common key, used often in the developing world, and re-purpose it for a very specialized use which will not be relevant to most mappers or most database users, and which can only be known by importing the data from an external source unless the pump has very helpful signage which tells you what sort of mechanism is used to pump the fluid. (unlikely in the tropics). --Jeisenbe (talk) 00:05, 22 March 2020 (UTC)

We have two different points of view about specialization of keys: pump=* is a common word currently used on a very special activity (water wells) while it might be used in a dozen of other situations. Secondly, attached concept is more about pump drivers than pump themselves and reflexion brought with this proposal shows that it's not the same at all. I don't find knowledge of pumping capacity more specialized than knowledge of drivers, sorry.

If you make a case of 30k to resurvey, what about the 70k left to be surveyed, and the milions of other devices we can't currently map? Should we stop mapping pumping capacities right now on waterwells because it's too much time to spend? As any deprecated value, proposed ones will spread carefully according to opportunities we have to get data from ground. Hopefully, we didn't have difficulties in the past to stop using power=station is favour of power=substation and power=plant or man_made=MDF for telecom=exchange. Fanfouer (talk) 15:08, 22 March 2020 (UTC)

I am not opposed to new tags which would allow infrastructure geeks to map the internal mechanism used by a pump, but I think this can be a new tag. Just like pump_driver=* is going to be a new tag, there is no reason we can't use pump_mechanism=* and leave pump=* as it is currently used in the humanitarian mapping community. --Jeisenbe (talk) 00:22, 23 March 2020 (UTC)

This will be one key point of upcoming vote, mappers and consumers will explicitly state if they want to keep pump untouched or not Fanfouer (talk) 21:39, 30 March 2020 (UTC)

How can mappers figure out the technology of the pump?

Resolved: Mappers are supposed to see on ground to what does a pump look like and formal figures written on it Fanfouer (talk) 22:48, 12 April 2020 (UTC)

How are mappers expected to find out the pump technology mechanism? Many pumps are located deep inside the well, or hidden in a service building or structure next to the well. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

Pump technologies depends on situations they're part of, or how they are driven. Their shape is the first hint mappers can get from ground. Underground or underwater pumps can't be that complex and it's often easy to deduce their mechanism by how they are driven. For instance a Pumpjack will always be a piston.

If the pump is hidden inside a building you don't have access to, you're not supposed to map the pump at all for sake of verifiability. Fanfouer (talk) 21:44, 19 March 2020 (UTC)

Additional answer: it's possible to introduce pump=yes to state there is a pump on a man_made=water_well (for instance, or any other tag than man_made=pump) of a unknown sort seen on the ground. Fanfouer (talk) 22:41, 19 March 2020 (UTC)

That does not answer my question. Are you planning to walk up to all the pipelines and water wells and oil wells in your area, and try to figure out the pump mechanism and type of motor by observation and survey? Is this info published on a big sign located outside of the pump building or structure? Or are you planning to import this data from an outside database or map or other source? --Jeisenbe (talk) 01:54, 21 March 2020 (UTC)

Proposed pump=* values are guessable from ground. I don't plan to import anything from any database for now, but this ontology can encourage further opendata publication in the future.

Look: a diaphragm pump vs a velocity centrifugal pump. Mappers can't get it wrong if we give them valuable documentation Fanfouer (talk) 19:21, 21 March 2020 (UTC)

Re: "guessable from ground." Do you mean, you plan to guess the pump mechanism due to the external shape of the device? This seems like it will be easy to get wrong in many cases. For example, how do you know that the two examples in Proposed_features/Pumping_proposal#Local_supply use a piston as their mechanism? The piston would be internal, not visible. Why would it be important to know that this was a piston pump rather than another mechanism, especially if it was only guessed by the mapper? --Jeisenbe (talk) 00:21, 22 March 2020 (UTC)

Joseph, am I supposed to answer questions like why it's important to know the geometry of the road while it hasn't been drawed by the one who built it? ?.

Look at the pictures and you won't be able to recognize anything else than a piston pump. The same logic applies for any tag on OSM: why are we proposing values if mappers can make mistakes? Fanfouer (talk) 15:37, 22 March 2020 (UTC)

Another concern: how can a mapper distinguish between a pump=piston, pump=plunger or pump=diaphram? These are all types of Reciprocating_pump so the will look similar from the outside. Diaphragm_pump , Piston_pump , Plunger_pump . --Jeisenbe (talk) 00:48, 22 March 2020 (UTC)

It's not currently proposed to make a distinction between a piston and pluger pump : pump=piston covers them both. Diaphragm has way different shape than piston pumps and could be easilly identified at first sight, if and only if the documentation enable you to do so. Fanfouer (talk) 15:37, 22 March 2020 (UTC)

Similar concern: progressive_cavity vs screw: https://en.wikipedia.org/wiki/Progressive_cavity_pump vs https://en.wikipedia.org/wiki/Screw_pump - seems like these will look the same on the outside? --Jeisenbe (talk) 01:29, 22 March 2020 (UTC)

like everywhere in OSM, if you don't know, don't do, don't try to invent. KISS! --Nospam2005 (talk) 15:21, 22 March 2020 (UTC)

For them two I admit I did want to merge them, but I expected to face the argument a screw isn't a cavity. Ok for me to merge them or to find more usable information to make the distinction (could be written on it or available in the manufacturer documentation). Fanfouer (talk) 15:37, 22 March 2020 (UTC)

Archimedes screws are not man_made=goods_conveyor

Resolved: Removed this paragraph, mappers will be able to use pump=screw if they want to Fanfouer (talk) 22:25, 21 March 2020 (UTC)

The tag man_made=goods_conveyor is used for conveyor belts and similar devices that move solids. It is not used for fluids. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

Proposal of man_made=goods_conveyor states it's mostly intended for material carrying. You often find such screws in wastewater plants to carry both water and solid waste to further process steps.

I'm ok to integrate Archimedes' screws to screws pumps, but I expect to get the opposite argument that doesn't look like a pump. If it's not a pump nor a conveyor, what is it? Fanfouer (talk) 21:44, 19 March 2020 (UTC)

Not a pump or conveyor: man_made=archimedes_screw probably - but you don't have to include every single possibility in your proposal. Just don't mention it. --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

Mapping fans as pumps?!

Resolved: Make man_made=pump suitable for liquids only. Fans removed Fanfouer (talk) 23:01, 5 April 2020 (UTC)

Re: "Fans installed in my vent pipes looks like axial flow velocity pumps. Yes they are." This is a bad idea. The common meaning of the term "pump" does not include fans which move gases. Pumps move liquids in common British English. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

Don't you inflate your bike's tires with a pump?

Pumps are for fluids, including gases: compressors have pumps. According to definition, a high speed fan just operates the same as an axis impeller in water. I'm not currently proposing to map fans just like pumps, but to use pump=axial_flow in combination with something like man_made=fan when fan is used to move air with velocity. Fanfouer (talk) 21:44, 19 March 2020 (UTC)

That's another argument for using mechanism=* or something similar, rather than pump=*. But it's not necessary to talk about fans in this case. --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

As I had questions in separate discussions prior to publish this document I prefer to state clearly this proposal doesn't close any door to map fans this way even if this won't be approved at the end of this vote Fanfouer (talk) 22:25, 21 March 2020 (UTC)

See this interesting topic. Pumps finally differs from fans and compressors and can be assumed applicable on liquid only. Glad to found such a precise explanations. My argument with pump inflating bike tires actually refers to a manual compressor. Fanfouer (talk) 23:01, 5 April 2020 (UTC)

Key:actuator

Resolved: Actuator moved to driver Fanfouer (talk) 18:31, 21 March 2020 (UTC)

• The proposal mentions. actuator=windmill, actuator=watermill, and actuator=beam_engine. What do these have to do with pumps?
• The current use of the key actuator is quite rare, but the documented values are: actuator=manual, actuator=electric_motor, actuator=pneumatic_cylinder, actuator=hydraulic_cylinder - these don't seem to have anything to do with windmills and watermills?
• What about the exiting tags man_made=windpump, man_made=windmill, man_made=watermill? Are you proposing to deprecate these common tags?
• In the examples "actuator=manual" is mentioned, but it isn't in the list above. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

Theoretically, mills are possible actuators for pumps just like electric motors or engines. Thank you for man_made=windmill mention : I've removed actuator=windmill in favour of a man_made=windmill combination with pump=*.

man_made=windpump should be abandonned prior to be more used due to combination between actuator and pump in a single tag it implies. Fanfouer (talk) 21:44, 19 March 2020 (UTC)

But man_made=windpump is a sensible way to tag a windpump, while man_made=windmil + pump=* is not. It isn't a windmill any more than a wind power generator is a windmill: it doesn't do any milling (grinding grain or other things) nor is it similar to a traditional windmill in construction or usage. --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

Is actuator=* correct in this application? In British English, as used by electrical/electronic engineers, an actuator is part of a control mechanism. The heads on a disk drive are moved across the surface of the platter by a voice-coil actuator; the platter is rotated by a motor. It would be regarded as an error to describe the platter being rotated by an actuator. Never having been involved in pump technology, I don't know what word is used in British English to describe what is called an actuator here. Is this a case where the proposer's language uses the same word to refer to both types of thing? --Brian de Ford (talk) 22:22, 19 March 2020 (UTC)

According to Wikipedia, actuator is a kind of mechanical energy converter from many energy sources and is responsible of a given system motion. Your hard drive electric motor is an actual actuator despite it's not usual to call it so.

Such a key was designed to state by wich mean a given OSM feature is moved, including valve, eventually bollard or even entrance=main and now pump if applicable. Fanfouer (talk) 22:38, 19 March 2020 (UTC)

I read that Wikipedia page before I commented here. It is quite clear from it that an actuator is part of a control system and is used to perform actions like opening a valve. Nothing on that page implies that an actuator is anything other than part of a control system. See also https://en.wiktionary.org/wiki/actuator It's not only unusual to call the platter motor in a hard drive an actuator, British people in the computer industry would ridicule you if you did so. --Brian de Ford (talk) 23:08, 19 March 2020 (UTC)

As I understand your point, an actuator would only put in motion but doesn't transmit mechanical power, is that right? I also read pump driver in documentation (so a driver would transmit mechanical power). I've certainly been confused by approximative or too general definitions. Then, I see two solutions : actuator=* could be extended to drivers or this proposal should consider driver=* instead. Fanfouer (talk) 23:29, 19 March 2020 (UTC)

I wouldn't describe an actuator as putting or keeping something in motion because the movement is brief and the travel is restricted. It could open a valve, the valve may stay open for years before the actuator closes it. It takes power to open the valve, but transfer/transformation of power is not the purpose of an actuator. In my area of engineering, the thing that powers a pump would not be called an actuator. It's possible the pump industry uses the word differently, but a google search for pump actuator returned only devices for opening valves and performing similar tasks. Your link to the petrowiki seems to indicate that "driver" is the correct term, at least in the oil industry. I would see extending "actuator" as forcing a square peg into a round hole. I think driver=* is a better way to describe the power source that moves the fluid. --Brian de Ford (talk) 23:55, 19 March 2020 (UTC)

So actuator=* has been removed and replaced by driver=* in the proposal. Thank you for this discussion Fanfouer (talk) 21:22, 20 March 2020 (UTC)

man_made=pumping_rig

• Are you also proposing to deprecate man_made=pumping_rig? If not, please explain. --Jeisenbe (talk) 02:19, 19 March 2020 (UTC)

I wasn't aware of man_made=pumping_rig and yes it is now proposed for deprecation too. Thank you Fanfouer (talk) 21:44, 19 March 2020 (UTC)

This is proposing to deprecate a large number of approved or commonly-used tags. A pumpjack looks very different than the tiny water pump deep inside our neighborhood water well. So instead of man_made=pumping_rig you would propose what, man_made=petroleum_well + pump=piston + actuator=beam_engine + substance=oil;gas, instead of as single tag? Why use 3 tags when 1 will do? And I dont see how pump=piston + actuator=beam_engine clearly define a pumpjack/pumping_rig. --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

Why several tags instead of one? Because pumps can have several different shapes and locations. Each concept should get its own tag to be reused and shared as many often as possible for sake of semantic quality. The point here is to separate pumps and their drivers (also called actuator here, maybe a mistake).

Note that a pumpjack is the driver part of a oil field pumping rig often associated with an underground piston pump. A piston pump can be driven by a dozen of different drivers, including the pumpjack or electric motor. Fanfouer (talk) 15:13, 20 March 2020 (UTC)

The current proposal now suggests deprecating man_made=pumping_rig which would require replacing one tag with 4 in this proposal: man_made=petroleum_well + pump=piston + mechanical_driver=electric_motor (or mechanical_driver=combustion_engine - both are used by pumpjacks, depending on if a grid connection is available) + mechanical_coupling=nodding_donkey. This is an excessive number of tags to define a simple object. Also "nodding_donkey" is not a common term, "pumpjack" is usual. I would instead recommend using pump=powered + man_made=petroleum_well as the basic replacement. Mappers could still choose to add more details if they know them, but would not have to guess electric vs combustion based on aerial imagery or survey from a long distance, where this is not obvious but he presence of a pumpjack is clear. --Jeisenbe (talk) 19:47, 19 November 2020 (UTC)

pump=siphon

• A siphon is not a type of pump: https://en.wikipedia.org/wiki/Siphon "any of a wide variety of devices that involve the flow of liquids through tubes. In a narrower sense, the word refers particularly to a tube in an inverted "U" shape, which causes a liquid to flow upward, above the surface of a reservoir, with no pump, but powered by the fall of the liquid as it flows down the tube under the pull of gravity, then discharging at a level lower than the surface of the reservoir from which it came." I think it will be confusing to have pump=siphon as a value. --Jeisenbe (talk) 05:49, 20 March 2020 (UTC)

Agree that a conventional siphon is not a pump, BUT a very special siphon architecture may be used as a pump, this particlar chapter is interesting. Fanfouer (talk) 08:30, 20 March 2020 (UTC)

See also trompes and airlift pumps. --Brian de Ford (talk) 11:36, 20 March 2020 (UTC)

While such things may exist, are they mappable as a pump device, on a node or small area?

Trompe: "Trompes are very simple devices. They consist of four main parts: water-supply pipe or shaft with an air-inlet inside it, water outflow pipe, separation chamber and takeoff air-pipe. The vertical pipe or shaft goes down from higher point to a separation chamber; a pipe, that is typically narrower than previous one, coming away from that chamber, allows the water to exit at a lower level, and another pipe (air-pipe) coming from the chamber allows the compressed air to exit as needed." So what part is the man_made=pump device? The separation chamber? Isn't this always deep underground, so not really mappable?

Airlift: "The only energy required is provided by compressed air.[citation needed] This air is usually compressed by a compressor or a blower. The air is injected in the lower part of a pipe that transports a liquid. By buoyancy the air, which has a lower density than the liquid, rises quickly. By fluid pressure, the liquid is taken in the ascendant air flow and moves in the same direction as the air. The calculation of the volume flow of the liquid is possible thanks to the physics of two-phase flow. - This doesn't sound like a siphon, it's injected compressed air, pressurized by a motorized compressor.

"a more complicated device utilizing an airtight metering chamber at the crest and a system of automatic valves, may discharge liquid on an ongoing basis, at a level higher than the source reservoir, without outside pumping energy being added." ... "These metering pumps are true siphon pumping devices which use siphons as their power source." So the siphon is the "power source", and the "pump" is a metering device with automatic valves? What do you map as the man_made=pump feature? Is this something accessible to mappers in practice? Perhaps the "driver" or power source should be =siphon rather than the pump mechanism. --Jeisenbe (talk) 00:38, 22 March 2020 (UTC)

I feel like the proposal is trying to include every conceivable option, even ones that cannot practically be mapped by OpenStreetMap surveyors. How about this: find and map 1 example of each type of pump which you want to include in the proposal. --Jeisenbe (talk) 00:38, 22 March 2020 (UTC)

Beam confusion

Beam pumps, such as "nodding donkeys" are not (usually) driven by beam engines.

A beam engine is an early type of engine which originally was mainly used for pumping. Later designs could generate rotary power and power shiups.

A beam pump uses a beam (known as a "walking beam") as a linkage to convert a rotary power input into reciprocating piston movement in the pump.

There is no reason why a beam pump could not be powered by a beam engine but usually they are powered by rotary engines or electric motors.

In the case of beam pumps the beam is a linkage, not a type of engine. It's possible there are pumps in the world where the driver is a beam engine rather than some other type of engine. It's possible there are beam pumps in the world where the driver is a beam engine rather than some other type of engine. But most nodding donkeys are beam pumps which are not powered by bam engines.

BTW, I know I argued that "driver" was better than "actuator" but there may be scope for confusion with the operator of a road vehicle. pump_driver=* or pump:driver=* perhaps? --Brian de Ford (talk) 21:45, 20 March 2020 (UTC)

Thank you Brian, I think I had the same reasoning : actuator=beam_engine has been replaced by driver=pumpjack (engine/motor + beam linkage delivering reciprocating motion).

Regarding driver, I also looked for better options. I'm not sure this concept can't be used elsewhere than pumps. If not I'd be ok for pump:driver=* Fanfouer (talk) 21:49, 20 March 2020 (UTC)

If we are going with "plain English", then motor=* or pump_motor=* would be even clearer. --Jeisenbe (talk) 01:56, 21 March 2020 (UTC)

There are some problems with a generic driver=*. Firstly, "driver" may be specific to only some of the things where we would like to specify the power source, other industries might use "prime mover" or some such term. Secondly, I'd prefer not to have a naked "driver" in order to avoid confusion with car drivers, so we'd end up with foo:driver=* and bar:driver=* anyway. Thirdly, some editors populate the value drop-down for a key by interrogating the wiki page (or its associated wikidata item): unless all of the values apply to all future uses then you get a large list with many values that are not appropriate for the particular POI unless the editor developers maintain such lists manually and add extra code to determine when to apply which subset of values to a drop-down (the developers of one popular editor will bluntly refuse to do that and have already done so at least once).

Joseph, drivers aren't always motors. When manual, human hands aren't a motor but I still read lever driver in documentations. There are also solenoids and cylinders I've added to the list with links provided to illustratons.

A pumpjack is a particular kind of pumping rig. It can be driven by an electric motor or by a diesel engine, so shouldn't the tag be driver=electric_motor or motor=diesel_engine? --Jeisenbe (talk) 01:41, 21 March 2020 (UTC)

You beat me to it. A pumpjack is technically a beam pump, It has a very distinctive appearance, which is why it is popularly known as a "nodding donkey." The power source could be an electric motor, a diesel engine, or even a beam engine. In fact, the reason the technical name is "beam pump" is because the earliest drivers were beam engines. But beam engines are thermodynamicaly inefficient compared to rotary engines, which is why modern beam pumps don't use beam engines even though the mechanism would be a lot simpler.

A pumpjack sounds to be the assembly of a rotating source (basically a motor) and a nodding donkey. That's why I've completed the drivers definitions as a motion source and eventually a motion adapter when required. There is an opportunity to divide source and/or adapter in a further proposal as this one only regards drivers as a whole object. Fanfouer (talk) 19:16, 21 March 2020 (UTC)

Consider drivers as pump specific devices

Resolved: Drivers are now proposed as motion_driver=* as to not confuse with any other kind of driver Fanfouer (talk) 22:46, 12 April 2020 (UTC)

We already have a type of object which has a choice of power sources: generators. These are specified with generator:source=*. I see no value in trying to force them to use generator:driver=* nor in pumps using pump:source=* (which would be very confusing, because I'd assume that would specify the source of the fluid being pumped). Let's go with namespacing using terminology appropriate to the specific industry, such as pump:driver=* if only to keep editor developers happy. --Brian de Ford (talk) 13:38, 21 March 2020 (UTC)

Brian, be sure I consider the opportunity to make driver more precise for pumps. Distinction made between generators bodies and their drivers would be interesting (electromagnetic rotor driven by pelton turbine for instance). That's out of the topic anyway. As I added solenoid and cylinders, I've merged electric motor and engine as rotating_motor. Should I add another key to give the power source or split values like rotating_electric_motor, rotating_engine, gasoline_pumpjack, electric_pumpjack... ? Fanfouer (talk) 19:16, 21 March 2020 (UTC)

After a bit more thinking about this point, another solution would be to define driver=* (or pump_driver=*) as a rotating motion source only (electric motor, engine, mill, whatever rotating) and pump_coupling=* as the linking device between the pump and its driver : nodding_donkey/pumpjack, reductor, direct coupling...). That would allow to distinguish electric and engine powered pumpjacks and eventually prevent to define pump-specific drivers. How do you feel @Brian de Ford: and @Jeisenbe: about this? If no, I'd simply move driver=* to pump_driver=*. Fanfouer (talk) 22:17, 3 April 2020 (UTC)

driver=* has been moved to motion_driver=* and motion_driver:coupling=* as such classification can be suitable for fans or compressor as well. I didn't want to include pump word as to no make it too specific Fanfouer (talk) 22:46, 12 April 2020 (UTC)

Searching the internet for "motion driver" does not find anything about pumps on the first page, and adding "pump" + "motion driver" finds pages about high-heeled shoes. I would sugest using pump_driver. --Jeisenbe (talk) 01:39, 13 April 2020 (UTC)

Drivers aren't specific to pumps, this key can be suitable for compressors or fans at least, then it is desirable to not make things too specific for pumps. Motion driver is most close term I found without pump in it. Any better suggestions without pump? Fanfouer (talk) 20:48, 13 April 2020 (UTC)

Definition of man_made=pump should be changed to exclude fans

Resolved: Make man_made=pump suitable for liquids only. Fans removed Fanfouer (talk) 23:01, 5 April 2020 (UTC)

The proposed definition of man_made=pump is currently "A ... device in charge of raising level or move any fluid, including gases". I suppose this is meant to be "A device which moves or raises the level of any fluid, including gases". This definition would include all types of fans, since a fan moves gases. I don't think we should use man_made=pump in this overly-general way. A pump is a device which moves a fluid through a pipe or tube or into/out of a container.

I would use this definition or similar: "a mechanical device using suction or pressure to raise or move liquids, compress gases, or force fluids through a tube or pipe". See also https://www.lexico.com/definition/pump and https://dictionary.cambridge.org/dictionary/english/pump, https://www.oxfordlearnersdictionaries.com/definition/english/pump_2, https://www.collinsdictionary.com/dictionary/english/pump --Jeisenbe (talk) 00:00, 22 March 2020 (UTC)

I'd rather agree about this slight change of definition.

Nevertheless, I think the fan beside still matches: it uses suction to move air out of a road tunnel through a duct.

If you replace air by water (with appropriate waterproofing) you've got the same exact result

Should we distinguish fans that push air in a duct between open air ones? Fanfouer (talk) 19:39, 22 March 2020 (UTC)

Re: "Should we distinguish fans that push air in a duct between open air ones" - I think that's off-topic. But if you want to create Proposed_featrues/Tag:man_made=fan we can talk about it there. --Jeisenbe (talk) 01:14, 4 April 2020 (UTC)

Two additional proposals will be required to deal with fans and compressors with distinct man_made=* values. Fanfouer (talk) 23:01, 5 April 2020 (UTC)

Output

Resolved: Move to maxflow Fanfouer (talk) 21:30, 30 March 2020 (UTC)

« pump:output=* "The maximum output flow a pump can deliver in m3/s" » I'd name it maxoutput as we do for other tags like maxspeed, maxheight, etc. It should be also possible to specify other units.

I wonder also if the output product (water, oil, gaz ?) should be also has its tag. It's an important information I think. --Florimondable (talk) 16:51, 29 March 2020 (UTC)

Hi Florimond and thank you to get involved here. I understand your point and that's interesting. maxoutput=* wouldn't be so evocative for a pump. How do you feel about maxflow=* or maxoutputflow=*. Benefit of maxspeed=* is we know it's about speed just by reading it.

Regarding output product, you're looking for substance=*. See here, under the table, it's explained it's correct to add substance=* on the pump even if it's first of all a connecting pipeline property. Fanfouer (talk) 21:45, 29 March 2020 (UTC)

I guess maxflow=* is ok. --Florimondable (talk) 14:09, 30 March 2020 (UTC)

Sounds good thank you, I've updated the proposal with maxflow=* Fanfouer (talk) 21:30, 30 March 2020 (UTC)

Please don't confuse 3 very distinct types of "windmill"

Resolved: man_made=windpump is kept and combined with proposed pump=* Fanfouer (talk) 22:05, 3 April 2020 (UTC)

What an English speaker means by the word "windmill" is pretty culturally biased - there are 3 easily distinguished types of entity that are colloquially called windmills by various groups of English speakers around the world:

• buildings (often unique in design, constructed in situ) powered by the wind, containing mechanically driven machinery that typically grinds grain into flour, but may also be used to do other things such as pump water (represented as man_made=windmill)
• turbines which use wind power to generate electricity (represented as power=generator, generator:source=wind)
• normally skeleton structures, typically supporting multi-vaned wind wheels, often factory made, which often are used to pump water (represented as man_made=windpump)

A better terminology for the last group is wind engines, but outside of technical literature that is rarely used. A real world compromise is that the best distinction that can be achieved is to call all buildings windmills (whether they mill or pump water), all devices that produce electricity wind turbines, and all the other mass produced devices that make mechanical use of wind power, windpumps, whether they pump water or not. This is the distinction currently largely in effect at OSM.

Whilst I understand your desire to record more information about devices used specifically to pump, please do not do it in such as way as to make the three groups of things above more confused. In particular dropping the easy distinction between the substantial building windmills, and the mass produced comparatively insubstantial windpumps is a backwards step.

Many renderer's show the first two categories on the list, but ignore the third category - that is a very reasonable stance, given that the third are far less substantial than the others, and thus provide far less of a landmark useful for navigation. Your proposal will end up having renderer's showing insubstantial windpumps as buildings using the windmill icon - that is simply hugely misleading. (I know that you propose having a way to distinguish based on additional tags, but in so many cases these additional tags will never be provided, and the defacto position of mappers will be to just use the man_made tag and nothing else).

In addition, in much of the developed world, windpumps are an obsolete technology, so the examples that exist fall into two main categories - they are either restored examples, often moved from their working location to somewhere more photogenic, and rarely reconnected to a pump of any form, or else they are unrestored, still in situ, but no longer capable of pumping either. At the moment, labelling both of these as windpump is understandable and justifiable - that is certainly how they look.

In practical terms, is seems to me that your proposal about the pump is largely about what exists at ground level or below - whereas the current tag of windpump is ideally suited to describing the structure above ground. As such, I think these are complementary - if the structure of a windpump exists above ground, then it should be labelled with man_made=windpump. This tag should not be deprecated, and in fact its use further encouraged.

Thank you for such a detailed description which make your point very understandable.

No problem to encourage a distinction between windmills as buildings and way lighter fabrics driving pump as to take water out of the ground.

If the appearance and structure matter, why those mills are distinguished on their usage? As I read wikipedia, a windpump could look like both this one or less often De Olifant.

Even if results are the same, I don't question visual differences between small and big mills, but the point of pump in man_made=windpump while you may need kind of man_made=small_windmill.

That's not the point of the proposal to propose a new man_made value for actual windpumps, then I removed the deprecation of man_made=windpump and combinate it with proposed pump=*. Fanfouer (talk) 22:05, 3 April 2020 (UTC)

Not a fan of pump=manual deprecation

I would prefer to keep some human editable and human readable way of marking "this man_made=water_well requires manual pumping" Mateusz Konieczny (talk) 01:20, 30 April 2020 (UTC)

It's the purpose of motion_driver=manual. Any better term than motion_driver suitable for its definition (mechanical source and suitable for pumps, fans and compressors) will be considered Fanfouer (talk) 22:12, 30 April 2020 (UTC)

The existing tag pump=manual is perfectly good for this application. You have not given any clear reason why this needs to be changed. --Jeisenbe (talk) 05:32, 23 September 2020 (UTC)

This is the whole proposal's goal: using pump=* for mechanisms and motion_driver=* for motion sources. Human hands are a motion source, not a pump technology that's why it needs two keys Fanfouer (talk) 22:16, 23 September 2020 (UTC)

Then why you use already existing tag for new purpose? Use new tag for tagging technical pump detail and leave pump=manual/pump=powered in peace... Mateusz Konieczny (talk) 07:43, 20 November 2020 (UTC)

Existing pump=* use a common word pump but focus it on a particular place (water wells) and actually deals with drivers, not pumps. pump=powered is not consistent with pump=piston for instance since the exact same piston design could be powered or not. I think mechanical_driver=powered is ok to preserve the manual/powered distinction, waiting for optional more detailed knowledge.

Such a change will be the same for water wells renders: they'll have to support new values for pump=* or drop it in favour of mechanical_driver=*. Fanfouer (talk) 01:07, 22 November 2020 (UTC)

That is not the only option. I have already request that you create pump_mechanism or another similar new key for the proposed values such as pump_mechanism=piston and pump_mechanism=centrifugal. You seem to be claiming that it is natural to use the key "pump" in the way you have proposed rather than creating a more specific key. But if we are being pedantic, the pump itself isn't a single piston, the term "piston" or "centrifugal" is describing the mechanism or impeller or other device that is used to cause the fluid to move under pressure. Hence pump_mechanism=* would be more specific, and would not require the likely futile attempt to deprecate the existing usage of the key pump=*. --Jeisenbe (talk) 05:21, 22 November 2020 (UTC)

As a piston requires a plunger moving into a static body to pressure the fluid, yes the piston is equivalent to the pump. What makes the plunger actually move in the body refers to the coupling or to the driver but not to the pump. Look at the scheme I add to the rationale, a pump is never powered or manual, it just waits to be moved by an external driver which can be changed for any reason (it's actually easy to swap a combustion engine by an electrical motor and keep the exact same pump). Then I agree to define mechanical_driver=powered to keep the same distinction made between manual and powered but not with pump=* key. Fanfouer (talk) 17:08, 22 November 2020 (UTC)

motion_driver=engine is too general

Resolved: Moved to combustion_engine, thank you Fanfouer (talk) 22:46, 18 September 2020 (UTC)

motion_driver=engine ("A complex mechanical device which converts energy into useful motion or physical effects") seems like a superset which could contain motion_drive=electric_motor. Changing it to motion_driver=internal_combustion_engine or motion_driver=ice would solve this possible confusion.

Hi and thank you for pointing this out. It's ok to change engine to a more appropriate term. Is shorter motion_driver=combustion_engine ok for you? Fanfouer (talk) 22:01, 16 September 2020 (UTC)

Hi, no problem :) External combustion engines seem rare enough to omit them, and use motion_driver=combustion_engine as a compromise to me --Gileri (talk) 11:36, 17 September 2020 (UTC).

"Maximum" should be "Nominal" for pressure=*, maxflow=*

Resolved: That's a good point. The proposal moved to nominal figures Fanfouer (talk) 22:08, 16 September 2020 (UTC)

Usually mechanical systems have a distinct maximum and nominal "capacity".

What's more representative of reality is the rated/nominal capacity, as the maximum one should not be used regularly. It's why pressure=*, aerialway:capacity=* and surely other tags use nominal capacity instead of maximum. maxflow=* could be renamed into flow=* or nominal_flow=*.

If the maximum capacity is deemed a useful information, additional tags could be introduced, e.g. flow:maximum=*.

Move proposed pump=* values to pump_mechanism=* or similar

Resolved: Pump mechanisme are now moved to pump_mechanism=* Fanfouer (talk) 23:42, 12 December 2020 (UTC)

As mentioned above, pump=* has been used 10s of thousands of times to map whether a water well has a manual pump or a powered pump or no pump at all. This is a well established tagging system which is easy to use and very useful in much of the world, including the many countries where most rural villages still obtain water directly from wells.

This proposal is seeking to co-opt this key (pump=*) and re-purpose it to define the technology used by the mechanism of the pump: information that is only knowable and useful for specialists. Instead of changing the meaning of an established key, I propose using pump_mechanism=* or something similar, e.g. pump_mechanism=rotary_vane. --Jeisenbe (talk) 05:40, 23 September 2020 (UTC)

Thank you for this proposal and pump_mechanism could be a good word for that but it would also lead to redudancy with two ways to give the same information. pump=* currently understands motion sources as pump-focused concepts which is wrong. Will we have to define a manual value for each object that can be moved by hands? At global osm namespace scale, actuator=manual and motion_source=manual are enough instead of door=manual, entrance=manual, pump=manual, valve=manual, gate=manual, switch=manual, bollard=manual, window=manual, whatever manual... Fanfouer (talk) 22:35, 23 September 2020 (UTC)

Re "Will we have to define a manual value for each object"? No, we only need to consider pumps in this proposal, and the existing usage of the tag pump=*. It is not necessary or helpful to develop a tagging system which will work for all mechanical devices in one proposal. --Jeisenbe (talk) 04:35, 24 September 2020 (UTC)

No, we only need to consider pumps in this proposal My question wasn't focused on this proposal. Approving pump=manual now is a logic which will encourage the definition of a similar concept for every feature that would require it later. I respectably disagree with such point of view. I had been helped in the past when existing concepts was well defined and could be reused with other features.

Approving pump=manual for manual pumps is as restrictive as defining pump=green to state a pump is paint in green instead of using a common colour=* shared by every feature paint in green. Fanfouer (talk) 14:32, 24 September 2020 (UTC)

I'm not asking you to APPROVE pump=manual, I'm asking that it not be deprecated and erased by your desire to map the mechanism of pumps. This tag is already the "de facto" way that manual pumps on water well are mapped in many countries. Instead of listening to this concern, you trying to cancel a tag used thousands of times in low-income countries and take it for mapping very particular, technical details which are of interest to only a small community of infrastructure enthusiasts. This is not equitable or fair. --Jeisenbe (talk) 19:54, 19 November 2020 (UTC)

which are of interest to only a small community of infrastructure enthusiasts. Here is our point of view difference. Knowing how a pump actually works, combined to a given driver isn't for infrastructure enthusiasts only but for local people as well or crisis management: how emergency services will be efficient with electricity pump=powered pumps if they come with gasoline only?

As said, I find pump=manual too restrictive for reasons upside and propose a solution I find more efficient Fanfouer (talk) 10:52, 20 November 2020 (UTC)

"it would also lead to redudancy with two ways to give the same information" I would like to jump in for the record to say that there's nothing wrong with a general key (for any pump properties), together with a specific key (for pump mechanism specifically). ---- Kovposch (talk) 20:04, 23 November 2020 (UTC)

Thank you and I agree with you in general. In this particular situation, the general key pump=* regards drivers, not pumps and I don't find desirable to encourage the confusion of two. Fanfouer (talk) 22:21, 23 November 2020 (UTC)

Values of mechanical_driver are confusing and non-verifiable

The proposed tag mechanical_driver, which is meant to replace the current use of pump=*, mixes obvious values like manual, electric_motor and combustion_engine with strange ones like reciprocating_solenoid, cylinder and turbine which are not sufficiently explained. It is easy to identify a manual lever, though I note that there isn't anything about a foot or pedal or tredle powered pump, or a pump powered by working animals. And it's easy to identify an electrical motor vs a combustion engine based on the presence or absence of electrical wires and smoke exhaust and noise. But how would we identify a reciprocating_solenoid vs an electrical motor? And what in the world are mechanical_driver=cylinder and mechanical_driver=turbine? How does a cylinder or turbine provide power to a pump and when would an ordinary mapper be able to identify and confirm this to exist? --Jeisenbe (talk) 19:35, 19 November 2020 (UTC)

Hi Joseph, did you see this video showing a solenoid in action? A solenoid produces a reciprocating movement and can't be confused with an electric motor.

A turbine got its power from a moving fluid, you'll definitely be able to see gas or steam inputs in situation with no additional wires

Finally, this gif on wikipedia shows well how a pneumatic cylinder could drive a double diaphragm pump which alternates admission and ejection between its two chambers.

These all are way different shapes and functions, mapper will be able to identify them with an external look in most situations. Fanfouer (talk) 23:49, 19 November 2020 (UTC)

Tagging exact driving method

Looking into it: pump=powered tagging (specifying that pump is powered, without specifying how) would become impossible if following this proposal ("according pump=* + according mechanical_driver=* + according mechanical_coupling=*"). This make it utterly unacceptable. Any tagging scheme allowing to tag extreme detail uninteresting to nearly all people must allow also tagging basic info without making mandatory to specify details. And this proposal would make tagging "this pump is powered, not sure how" completely impossible, what worse it would take over pump=* key. Mateusz Konieczny (talk) 07:51, 20 November 2020 (UTC)

I do appreciate your comments and many of your points are already answered both in rationale and Talk.

pump=powered is suitable for electric or gasoline powered pump (not this pump is powered but I don't know how), this proposal shows many other ways to power a pump. Have you tried to map something with the two schemes to see which one is the most usable? Can you provide a situation where you were unable to see how the pump was driven please? Fanfouer (talk) 08:59, 20 November 2020 (UTC)

Mapper may be also simply uninterested in tagging exact method and simply desiring to tag it as not requiring human-powered operation. Tagging unimportant details should not be mandatory to record less detailed info. Mateusz Konieczny (talk) 09:05, 20 November 2020 (UTC)

"many of your points are already answered both in rationale and Talk" neither explanation why pump=* deprecation is needed, nor tagging example for deprecated pump=powered, nor explanation for exact replacement of pump=powered is provided. Mateusz Konieczny (talk) 09:08, 20 November 2020 (UTC)

Reviewing values with a particular meaning prevent no one in using different ones (mechanical_driver=powered for instance), Any_tags_you_like applies here.

A pump is a mechanism to raise level of a fluid, different from a motor or any other driver. As explained in Talk, pump is currently a misused word, related to driver and not to pump. Fanfouer (talk) 09:26, 20 November 2020 (UTC)

Your proposal deprecated current method for tagging this without providing replacement. Including mechanical_driver=powered in proposal would remove this specific problem (though I would still cosider deprecating easy to remember pump=manual and pump=powered as a mistake) Mateusz Konieczny (talk) 11:12, 20 November 2020 (UTC)

I explained that I find current tagging meaningless (with all due respect to people who created it in the past): knowing how a pump actually works, combined to a given driver isn't for infrastructure enthusiasts only but for local people as well or crisis management: how emergency services will be efficient with electricity pump=powered pumps if they come with gasoline only? Fanfouer (talk) 11:16, 20 November 2020 (UTC)

I have no idea why people tagged this info (not sure is it intended for crisis management or for something else), but clearly some were interested in tagging this level of detail. Tagging more info may be useful or interesting for some, but it is not a valid reason to deprecate and block existing tagging. It reminds me about someone who made proposal to deprecate power=tower and proposed tagging voltage as a replacement, without being aware that it is not a viable solution. Mateusz Konieczny (talk) 11:22, 20 November 2020 (UTC)

It is explained in rationale that current tagging is proposed for deprecation because words are misused. Current pump=* is focused on wells and deals about drivers, not pumps and is confusing. I'm glad you mention non viable power tower tagging according voltage because it's the current one and it should be refined indeed but it's a different debate Fanfouer (talk) 11:35, 20 November 2020 (UTC)

Re; "I find current tagging meaningless (with all due respect to people who created it in the past)" - this is absolutely disrespectful to the current mappers using this tag to specify the type of water well found in lower-income countries. Perhaps you have never lived in a place where people get their drinking and washing water from public or semi-public wells? In these places it is quite important to know if a well is just a hole in the ground where you need to use a bucket and rope to draw out water (pump=no), or if there is a mechanical pump handle which you can physically operate, with some amount of force, to pump out bursts of water (pump=manual). And the other type of well is "a well that is attached to pipes and a motorized pump", which is usually powered by electricity but sometimes by a diesel motor. In this type of well you don't have to use any physical effort at all, you just flip a switch or open a faucet and water comes out - as most Westerners are accustomed to enjoy in their own homes. But you will need electricity or fuel to operate it. So usually the a pump=powered is much more convenient, but when the power goes out or there is no fuel, it can be nearly useless, while a pump=manual is now much more helpful. --Jeisenbe (talk) 05:11, 21 November 2020 (UTC)

Deprecation of pump=manual and pump=powered would break current usage by significant database users

Resolved: pump=manual and pump=powered aren't proposed for deprecation anymore Fanfouer (talk) 18:33, 12 December 2020 (UTC)

The current tagging of man_made=water_well + pump=no/manual/powered is currently used by the HDM style, featured as the "Humanitarian" map layer on Openstreetmap.org, to determine what sort of icon should be shown for a water well. Examples:

https://www.openstreetmap.org/node/5768737664#map=17/-8.54734/122.04898&layers=H - well with powered pump (and you can see 3 more nearby, one for each "dusun" or small "neighborhood" in this village)

https://www.openstreetmap.org/node/5768453092#map=18/-8.74465/122.07912&layers=H - lots of wells with no pump, represented by a bucket, also one powered well in this village.

https://www.openstreetmap.org/node/6449466014#map=18/14.52455/121.05865&layers=H - water well with a manual pump in a school yard - also another one in the school to the east.

Have you contacted the maintainers of the HDM style at https://github.com/hotosm/HDM-CartoCSS about this potential change? Realistically, as long as these tags are supported in rendering, they won't be abandoned by mappers, so any attempted deprecation will be confusing and ineffectual. --Jeisenbe (talk) 05:50, 21 November 2020 (UTC)

"Have you contacted the maintainers of the HDM style" - I did it right now using https://github.com/hotosm/HDM-CartoCSS/issues/322 Mateusz Konieczny (talk) 08:04, 21 November 2020 (UTC)

Proposed use of handle=level conflicts with current definition of that tag

Resolved: Handle lever usage has been clarified Fanfouer (talk) 18:49, 12 December 2020 (UTC)

The wiki page Key:handle, which was created after Proposed_features/Pipeline_valves_proposal was approved, defines this key as "Kind of handle installed on doors or more specific systems as to open or close them". In the proposal, the key handle=* was described as "handle <handle model> Does a handle is available on the valve?" with values "level, wheel, cross, button" - and handle=lever was defined as "A single arm lever is available to operate the valve. This is the preferred handle design for modern domestic use." These definitions don't fit with a manual pump lever, which is not used to open or close the pump, but rather is used to provide the energy to operate the pump. I don't think these are called "handles", at least not in American English.

Compare the pictures https://upload.wikimedia.org/wikipedia/commons/thumb/b/b1/Alloy_valves.JPG/100px-Alloy_valves.JPG used currently for handle=lever and https://upload.wikimedia.org/wikipedia/commons/thumb/c/cc/Mali_water_pump.jpg/360px-Mali_water_pump.jpg - using the tag handle=* for these seems incorrect to me, because this is not like a doorknob or a valve handle. And what about this kind of hand-operated pump which has a huge bar with weights - do you call it a handle? https://waterbuckpump.com/wp-content/uploads/2016/10/Community-Hand-Pump.jpg --Jeisenbe (talk) 05:51, 22 November 2020 (UTC)

Wikipedia deals with hand pumps, i thought about an appropriate use of handle=*. Lever pumps are actually piston/diaphragm/... pumps with lever driver. It sounds to be a 3rd class lever.

Lever handle sounds to have different forms and this is what we get when looking for them 3 :

• Door handle : The most common types of door handle are the lever handle and the doorknob.
• Ball valve : Lever handle (on the first chart)
• Hand pump (kind of lever is a hand pump) : Piston rod + force rod = lever.

Regarding your last example, I mean yes, that's a big lever handle Fanfouer (talk) 16:03, 23 November 2020 (UTC)

iD general Pump Preset example

I put this together based on the proposal so people could possibly judge the understandability of this since it has been a concern.

The water pump preset, etc. will look a bit different of course, but this example preset incorporates all of the proposed features.

--Lectrician1 (talk) 18:06, 23 November 2020 (UTC)

This is inspiring, thank you for this suggestion Fanfouer (talk) 22:16, 23 November 2020 (UTC)

This is a great graphic, and thanks for creating it. However, I still don't understand why pump=* must be overridden to store the pump technology information. If this proposal were to simply use a different key for that field, this proposal would pass easily. pump=powered + pump_technology=diaphragm (for example) would be perfectly understandable. Surely there is a way to describe all of these aspects of pumps while retaining the existing usage of pump=*. --ZeLonewolf (talk) 22:38, 23 November 2020 (UTC)

Because pump=powered is misleading, believe me: it's not about a pump but about a driver. pump_technology=diaphragm isn't a sub-property of a powered pump, it's a particular pump device sometimes assembled with a powered driver. Those two are described on a single node on OSM and people have the impression it's one single concept instead of two. The same diaphragm pump could be manually driven. pump word is currently used in place of driver and I propose to fix this formal issue here. It's not a sub-property matter and it's not a fancy thing to deprecate an established tagging. I wouldn't have proposed so if pump word was correctly used. Fanfouer (talk) 22:45, 23 November 2020 (UTC)

Think about this sentence: "Well, road is already taken to deal with trees, then use a different word please". Fanfouer (talk) 22:46, 23 November 2020 (UTC)

That is not a meaningful analogy. "Pumping water from a well" is a perfectly valid plain-English description of the activity that pump=* currently describes. You are ignoring the extensive feedback that has been provided by multiple commenters. It appears that you would rather this proposal to fail in the vote than modify the scheme to address the concerns expressed. That is a shame, because this is an otherwise very well-thought out proposal that would be beneficial. OSM tagging is based on community consensus on how tagging should be applied. It does not matter how technically or scientifically correct the subject matter, or whether the word used for the tag is the exact thing being described, if it does not service the practical needs of non-expert mappers. The tag highway=* is used to describe paths. The tag natural=coastline is used to tag the high tide line rather than the hydrological definition of a coastline. The tag amenity=* is used for things that aren't amenities, such as amenity=police and amenity=university. It goes on and on. There must be a way to tag a pump which is powered, but no other information is known, and extensive existing tagging for water well pumps must be accomodated. --ZeLonewolf (talk) 23:17, 23 November 2020 (UTC)

Note that pump=* was perfectly well until another scheme was proposed. I currently see no other solution for highways, amenities replacement/refinement/extension are nonetheless regularly discussed and so on.

Pumping water from a well is perfectly fine and this proposal doesn't question it. However, it's not the only usage of pumping and current wiki pump=* states it requires man_made=water_well which is way too restrictive.

It appears that you would rather this proposal to fail in the vote I see both approval and opposition comments and should respect both of them for now.

As answered before, mechanical_driver=powered is suitable to address concerns about manual/powered distinction and this proposal obviously doesn't prevent its definition. Fanfouer (talk) 23:28, 23 November 2020 (UTC)

I'd like to offer a gentle reminder that the threshold for approval is at least 74%. Given the significant opposition so far, I suggest that it would be a better use of everyone's time to modify the proposal so that it addresses the the concerns, and re-submit for a new vote. Simply allowing the existing pump=* values to remain is probably the simplest fix to make this proposal pass. Obviously you are welcome to see it through to the end of the current vote if that is what you insist upon. --ZeLonewolf (talk) 23:47, 23 November 2020 (UTC)

Pardon me, am I blamed for insisting while 86% of OSM's water wells still wait for a pump=* value? How can we talk about an established usage for 14% of a single feature among many?

Having this word pump focused on water_wells actually prevent extending pump mapping on dozen of thousand objects unrelated to water wells.

It's not about pumps only, it blocks compressors as well. We're stuck for 20k occurrences relatively to hundred thousand features waiting to be mapped Fanfouer (talk) 00:05, 24 November 2020 (UTC)

Those things will continue waiting if you are unable to come up with a scheme that can achieve consensus, regardless of how technically accurate your scheme is --ZeLonewolf (talk) 00:09, 24 November 2020 (UTC)

By the way, I don't exactly get why you didn't consider suggested mechanical_driver=powered to address pump=powered concern Fanfouer (talk) 00:26, 24 November 2020 (UTC)

Consider also that the proposal process is not supposed to find a majority of support for a compromise position, but rather it should achieve consensus. The 75% voting threshhold is simply one way to show that consensus has largely been achieved. In this discussion it is clear that most people support most of the new tags in the proposal. The only significant objection has been to deprecation of pump=* for its current use. There has already been a suggestion by several people to use a new tag like pump:mechanism or pump_technology or similar to express this concept. This will cause no harm to the proposal, and will allow the current use of pump=* with water wells to continue for now. Why not accept this suggestion, to achieve consensus? --Jeisenbe (talk) 01:39, 24 November 2020 (UTC)

You know, it's actually hard to consider pump_mechanism or pump:mechanism while I was blamed for complex-hard-to-remember mechanical_driver.

Argument like wow! pump is established don't touch it while 86% of wells miss it just fails to convince me. pump=* was actually not reviewed, used since 2011 and documented in 2013. I would certainly down vote it if only I was asked for.

Past changes like that give better results in way less time than it was required to populate the deprecated key (1 year for line_attachment=anchor vs 7 years for tower:type=anchor).

Even if I could be tempted to easily edit the proposal to look for a short-term consensus, I have good reasons to think it's not a good idea on medium-term as well.

Let me return the question: why don't you consider mechanical_driver=powered to address pump=powered, to achieve consensus? Fanfouer (talk) 21:17, 24 November 2020 (UTC)

It is not our job to convince you that certain tagging is a good or bad idea. It is your job to convince the community why we should adopt a particular tagging style, and the comments all over this talk page should be a sufficient indication of the community's views. And to your specific question, I and many others here find mechanical_driver=powered to be a confusing and unneeded replacement for the simple pump=powered, which has clear meaning and is working just fine to tag powered pumps and is accepted by mappers. There is no good reason why your proposal cannot maintain that usage and simply offer expanded tagging for pump technology details, other than your continued refusal to consider other points of view as legitimate. You could have chosen to define something like pump:mechanism=*, which would have been a perfectly valid way to describe the values that you propose to use pump=* for.

There would be nothing wrong with (for example) tagging a pump like this:

• man_made=water_well
• pump=powered
• pump:mechanism=gear
• pump:driver=electric_motor

Clear meaning! A water well, with a powered pump that uses a gear mechanism and an electric motor.

If you wish to achieve the goal of more detailed tagging for pumps, you must listen to the valid objections being raised and adapt your proposal so that it achieves consensus. You are wasting everyone's time by continuing to argue rather than listen to the legitimate concerns and objections being raised. There is no benefit to the community if the proposal is rejected, especially when there is a clear path to acceptance. --ZeLonewolf (talk) 21:51, 24 November 2020 (UTC)

Good/bad reasons/tagging are completely subjective. I gave use cases, situations where current tagging could cause harm, figures that clearly question the establishment of tagging subject to concerns. Past changes clearly shown that people are able to provide more precise data on complex subjects. It's still opposed as a no go without any justification, but who knows?

As a discussion, both part should be able to provide accurate assertions and failure is collective. I agree with some comments and 14 solved points of this talk could be a good start.

Be sure I won't waste your time again, this vote is now closed for common wellness

A special mention to @Lectrician1: who provided concrete material at the beginning of this topic. It will be reused in a second version Fanfouer (talk) 11:56, 25 November 2020 (UTC)

Namespace(s) Proposal

Resolved: Namespaces won't make tagging more usable here Fanfouer (talk) 18:50, 12 December 2020 (UTC)

It seemed like at the end of voting, it was suggested to use namespaces perhaps instead of individual keys. I may be misunderstanding the whole concept of namespaces and how they are applied, but would this look like pump:mechanism=*, pump:driver=*, and pump:coupling=*? What are the pros and cons of using this classificiation?--IanVG (talk) 15:50, 2 December 2020 (UTC)

It's pretty simple: drivers and couplings aren't specific to pumps. Like actuator=*, handle=* they can be used in many systems. Then namespaces aren't so useful here, pump_mechanism=* is enough and doesn't require a namespace here. Fanfouer (talk) 22:57, 2 December 2020 (UTC)

Gotcha. And I'm just being slow here, but just to be completely clear, one should use a namespace when the value following the ":" is specific to the key? For example as with mechanism in pump:mechanism? (Even though it wouldn't be so useful here in this instance). Thanks. :-) --IanVG (talk) 16:04, 3 December 2020 (UTC)

That's not a slow but a good question actually, Namespaces have different use cases here. It can be to extend a global concept into several items (voltage:primary=*, voltage:secondary=*...) or to distinguish the same property for 2 different objects on the same OSM feature (transformer:ref=* + pole:ref=* on the same node stands for reference of transformer and reference of pole). Sometimes and in my opinion, namespaces are overused (fire_hydrant:position=* <=> location=*) or make a property over specialized, what we intend to avoid here (pump:driver=* instead of mechanical_driver=*). Fanfouer (talk) 19:17, 3 December 2020 (UTC)

Hydropower

You are correct that pumped storage hydroelectric schemes exist. However, they commonly use reversible [Francis Turbine]s for both generation and pumping.

One example is Dinorwig Power Station otherwise known as Electric Mountain --Brian de Ford (talk) 01:14, 21 December 2020 (UTC)