[OSM-talk] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Rob Nickerson]

Dear List,

{This is a cross post - please reply to the tagging mailing list or the
proposals [2] talk page. Please forward to local mailing lists as
appropriate }

- - - Announcement - - -
Several attempts have in the past been made to develop a tagging scheme
that is capable of handling the more complex access restrictions (e.g. No
motor vehicles between 10am and 6pm except vehicles less than 5 meters
[1]). Voting has started on the latest proposal [2]. Due to the wide reach
of this proposal, I am announcing it here and encouraging users to
carefully consider the proposal and vote.

To help, I have summarised the alternate proposals (in alphabetic order and
including this one) [3]. Note that not all of these are in active
development. I have also attempted to write the case for and case against
this proposal.

As a reminder of terminology, a Tag consists of 'Key' and a 'Value' pair
(key=value). For example "maxspeed=80".


- - - Case "For" - - -
Extract by the proposal author from the proposal's wiki page [2]:

//start quote// This proposal overcomes some objections to previous
attempts at tagging conditional restrictions.

* No variable parts in the key. This is essential as keys are used to
search for data in the OSM database. If a key comprises a variable part it
can no longer be retrieved during search unless you know the exact
condition you are looking for (database searches do not allow wildcards in
search keys). Variable parts in keys will also lead to an undesired
proliferation of unique keys.

* Avoids the requirement for problematic characters in the key such as "<"
or ">"

* Clear distinction between scope (transportation mode, vehicle class) and
condition.

* Possibility to combine conditions using operators.

* The conditional restriction can be defined as a single tag. Some prior
proposals required multiple tags such as hour_on and hour_off tags. For
objects having multiple restrictions this could lead to problems (which
tags belong to which restriction?)

* The syntax of the key is essentially identical to the established access
key syntax with an additional qualifier ":conditional".

* Backward compatible. Doesn't break any established tagging schemes.
//end quote//


- - - Case "Against" - - -
Extracts from those who have currently (18/09/2012)  voted against the
proposal:

//start quotes//
* Breaks a lot of tags which came "natural" to the mappers, e.g.
maxspeed:wet=80 becomes maxspeed:conditional=80 @ wet, access:disabled=yes
becomes access:conditional=yes @ disabled, …

* Creates arbitrary distinctions: depending on whether something is defined
to be a transportation mode or a condition, it belongs either in the key or
in the value, e.g. "hgv" is a transportation mode, but "hazmat" is a
condition

* Has bad editor support: adding a conditional restriction like "speed
limited to 80 when wet" to a set of ways is quite complicated if there are
already different restrictions on those ways; merging :conditional tags in
JOSM by default produces a value that is completely wrong, yet cannot be
identified as wrong.

* It's to difficult for users, not intuitive. There are too many subkeys
and subvalues. I think value with logic instruction (AND) (and maybe
special/new signs (@)) are not good tagging rules.
//end quotes//


- - - How to Vote - - -
0. Take a moment to conside the pros/cons and their relative importance /
how would you do it differently?
1. Log-in to OSM wiki (as far as I know this is not your usual OSM
username/password.
2. Navigate to the proposal page [2]
3. Click edit (to the right of the "Voting" heading
4. Add "{{vote|yes}} --~~~~" or "{{vote|no}} --~~~~" after the existing
votes.



Kind Regards,
RobJN

[1] Example Signpost:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
[2] The Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
[3] Summary of alternate proposals:
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120918/bf68bd38/attachment.html>