Hi,
You could combine "Conditional restrictions" and the lanes suffix¹:
[...]
psv:conditional:lanes = | | yes @ rush_time
There are a couple of issues here
1. I did not include 'lanes' when I created the "Conditional
Restrictions" scheme (mostly not to complicate the discussion and voting
process of the proposal). It could be done as suggested by you. However,
I would prefer to write the key as psv:lanes:conditional in order to be
consistent with other uses of conditional where the unconditional and
the conditional tags can be distinguished just by the :conditional
suffix. I may add this to the wiki page.
Disagree. Both variant express a different meaning:
<key>:lanes:conditional expresses that all lane values depend on a
condition:
maxspeed:lanes = 100|80
maxspeed:lanes:conditional = 80|60 @ So
<key>:conditional:lanes expresses that the conditional restriction
values depend on the lane:
maxspeed:lanes = 100|80
maxspeed:conditional:lanes = 80 @ So |
For practical tagging I think it is too theoretical for most mappers to
understand the difference.
For mappers and parsers it might be easier to request using parenthesis
around conditional restrictions/values containing special characters:
maxspeed:lanes:conditional = maxspeed:conditional:lanes = (80|60) @ So
- or, 2nd example above -
maxspeed:lanes:conditional = maxspeed:conditional:lanes = 80 @ So |
The values are unambiguous (giving '|' technically a higher precedence)
and the order of suffixes no longer matters. Then we can propose a
preferred order.
This way we also solve the issue with multiple values separated by ';':
access:conditional = (delivery;forestry) @ So
martinq
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
