Proposed features/Extended conditions for access tags/First voting

From OpenStreetMap Wiki
Jump to: navigation, search
  • I approve this proposal I approve this proposal. -- Eckhart 15:25, 27 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. Because this proposal is breaking a fundamental rule in OSM : a tag is a key/value pair where the key is constant and value is variable but you propose "constant:variable=variable" which makes this unusable for data consumers (or not without huge impact on performances). If we follow your syntax, "maxspeed=50" becomes "maxspeed:50=yes" --Pieren 15:49, 27 June 2012 (BST)
Please stop spreading FUD, maxspeed:50=yes completely contradicts the proposal. -- Eckhart 16:56, 27 June 2012 (BST)
Read me correctly. it's only about the syntax (variable in key) showing your contradiction with all existing practices (and not only in OSM). --Pieren 17:08, 27 June 2012 (BST)
Last I remember, you were in favor of maxspeed:conditionX, where X is a natural number, which would also fit into constant:variable=variable scheme.
About "exiting practices": if you have a look at taginfo, you can easily find out about existing practice:
  • the extended conditions proposal is in widespread use
  • source:<key>=value, where <key> is a variable referring to the key that gets annotated with a source
Existing practice outside OSM: structured tagging, which we don't have. (If you add support for structured tagging to the OSM api, I will definitely deprecate this proposal.)
Also, I am wondering where your knowledge of "unusable for data consumers (or not without huge impact on performances)" comes from - I haven't seen those performance impacts. -- Eckhart 18:17, 27 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. But I vote yes for :hgv, :wet and so on. But values like weight>5.5 shouldn't be in the key part! -- Soldier Boy 16:20, 27 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. But I approve of the old proposal without the vechicle properties in the key. I like to put them after the value instead.-- Johan Jönsson 15:03, 8 July 2012 (BST)
  • I approve this proposal I approve this proposal. Although I would have liked to see the conditions in the value instead of the key, we really need something like this, whether it's perfect or not -- Errt 18:15, 27 June 2012 (BST)
  • I approve this proposal I approve this proposal. --polderrunner 19:37, 27 June 2012 (BST)
  • I approve this proposal I approve this proposal. Aighes 20:32, 27 June 2012 (BST)
  • I approve this proposal with the exception of the "vehicle properties" section, which I oppose at the moment. I think this should be considered further before being adopted. (Might it be possible to always represent such restrictions / exceptions using a max_____:constraint=* instead? For example, access:(weight>5.5)=destination could be represented by maxweight=5.5 and maxweight:destination=none.) -- Rjw62 21:03, 27 June 2012 (BST)
This might work with access:(weight>5.5)=destination, but what about access:(weight>7.5):(22:00-06:00)=destination? Or about maxspeed:(weight>7.5)=100? (Those are real-world examples) -- Eckhart 12:40, 28 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. For the same reason as Pieren. But would approve it for not more the one subkey, which is not variable. So using "vehicle properties" or "time" is not what I want to see in any key. For complex relationships of (sub)keys, I would use (child) realations to build trees of keys/values, as the API does it not support this otherwise now. --Fabi2 21:32, 27 June 2012 (BST)
maxspeed:wet is okay, maxspeed:hgv is okay, but maxspeed:hgv:wet is not okay? -- Eckhart 12:42, 28 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. generally, I vote for no. But maxspeed:wet=*, maxspeed:hgv=* and maxspeed:night=* would be o.k. --Efred 07:02, 28 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. with a reason similar to that von Pieren: A Key should be a key, and not a variable string. Otherwise why should we in general use the "restriction" to key-value-pairs instead of a simple string for a tag? --Jongleur 09:48, 28 June 2012 (BST)
"a key should be a key, and not a variable string" - by definition, a key is always a key. "why use key-value-pairs instead of a simple string for a tag" - this is an interesting question, and the simple answer is: because the OSM database dictates it. "hotel" is probably at least as good as "amenity=hotel" "tourism=hotel", yet the proposal had to stay in the boundaries set by the OSM database. Just to recall them: features are described by key/value pairs, where keys and values are UTF-8 strings with at most 255 bytes, and keys are unique per feature. Unless you plan on changing those restrictions, you have to come up with a proposal that respects them, which the proposal at hand does, or pretend the problem this proposal solves doesn't exist. -- Eckhart 13:21, 28 June 2012 (BST)
  • I oppose this proposal I oppose this proposal, for parametric keys. --Zverik 12:15, 28 June 2012 (BST)
  • I oppose this proposal I oppose this proposal. Vote "no" for syntax, but "yes" for conditions --Ilis 12:23, 28 June 2012 (BST)
  • I approve parts of this proposal. Vehicle vategory and direction are aleady ducumented and in use. Road condition also seems fine. I can't decide on lighting condition, because I don't know a real-world example. I dislike the prantheses syntax, because it is error-prone, while it not does not make parsing easier. Time syntax should be better distinguished from vehicle properties. Maybe just leave away the parantheses for vehicle properties. But even then, their syntax is problematic. If ">" and "<" are permitted as comparison operators, people will also use ">=" and "<=". This is potentially harmful, because the "=" character is often used as the key/value separator. --Fkv 13:21, 28 June 2012 (BST)
The parantheses have the advantage that it makes parsing for human eyes easier, e.g. compare maxspeed:(weight>7.5):wet with maxspeed:weight>7.5:wet.
About "=" separating key/value pairs: we already have the same problem with : already, and sane notation uses quotes around keys/values (try to search for maxspeed:wet in JOSM).
Regarding times: there's no big difference between maxspeed:(sunset-sunrise) and maxspeed:night, why would you want to treat them seperately? (the second one is a valid time according to opening_hours)
Apparently, lighting conditions are used in the U.S., where there are black on white signs for day speed limits and white on black signs for the night. -- Eckhart 13:30, 28 June 2012 (BST)
  • I approve idea, oppose syntax this proposal. The colon shouldn't be chosen for this as the main separator, since it already has meaning in different tags that aren't conditions, like name:en etc. I also would like to see some pseudocode to determine whether something is allowed or not given certain access tags, to see how conflicts will be resolved, and to see how the access tags will be read in general by a machine. What may be natural to us may not be so easy for a computer... The lighting condition for night can be removed, since the opening hours syntax has tags for sunset and sunrise (which on its hand should be extended to allow tags like sunset+2:00 for two hours after sunset, but that's not for this proposal). --Eimai 15:30, 28 June 2012 (BST)
Here's a simple implementation: http://eckhart-woerner.de/~eckhart/extcond.html -- Eckhart 20:00, 28 June 2012 (BST)
  • I oppose this proposal. something like maxspeed:wet=* would be ok but no functions, times, formulas in the key, please. -- wambacher 09:49, 29 June 2012 (BST)
  • I approve this proposal I approve this proposal. in hope to get some improvements--R-michael 16:58, 29 June 2012 (BST)
  • I approve this proposal I approve this proposal. makes sense--Geodreieck4711 21:54, 29 June 2012 (BST)
  • I oppose this proposal. for the same reasons stated by wambacher above --mmd 18.14, 2 July 2012
  • I approve this proposal I approve this proposal. I think we really need more detailed access conditions. I would prefer a change to the OSM database in the long run though, that tackles the problem of structured tagging better though...--Extremecarver 16:07, 3 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. Conditions in the key just seems wrong. And there are other ways to express the same information - access:condition=, for example. --Opk 18:31, 3 July 2012 (BST)
access:condition is broken, since there can be different values depending on different sets of conditions. -- Eckhart 16:19, 4 July 2012 (BST)
fair enough but with some thought there would be cleaner ways to express the same information. --Opk 11:54, 17 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. Because of variable parts in the keys. I partially approve the proposal where the keys remain constant.--Surly 13:45, 4 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. Keep the key syntax simple, move all conditions to the value please. Everything written in this proposal in brackets is a particularly bad idea to cram into keys: there's no commonality due to the variable nature of conditions, and this would make things like taginfo much less useful to mappers. The conditions concept is sound, but we need to rethink it in terms of cases: motor_vehicle:case1:times=Mo-Fr + motor_vehicle:case1:maxspeed=3030 kph for motor vehicles, Monday to Friday or suchlike (maybe turn the whole thing around, e.g. access:case1:motor_vehicle=yes etc.). Still less than ideal, but it would reduce the number of unique keys created in tag databases significantly. --achadwick 01:17, 5 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. --EvanE 13:04, 5 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. Obviously not ready for a vote when so much discussion happens after the vote is started. --Frederik Ramm 13:38, 5 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. --Mondschein 07:31, 10 July 2012 (BST)
  • I oppose this proposal I oppose this proposal. The proposed syntax is inside out. It would be much easier to just add opening_hours value to some specific tag (like vehicle:opening_hours), or maybe name it vehicle:when? whatever. --Diomas 07:13, 10 July 2012 (UTC)
What you're proposing simply doesn't work, as has been mentioned several times in the discussion. -- Eckhart 15:51, 11 July 2012 (BST)

  • I oppose this proposal I oppose this proposal. and would be happier if Eckart stopped commenting on other people's vote --FedericoCozzi 25 July 2012 added after end of voting period