[Tagging] Multi-value tagging and Lane Groups

[Colin Smale]

On 08/02/2012 16:00, Martin Vonwald wrote:
> What you describe is proposed here: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension
>
> Martin
>
Martin, I had looked at your proposal, and I can see some similarities 
and some differences. Both of us would like to have a generic system for 
describing attributes of the lanes. The differences are, I think, 
largely a question of syntax rather than concept. What triggered my post 
was actually a comment by Martin K who also felt a need for multi-value 
tags (i.e. arrays) in the context of the floors within a building. There 
are undoubtedly other applications for this concept where a single OSM 
object actually represents a collection of subobjects. Someone might 
point out that relations are intended for exactly that purpose, but they 
get rather unwieldy if they need to be applied at such a low level and 
introducing them for lane tagging is going to break things big-time if a 
road is to be modelled as a relation containing ways representing 
individual lanes.

You suggest using the "content" tag as the first tag(s), then appending 
":lanes=value|value...". As the "content" tags are already hierarchical 
in many cases, this means the lane-specific information is at a variable 
position in the hierarchy. I suggest putting the "lanes" qualifier in 
front, allowing arbitrary tag hierarchies to follow at a fixed location.

My bus lane proposal:
     lane:1:access=no
     lane:1:bus=yes

Your bus lane proposal:
     access:lanes=||no
     bus:lanes=||yes

Your proposal introduces the "lanes" tag into the "bus" namespace, and 
similarly into the namespace of many other very common tags. My proposal 
leaves the current namespaces unchanged, and allows for any future 
tagging extensions without impacting the "lanes" information.

You introduce a new tag "applies_to" to limit the lane to a certain 
class of vehicle, whereas I suggest reusing the existing "access" tags.

There are already (as you note in your proposal) turn restriction 
relations. If they are to be applied to lanes, maybe the way should be 
split for the 50m or so in the approach to the junction, and then we 
won't need a new construct. There is also a relation type 
"through_route" which provides a strong hint to routers which path 
across a junction should be considered "default".

Best regards,
Colin