Proposal talk:Pipeline valves proposal

Better example

"A domestic globe valve installed on heating radiators. " - I would change this example, current one suggests that it is OK to map individual radiators Mateusz Konieczny (talk) 16:21, 26 November 2018 (UTC)

Yes it does. Since indoor and micro mapping are possible in OSM I don't see any objection to map individual radiators as common and wide used devices. Fanfouer (talk) 18:04, 26 November 2018 (UTC)

sensors

Resolved: Moved to sensor:position=* Fanfouer (talk) 20:42, 3 December 2018 (UTC)

The sensors that are proposed all sense the position. Other sensors are for temperature, pressure, humidity etc. It may be better to have sensor:position=* to allow for these other sensors in the future? Warin61 (talk)

Great point, thank you. It's consistent with man_made=monitoring_station which relies on sensors. So I've moved to sensor:position=*. Fanfouer (talk) 20:42, 3 December 2018 (UTC)

Use namespace or not

If the keys are moved to a namespace (valve:handle, valve: actuator, valve:handle,...), I would wholeheartedly agree! So we have major keys for more or less very little items! --Waldhans (talk) 21:31, 16 December 2018 (UTC)

What if we need those keys for other items? Actuators, sensors, handle aren't specific for valves (railway switches, power switches, road bariers...), no need for a namespace. Fanfouer (talk) 22:16, 16 December 2018 (UTC)

then you should add useful examples into the proposal. What do you want with ' turn_to_close'? A new major key should have it's own proposal! --Waldhans (talk) 22:53, 16 December 2018 (UTC)

The keys valve=*, actuator=*, handle=*, sensor:position=* and turn_to_close=* are introduced here for valves, which doesn't prevent anyone to use them for anything else if applicable. Examples are given for all of them and their introduction is clearly written in the Proposal chapter. Fanfouer (talk) 23:41, 16 December 2018 (UTC)

I vote no for the same reasons of Waldhans. Tags of this kind should be adequately namespaced. It is true that the same "keyword names", like "actuator", can be used in other contexts too, and this is exactly the reason why I think they should be namespaced, to create a valid taxonomy. (BTW, I think the thermostatic valve pictured in "Domestic devices" is a diaphragm valve, not a globe valve.) --smz (talk) 23:23, 16 December 2018 (UTC)

Then what about widely used location=*, usage=* or less used switch=*, substation=* (valid for both pipeline=substation and power=substation)?

I remember of fire_hydrant:position=* which literally means location=* but only valid for hydrants (a bit inefficient regarding the time needed to properly define and document a single key).

No values of actuator=*, handle=* or sensor:position=* are restricted to valves. An electric motor can also be used on any device. Namespacing may be required when whole set of values is restricted to a particular concept.

As often, I'm a bit disappointed those useful comments rose during the voting period while a RFC has been announced on @tagging. Fanfouer (talk) 23:41, 16 December 2018 (UTC)

I asked for a POSITIVE example for your proposed main keys. Your sentence 'electric motor can also be used on any device' shown for me that you did not consider the complications of introducing 4 new top-level keys. --Waldhans (talk) 00:08, 17 December 2018 (UTC)

Well, pipeline=valve + actuator=electric_motor is a valve which the state can be changed with the help of a (remotely controlled or not) electric motor, just like an electric railway switch : railway=switch + actuator=electric_motor. Would you prefer valve:actuator=* and railway:switch:actuator=* for the exact same concept? Fanfouer (talk) 00:18, 17 December 2018 (UTC)

Have a look to man_made=street_cabinet which can host a telecom=exchange. According to your logic, instead of man_made=street_cabinet + street_cabinet=telecom + telecom=exchange + exchange=... I should use man_made:street_cabinet:telecom=exchange and this sounds not very fine. Note that telecom=exchange can actually go in man_made=street_cabinet and in building=service but I won't define street_cabinet:telecom=exchange and building:telecom=exchange because telecom=exchange is enough to define the concept Fanfouer (talk) 00:26, 17 December 2018 (UTC)

No: I would like it to be pipeline:valve:actuator=* and railway:switch:actuator=* --smz (talk) 00:28, 17 December 2018 (UTC)

Please consider my previous example with man_made=street_cabinet. This is really not contribution friendly and it will split exactly same documentation in hard-to-maintain wiki pages

You try to make OSM tags looks like a tree while I play lego with them. That's not exactly the same game and yours doesn't bring more information in a more complex tagging than mine Fanfouer (talk) 00:46, 17 December 2018 (UTC)

Your example is, IMHO, ill formed, that's not how "namespacing" works. The rationale for namespacing is to differentiate domains. Instead of "actuator", try thinking "switch": the same term apply to very different things, like an electric switch and a railroad switch. Here, in OSM, the railway switch is correctly namespaced, the power switch is not. But... can't we just agree to disagree? --smz (talk) 00:59, 17 December 2018 (UTC)

I respectably disagree to split same terms between different domains. Concepts and tags are time consuming to define and maintain and I'm happy to re-use something someone took time to properly define. I was particularly unhappy to be unable to re-use anything from railway switches when I proposed switch=* for power features. I didn't understand any benefit from namespacing while I tried to elaborate on advantages to reuse something existing Fanfouer (talk) 01:18, 17 December 2018 (UTC)

I don't see Fanfouer as being against namespaces, he uses them when it's needed, for instance for sensor:position=*. Namespaces make sense when 2 keys could be in conflict, like in the previous example with the monitoring station. Smz seems to value more a tag not prefixed than a namespaced tag. That's subjective, nothing in OSM implies that. A power switch and a railway switch can't be confused. Where I could agree with Smz is when the possible values radically differ. Or if the key is too generic (like type or category) but then the name of the key is an issue anyway.

Smz, can you please elaborate about the supposed issue about introducing new "top level keys"? Fanfouer mentioned advantages of not using namespaces here. If you're using switches, you already know if it's an railway=switch or a power=switch, so where is the added value? On top of that when you inject the data in the database you can filter out or map according to your needs. Do you intend to loop inside actuators for instance from the wild? I can imagine default values would be less practicable when not using namespaces. As for me this is a small drawback, nothing compared to the advantages of not reinventing the wheel again and again.

No problem to disagree (or not) but I'd like to understand your reasoning.

--Nospam2005 (talk) 19:58, 17 December 2018 (UTC)

I am still waiting for an example how to use turn_to_close in any other context. This is still my main concern. If you introduce top-level tags, you should give a reason and useful, positive examples. The argument "it is bad somewhere else, so I can make it worse here" is not sufficient. --Waldhans (talk) 11:27, 18 December 2018 (UTC)

You can use it for a door that is closed with a wheel for instance. Note: I would have used a namespace here but you see that it can be properly reused. --Nospam2005 (talk) 14:46, 18 December 2018 (UTC)

then you should write a proposal for it, since you made it a top-level key. Then we will discuss about door handles.--Waldhans (talk) 19:13, 18 December 2018 (UTC)

Why "since"? In order to create properly tags we create proposals, here Fanfouer created one. It is not said anywhere that each single top level key requires a specific, stand-alone proposal or did I miss that? --Nospam2005 (talk) 21:22, 18 December 2018 (UTC)

First all all, Yes, I would prefer a separate proposal for each new top-level key. If I would add the sentence “With your Yes vote you agree that turn_to_close* has now the same priority for OSM like highway=*", I assume your Yes votes will be revoked! So the proposal is somehow cheating. A very narrow-topic to refine pipline-mapping is cluttering the whole namespace. I would suggest you check the very detailed railway-namespace for a precise mapping using only one top-level key! --Waldhans (talk) 22:18, 18 December 2018 (UTC)

Come on, why didn't you object this point of view during RFC? I don't see priorities in keys, only adjacent topics. Pipeline mapping isn't narrower than highway mapping. There are people who want to spend time on highways and other that want to spend time on pipelines. They meet when they are using common keys and this is great because you take advantage of the community.

I wasn't aware that using the lowest amount of so called top level keys was a goal in OSM. Railway tagging have one issue: common concepts can't be reused since every key is namespaced under railway:. That's not a good news since the time you invest in railway tagging definitions and documentation can't be used elsewhere and that's not what I propose in OSM. Have a look to power=* to see how it's possible to map things with as many keys as needed. Fanfouer (talk) 19:22, 19 December 2018 (UTC)

Power is also a good example: 2 top-level key "power" and "line: for the whole domain.You have, under the domain pipeline, 5 top-level keys just to describe a valve. Don't see the difference? What I don't understand is your unwillingness to use a namespace. The discussion in the forum is quite clear in favor of namespaces for special interest groups. Just prefix your keys with "pipeline:valve:", e.g. pipeline:valve:handle=wheel and pipeline:valve:turn_to_close=anti_clockwise and everybody will be give you standing ovations! And this is prefect readable! --Waldhans (talk) 21:15, 19 December 2018 (UTC)

I don't have the same reading. Power actually implies many keys : power=*, transformer=*, switch=*, converter=*, generator=* (namespaced), substation=* (shared with pipelines especially for heating and gas), line=*, voltage=* (namespaced for transformers, see voltage:primary=*), windings=* (namespaced for transformers : windings:configuration=*), and so on. None of them have power: suffix. You're invited to read the proposals for switches and transformers. Other major keys like location=*, man_made=street_cabinet are massively used also. Namespaces are used when necessary. This took years of documentation gathering, redaction, proposing and then use worldwide.

I didn't proposed pipeline:valve:actuator=* or pipeline:valve:handle=* because I want to document valves and share concepts with other topics (actuator can fit for railway switches, road barriers including movable bollards), as to reinforce the whole usage, documentation and, most of all help others. Again, the last is completely forgotten in railway namespace because we can't reuse anything. I agree that I could have chosen to propose each tag separately, is this my only mistake? Fanfouer (talk) 21:46, 19

December 2018 (UTC)

I am tired of dot counting, so start again at the leftBold text

Again, you are argumentative negative. Others did bad, so I could do worse. I assume now you have software background, otherwise you would know about the problems with namespace pollution. So you should take it granted that is OSM we have already problems with tags like "bicycle=*" used in access AND in the information=guidepost context. That's exactly the wrong case of re-use making headache for any QA-Tool. And to your re-use (note: you still don't provide ANY POSITIVE example!!!!). railway:switch: is using electric=yes/no, so no need for actuator (there are no pneumatic_cylinder,hydraulic_cylinder,thermostatic,solenoid railway switches!!!!). All this is domain-constraint to you pipelines, useless outside your domain. So, you are excellent describing your special domain. Inside the domain, you can control the usage and value and validate it (turn_to_close will require handle=wheel). Outside of the pipeline world .... I don't know and you don't care. --Waldhans (talk) 23:41, 19 December 2018 (UTC)

Nor power nor pipeline are my domains, OSM is not your project. People are doing working things despite you don't like this. We provided both examples (door for handles, movable bollards for actuator) and a vision to stop using namespaces to build walls between people. Then I hope this is clear for anyone who get reading so far here. Let's see the vote result in 15 days.

turn_to_close=* can be usually combined with handle=*. It also works with handle=lever : image. Fanfouer (talk) 00:18, 20 December 2018 (UTC)

very impressive pipeline image (your proposal) --Waldhans (talk) 00:50, 20 December 2018 (UTC)

And to your voting remark: do you really believe that your Yes voters agree that turn_to_close is now equal important as building=*, highway=* and landuse=* ???? If you say yes, ask the question on your voting page ....

I am confused: you don't know about namespace pollution and now you say don't know about pipelines. Are you you writing the proposal for somebody else or is this just some semantic misunderstanding?

handle=wheel on a door.

actuator=hydraulic_cylinder on a movable bollard

There are many ways to find building=* more important than landuse=* despite they're both top level keys in namespace point of view. Fanfouer (talk) 18:52, 20 December 2018 (UTC)

dot count overflow.
So go forward and make a proposal for handles, if you are so sure that's useful for the OSM community. The same for actuator, if you real believe that this make sense. For me bollard=rising is enough information, and I assume that's true for almost all mappers. So don't hide your information in talk-pages, go forward and demonstrate the useful of your top-level keys in separate proposals/wiki pages (which you must create anyway).

Well, before asking me to do more work that I should actually do to achieve the introduction of some keys I find relevant according to the OSM proposal process, try to make your views of namespace adopted worldwide on your own. I didn't see any of what I'm currently blamed for on the tagging principles, did you?

Your objections were finally found brutal and not respectable of the work I provide on my spare time. I'll be pleased to read what you are proposing to rename dozen of thousand existing keys as to solve just no concrete issue Fanfouer (talk) 00:01, 21 December 2018 (UTC)

Other valve-related keys

Most gas valves for maintenance are located underground behind a street cap or a manhole cover. But the existing manhole=* doesn't fit well into the man_made=pipeline scheme ( see: Talk:key:manhole ). Shall we furthermore use the provisional key manhole=* in conjunction with valves? I propose (besides pipeline=manhole ) a pipeline=street_cap in combination with size and label. --Schröcker (talk) 23:32, 8 January 2019 (UTC)