[Tagging] Multi-value tagging and Lane Groups

Colin Smale colin.smale at xs4all.nl
Wed Feb 8 17:48:16 GMT 2012

On 08/02/2012 17:52, Martin Vonwald wrote:
>> I suggest putting the "lanes" qualifier in front,
>> allowing arbitrary tag hierarchies to follow at a fixed location.
> This was suggested, but dropped for better readability: see "Default
> values; minimise ambiguity" on the Discussion page.
Yes, I see that now. I guess beauty is in the eye of the beholder. Tag 
lists are intrinsically unordered, so any sorting will be done by a 
machine. I admit it will have to think a bit harder to sort 
"lanes:1:psv=yes" adjacent to "psv=no". But my (not-so-humble?) opinion 
is that the way the data is modelled is more important than the sort 
order of a list of tags. I spend my working life surrounded by data 
models, and regularly see at first hand how "expedient and pragmatic" 
solutions can come back to bite you later. OSM's tagging is dynamic, 
open and free. We cannot predict to what uses OSM will be put in the 
future, so we should implement things in a way that does not impinge on 
future creativity. My rationale is that having "lanes" as a prefix keeps 
it more out of the way of future changes.

>> 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.
> You missed here the point, that this tag is part of a new relation,
> which handles lane connectivity.
Can you give an example of when this would add something to the mix, 
compared to a restriction relation following the current specs plus the 
lane information? If there is no right turn from a left-hand lane, 
wouldn't the left-hand lane just be tagged for left/straight only? You 
say yourself that it will rarely be needed. This whole idea feels like a 
solution looking for a problem.
>> 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.
> That is a very bad idea. Splitting the way would mean, that there is
> no possiblity to switch between the lanes (as they are separated),
> which in reality often is not correct. This would also break routing.
Where I am (NL) it is actually an offence to not follow the arrows on 
the lane in which you are driving. So if you are in a left-turn lane 
(marked as such), you must turn left. In theory at least... But I agree, 
this will not be the case everywhere. If a road is still modelled as a 
single way, further detailed at the lane level, I don't see a need for 
turn restrictions at the lane level, only at the way level. So maybe my 
comment was irrelevant anyway.

Why do you think this will break routing though?
>   There is also a relation type "through_route" which provides a
>> strong hint to routers which path across a junction should be considered
>> "default".
> Could you please provide a link to this relation? I couldn't find
> anything in the wiki for it.
Indeed, it doesn't seem to be documented on the OSM wiki. I found out 
about it through mkgmap, which uses it. It works well and is very useful 
for improving routing instructions. You can read a bit about it here:



More information about the Tagging mailing list