The following picture is a part of the motorway junction Stuttgart. It shows the lanes. I am struggeling with the direction:lanes and also I am not sure about turn:lanes. I would appreciate your suggestions. Since you are the first who are using the tags, we have a lack of experience and you have the chance to make it as easy as possible for data consumers before OSM establish an own, too complicated shema...like for multipolygons ;) Currently it is tagged as follows 1) destination:lanes=Stuttgart; S-Vaihingen|Stuttgart; S-Vaihingen|Karlsruhe;Heilbronn|Karlsruhe;Heilbronn;München; Flughafen Stuttgart|München; Flughafen Stuttgart turn:lanes=through|through|slight_right|slight_right|slight_right 2) destination:lanes=Karlsruhe;Heilbronn|Karlsruhe;Heilbronn;München; Flughafen Stuttgart|München; Flughafen Stuttgart turn:lanes=slight_left|slight_left;slight_right|slight_right
How can you know which lane to take and which signpost to display at point 1 if more than one direction is going slight_right (and when you don't consider the next turn)? A human would change it it mind to turn:lanes=slight_left_then_slight_left|slight_left_then_slight_left;slight_right_then_slight_right|slight_right_then_slight_right Personally I think such situations require a lane assistant more than a easy motorway exit
This is the case where you have to combine information from both crossings and both ways (with lane and destination tag). Probably very important is that the turns (unique combinations) correspond to unique combinations destination. Turn 1|1|2|2|2 and destination A|A|B|BC|C, defines only A=1. In the second crossing 3|34|4 and D|DE|E, you can define that D=3 and E=4. And after "concatenation" you could find out, that B=D and C=E. So this example is resolvable. Note importance of exact matching of strings. I would keep the order too, if possible. I mean that you will keep the D|DE|E and not arbitrarily swap destination like D|ED|E.
At the moment "slight_left_then_slight_left" seems to me too complicated, but I would rather wait until example above is fully implemented.
Maybe one more note about destination tags. Say case 1|12, or left|left;right ... it is not possible to say properly the 2/right destination, unless the texts are concatenated, i.e. A|AB, so you can guess that 2=AB-A=B
OK, sounds good. But please let me ask another question: How do you know that you have to combine the information for 2 junctions? I mean such situations don't only exist on motorways but also in city areas. Would it help you in the above example if at 1 is an extra tag like? turn:lanes=through|through|slight_right|slight_right|slight_right turn:lanes:following:slight_right=slight_left|slight_left;slight_right|slight_right
Destination lanes can be similar
Maybe one more note about destination tags. Say case 1|12, or left|left;right ... it is not possible to say properly the 2/right destination, unless the texts are concatenated, i.e. A|AB, so you can guess that 2=AB-A=B I still think about a delimiter because quite common is left;through|through;right with destinations AB|BC
I suppose that the first issue is to correctly split destinations among lanes turns. In your example left;through|through;right with AB|BC destinations you can guess that the common part (end of first and begin of second) B should be assigned to "through". But I believe that there will be cases like single line "through;right" and destination "A;B;C" where you cannot guess if B belongs to 'through' or 'right'. It could be even possible that all ABC should go straight?? Would "empty separator" help? [I do not know if it is used in OSM], ie. "A;;B;C" means through=A and right=B&C?? ... this would be for cases when general heuristics does not help.
Once you have turn assigned to direction, you may check, that the same turns correspond to the same destinations. If not, you will have to follow the link to the next crossing to make the decision ... what do you think?
I am currently discussing the possibility to split destinations for lanes that go to more than one direction in the OSM Forum. Current idea: turn:lanes=slight_left;slight_right destination:lanes=[A;B;C][D] -> ABC goes left, D right. This would also help to prevent complex string comparisons
I have also contacted the guy who created the turn:lanes and destination:lanes proposal in OSM to discuss with him different possibilities. Before we document something, I will provide it here for you comments
Is there any update? I tried to integrate simple "string matching" mentioned sooner and I was a little bit surprised that for germany_osm_north changed only 4 crossings/blue signposts:
But I have not edited the OSM Wiki. There is a meeting planned about such tagging later this year. This will not be limited to turn:lanes and destination:lanes but also to other road characteristics. The meeting shall be with OSM mappers and automotive suppliers active in the car navigation/automation area. If you are interested to attend, I can ask. I would appreciate your attendance because you are most advanced with using OSM data and know better than anyone else where the problems are currently with using road attributes from OSM data. The goal is pushing the tagging schema
If you are interested, I can post a link here which shows on a map where destination:lanes and turn:lanes information are currently in OSM/Europe data. I am just updating the database.
if you follow this way http://www.openstreetmap.org/browse/way/203676200 in direction München(very long turn lanes, 2x splitting turn lanes and destination signpost that ask you for using specific lanes 2 turns before instead of one) you get a tricky situation. I come across there every day I go to the office...just in case you need an test example for your micro routing.