Proposed features/boolean values

boolean values
Status:	Approved (active)
Proposed by:	Cohan
Tagging:	*=[[:Tag:*=yes|no|yes|no]]
Applies to:	All keys that expect a boolean value
Definition:	The recommended boolean values
Rendered as:	n/a
Draft start:	2009-10-03
RFC start:	2009-10-03
Vote start:	2009-10-03
Vote end:	2009-10-17

Contents 1 Proposal 2 Rationale 3 Tagging 4 Applies to 5 Additional comments 6 Discussion 7 Votes 8 Post-vote

Proposal

This proposal is to end the ridiculous debate that there is no definition of what boolean values to be used.

Rationale

There is currently a long debate on the talk-list about what boolean values should be used. Or rather, the discussion is about why we only are discussing this instead of doing something about it. (Because someone else should do it.) We need to end it and start making beautiful maps instead.

Tagging

yes or no

Examples:

• Instead of oneway=true/1/ja/da/japp/jej/Yes/YES/sant/recht/riktigt/korrekt/sschjo/... use oneway=yes - a oneway street
• oneway=-1 - a oneway street in the opposite direction
• lit=no - the street/path/object is not lit
• Instead of bridge=true/1/ja/da/japp/jej/Yes/YES/sant/recht/riktigt/korrekt/sschjo/... use bridge=yes - there is a bridge
• electrified=no - the railroad is not electrified

NB: These are only examples where yes|no could be used. (And should be used instead of true/1/ja/da/japp/jej/Yes/YES/sant/recht/riktigt/korrekt/sschjo/...) Other descriptive values are still valid, e.g. bridge=viaduct or electrified=contact_line

Applies to

All keys that expects a boolean value.

Additional comments

• Since other boolean values will continue to be used (yes/true/1/ja/da/japp/jej/Yes/YES/sant/recht/riktigt/korrekt/sschjo/...) renderers are, at least for the moment, encouraged to at least support the most frequently used.
• Map data editing software are encouraged to automatically change inputed boolean values to yes or no. As we have freeform tagging there is no such thing as a list of all keys that expect a boolean value, nor is there any list of all other possible boolean values that needs changing. Hence this will be needed to be limited to the most used other values. E.g. true -> yes Care has to be taken so that keys expecting numerical values doesn't receive boolean. We don't want e.g. layer=yes
• Users are encouraged to change boolean values into yes or no as other values are encountered when editing data.
• Someone with the know-how are welcome to program a bot that changes current values into yes or no. Again, care has to be taken so that keys expecting numerical values doesn't receive boolean. We don't want e.g. layer=yes

Discussion

Unfortunately, this proposal was botched by not following Proposal Status Process defined at Proposed_features#Proposal_creation_guidelines, so discussion on Talk:Proposed_features/boolean_values probably can't help at this stage, but here it is anyway.

Votes

• I approve this proposal. --Cohan 07:00, 3 October 2009 (UTC)
• I approve this proposal. --drlizau 07:14, 3 October 2009 (UTC)
• I approve this proposal. --Snoopy88 07:20, 3 October 2009 (UTC)
• I approve this proposal. --Delta foxtrot2 07:24, 3 October 2009 (UTC)
• I approve this proposal. --Gnonthgol 07:26, 3 October 2009 (UTC)
• I oppose this proposal. -- Internally this should be 0/1 what is DISPLAYED is a job for the tools Lsces 07:28, 3 October 2009 (UTC)
• I approve this proposal. -- polderrunner 07:55, 3 October 2009 (UTC)
• I approve this proposal. -- (I doubt that 0/1 as inside values for booleans is a good idea. What for layer=0/1 ? But you are right, Lsces, the display is a question of tool : yes, Ja, oui, si, da... checkbox) FrViPofm 07:59, 3 October 2009 (UTC)
• I approve this proposal. -- ck3d 08:23, 3 October 2009 (UTC)
• I approve this proposal. --Snusmumriken 08:46, 3 October 2009 (UTC)
• I approve this proposal. --seav 09:47, 3 October 2009 (UTC)
• I approve this proposal. --User:Renaud 11:29, 3 October 2009 (UTC)
• I approve this proposal. --Pobice 10:56, 3 October 2009 (UTC)
• I approve this proposal. 0/1 and true/false is too nerdy. 0/1 is used when we have technical limitations, which isn't the case here. Of course, some kind of I13N would be great, as Lsces proposed. --BraulioBezerra 11:17, 3 October 2009 (UTC)
• I approve this proposal. -- Joto 11:50, 3 October 2009 (UTC)
• I oppose this proposal. I strongly oppose yes/no as that remove the option provided by the value "-1" which is heavly used be k=oneway. IF we want to normalize the values for boolean tagging we have to use -1 / 0 / 1 as it is the only option which does not loose data. -- Petschge 12:01, 3 October 2009 (UTC)
  • How about converting -1 to maybe? --Ævar Arnfjörð Bjarmason 12:06, 3 October 2009 (UTC)
  • When using 1/0/-1, you don't know, if the numeral value "1" or the boolean value "true" is meant. But doesn't "-1" mean the same as "opposite"? So the value "opposite" should be included in the Proposal. Snoopy88 12:12, 3 October 2009 (UTC)
    • The proposal concerns the boolean values -1 / 0 / 1 is not boolean and is not concerned by the proposal. FrViPofm 12:58, 3 October 2009 (UTC)
      • none of the examples is boolean only though (check tagwatch/osmdoc). This vote is solving nothing. "-1" is generally referred to as "reverse", not as "maybe" or "opposite". The definition says, that "reverse" is "discouraged" though ;-) --Dieterdreist 14:06, 3 October 2009 (UTC)
• I approve this proposal. Values with a clearly and genuinely distinct meaning that database users following the tag are usually interested in can coexist with yes/no for some keys but synonyms should be avoided.--Wynndale 13:57, 3 October 2009 (UTC)
• I approve this proposal. -- to substitute true and false by yes and no, but I do not support the idea that the above mentioned Keys have to have boolean values. Already mentioned for oneway, there is similar issues also with the rest of it: lit (used are e.g. 24h, automatic), bridge (viaduct, swing, aqueduct, drawbridge, etc.); electrified has even most values tagged non boolean (18000 times v=contact_line)! -- Dieterdreist 14:04, 3 October 2009 (UTC)
• I oppose this proposal. true/false should also be accepted as values. --Skippern 14:51, 3 October 2009 (UTC)
• I oppose this proposal. While I do agree that "yes"/"no" should be defined as "official" boolean values, and that users are to be encouraged to change to "yes"/"no" values manually on stuff they are editing, I do not think that editing software should change that automatically (although it *should* warn the users before commiting such changes of the official yes/no suggestion - if the editor already has a validation plugin). And most of all, I'm *totally* against the idea of any bot changing such values worldwide. In general case, renderers should continue to render few most popular (in current use) negative values as negative ("no", "false", "0") and all other values as true (and such behaviour should be clearly documented). I'm also against forcing the strict type checking in the data: although 99% of the "boolean" data might really be boolean, the remaining 1% might have a good reason to be something else -- Mnalis 15:45, 3 October 2009 (UTC)
  • Show me one element tagged true or false for any key or tagged 1 or 0 for the keys Mapnik and Osmarender accept numeric synonyms for (oneway=*, bridge=* or tunnel=*) that would be wrongly tagged if changed to yes or no.--Wynndale 12:07, 5 October 2009 (UTC)
• I approve this proposal. -- Gerv 17:21, 3 October 2009 (UTC)
• I approve this proposal. Get on with it already. Alexrudd 22:05, 3 October 2009 (UTC)
• I approve this proposal. -- Waldo000000 22:25, 3 October 2009 (UTC)
• I oppose this proposal. Why bother? -- Ivansanchez 08:57, 4 October 2009 (UTC)
  • OSM’s most important product is not what you see on the website, it’s the underlying data. Having a single syntax for boolean values make it easier for people to write their own applications. --Wynndale 11:11, 4 October 2009 (UTC)
    • OSM's most important product really is underlying data. That is exactly the reason why such data should be allowed to verbose as needed, and not be forced into fixed types like boolean just to make a renderer's job a teeny tiny bit more easy. Really, forcing keys to be boolean and going from if ($value =~ /^no|false|nein|0$/) to if ($value =~ /^no$/) equivalent will not help renderers all that much; but it will make impossible for other extensions of the tag. (for example, *NONE* of the examples listed in proposal [oneway, lit, bridge, electrical] is actually a boolean value !!) --mnalis 22:51, 7 October 2009 (UTC)
• I oppose this proposal. For OSM to expand it needs to be understandable for the majority of humans, not just computer nerds/geeks. This proposal does not recognise the majority of humans dont know what a "boolean values" is, and therefore I oppose it. --Jamicu 23:32, 4 October 2009 (UTC)
  • Sorry if the word “boolean” scares you. The words “yes” and “no” are the key part of the proposal.--Wynndale 12:07, 5 October 2009 (UTC)
• I true this proposal. Oh ffs. You're all voting for something which already happens anyway. Calm down people. It is not the end of the world quite yet. Randomjunk 10:20, 5 October 2009 (UTC)
• I approve this proposal. --Vrabcak 20:09, 5 October 2009 (UTC)
• I oppose this proposal. --Socks 13:02, 6 October 2009 (UTC)
• I approve this proposal. --Ulfm 21:58, 7 October 2009 (UTC)
• I approve this proposal. -- Zkir 14:56, 9 October 2009 (UTC)
• I approve this proposal. --Kevin Steinhardt 20:37, 18 October 2009 (UTC)

Post-vote

Voting ended, the values are approved