Talk:Proposed features/Pumping proposal

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

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. 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: vs - 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)


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


Resolved: pumping_rig is proposed for deprecation as it mixes a well and a pump basically Fanfouer (talk) 21:40, 30 March 2020 (UTC)
  • 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)


Resolved: A siphon can be used as a pump according to this architecture Fanfouer (talk) 22:25, 21 March 2020 (UTC)
  • A siphon is not a type of pump: "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

Resolved: A pumpjack is a combination of a rotating source and motion adapter that conform to driver definition of the proposal Fanfouer (talk) 21:32, 30 March 2020 (UTC)

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 and,, --Jeisenbe (talk) 00:00, 22 March 2020 (UTC)

Fan velocity extracting.jpg
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)


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)

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

Disregard: Choice is made to reuse pump key for mechanism and move drivers to a new keyFanfouer (talk) 23:06, 21 October 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)