[Tagging] Multi-value tagging and Lane Groups
Martin Vonwald (Imagic)
imagic.osm at gmail.com
Wed Feb 8 20:09:11 GMT 2012
Am 08.02.2012 um 18:48 schrieb Colin Smale <colin.smale at xs4all.nl>:
> 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.
Actually I do agree with you. A prefix would make more sense. For a computer, for a program, for everyone who studied computer science. But for the average human? I'm not so sure about that. And we always have to remind ourselves, that a large number of mappers don't know about namespaces and actually they shouldn't. We don't gain anything if we agree on some perfect format which is a beauty as a data format, but we don't get data because only a few can handle and understand the format.
>>> 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.
The connectivity relation (maybe we need a better name) does not set any restrictions! It just states what markings are on the road and what lane connections are present, which are not obvious. This information is necessary for navigational devices to tell you on which lane to stay. It is not sufficient to know, that you need to be on the right-turn lane to turn right (surprise! ;-) ) but the navigational devices needs to know which lane leads to this right-turn lane to give you precise instructions.
>>> 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
>> 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.
If I am on a right turn lane I am still allowed to switch to a straight lane (usually), before(!) the junction. If you split the way you state, that this is not allowed, which is wrong.
> 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
>> 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:
If it is not documented it doesn't help a lot. First we would need some usage statistics and if it is really widely used someone needs to write the documentation. Thanks for this information!
More information about the Tagging