[Tagging] Feature Proposal - Voting - lanes General Extension
imagic.osm at gmail.com
Tue Mar 6 12:11:56 GMT 2012
> The much more relevant precedent are existing attempts to tag lanes. One
> example is indeed lanes:forward/backward. But there are other examples for
> existing lane tagging which are also documented on the wiki, and used more
> frequently than your example according to taginfo:
> ~ 11.500 cycleway:left/right
> ~ 10.000 footway=left/right, 22.000 if you count "both" (same proposal)
> ~ 4.500 footway:left/right/both:*
As far as I understand, those are ways next to the carriageway.
>> I also think that we should clearly separate those approaches:
>> backward/forward for the directions of the ways/lanes and right/left
>> for anything next to the ways. This would be consistent. At least in
>> my opinion.
> My suggestion for separating the approaches is:
> * Physical placement of things relative to road centerline: left/right.
> * Legal restrictions depending on driving direction: forward/backward.
And this would be a complete show stopper. What you suggest is to tag
one property with :left/:right and another with :forward/:backward. So
The same lanes and different suffixes. Sorry, but something like this
I can simply never support. It is completely inconsistent and
> But I have another question: Do you use :forward/:backward strictly as
> * "forward" = right of the central divider/lane(s) if right-hand traffic
> * "backward" = left of the central divider/lane(s) if right-hand traffic
> * "forward" = left of the central divider/lane(s) if left-hand traffic
> * "backward" = right of the central divider/lane(s) if left-hand traffic
> Or would it be possible for hypothetical weird road layouts that the two are
> mixed somehow, i.e. that there is a "backward" lane between two "forward"
I use it exactly the way as it is used right now. Usually this means:
right-hand-traffic: backward | forward
left-hand-traffic: forward | backward
In case of lanes running in both directions (like center lanes) this
is extended to:
right-hand-traffic: backward | both-ways | forward
left-hand-traffic: forward | both-ways | backward
Note: both-ways is not used at the moment. It is a suggested extension
- see below.
> Because if you technically allow mixing of lanes, rather than enforcing a
> clear split between 2 parts of the road (or 2+1 with center lanes),
> renderers can't determine the lane arrangement *even if* they know about the
> local left-hand/right-hand rule.
In case of mixed lanes this would be tagged like this:
This part is excluded from the voting, as I am not 100% satisfied with
More information about the Tagging