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
_______________________________________________
Tagging mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tagging
