Proposal talk:Lane directions
- Nice idea. This might be very useful for routing. Maybe you should add a "T" option for designated tun-over lanes. How would you tag intersection where you can turn half right and sharp right (or left)? I would prefer a name like "lane_directions" over "lanes_sign" because I think you want to tag the directions to which the lanes are leading and not the fact that there is an actual physical lane sign. --SnakeBDD 10:41, 31 May 2010 (UTC)
How about non-oneway roads? – Nikerabbit 12:23, 31 May 2010 (UTC) ---
- Actually, I don't care about the name at all :) It was just the first thing that came into my mind. You're right, "lane_directions" is better.
Concerning "T" option. I'm not sure it's needed, because in Ukraine if you are allowed to turn left, you are automatically allowed to make U-turn if it's not prohibited exactly here. Concerning intersections with half turns and sharp turns. The biggest problem of my proposal is that I make one sign as one jpg-file. So if you chose L_L_S, it must correspond to file L_L_S.jpg. I made signs/files with all combinations of directions for two and three lines. But try to imagine how many combinations can be on a road with 4, 5 and more lanes. Of course, it is possible to create files for all combinations, but I think it would be easier to make a script or something that will create a sign on the map using the same definition for lanes (L for left turn etc.) Unfortunately, I'm not a programmer and I don't know how to do it. Maybe, some additional keys should be made, like higway=lanes > lanes=3, then a form with multiple choice for every lane should appear, where one can chose the direction: U-turn/Left/Sharp left/Half left/Straight/Right/Sharp right/Half right.
- to Nikerabbit: It doesn't matter if a road has one-way or two-ways traffic. The tag should be placed before an intersection, so there will be no misunderstanding.
Example:
--nyoma 16:08, 31 May 2010 (UTC)
- Don't mind about that rendering issue. I don't think that this would be a big problem for programmers of a rendering engine. I think it is sufficient to provide sample images for every possible combination for one lane. A program can then put these next to each other to render the sign. Anyway, most renders will prefer a custom style for their map, so I don't think that you have to provide these images. But they are useful to demonstrate your idea in this proposal.
- Concerning the "T" option: there are few intersections here in Germany where you have designated turn-over lanes. It wouldn't hurt to allow the "T" option to map those.
- On the two-way roads issue: I understand Nikerabbit's concerns. I think you should add this tag to an existing road instead of adding a note where the physical sign is installed, what is what you want as far as I understand you, Adding an extra node just for this issue somehow doesn't feel right. You could tag only the last segment of the road in front of an intersection with this tag. In most cases It will be clear which direction is meant by the tag (the one leading to the intersection node). But we have a problem when there are two intersection nodes next to each other. In that case, we cannot tell to which direction the tag applies. A possible solution would be to add a new node between these two nodes. --SnakeBDD 13:48, 31 May 2010 (UTC)
- No problem with providing the images as well as with the "T" option. I'll do it. Concerning two-ways roads: Your ideas to place the tag on the last segment and to add one more node is good. I thought about it too. Besides, in some cases there is no need to add new node because you may use the segment between the first crossing and the next one.
For example,
- I made changes to http://wiki.openstreetmap.org/wiki/Proposed_features/lane_directions
What do you think about it?
I like this proposal, but with two concerns...
1. You appear to be trying to define every possible combination of turning options. That can be a long list, and the real world has a nasty habit of coming up with things that you hadn't thought of. It seems to me a better approach would be to simply define all the single turn options that seem reasonable, and allow the tag to contain multiple values to create combinations. For example, the values could be something like:
- LU (or left_U)
- LS (or sharp_left)
- L (or left)
- LH (or half_left)
- S (or straight)
- RH (or half_right)
- R (or right)
- RS (or sharp_right)
- RU (or right_U)
Then the tag can contain multiple values separated by a semicolon as I've seen done with other OSM tags. The editor could present a short list of checkboxes that can be checked in any needed combination. This allows the flexibility to represent unusual (but still quite possible) combinations that this proposal doesn't mention, such as:
lane1_directions=LS;LH;S;R (obviously, a single-lane road)
This approach would also make it much easier to add new possible turn values should the need arise (though I'm not sure right now what else there could be).
Likewise for rendering, there need not be a pre-drawn image for every possible combination of turns for a lane. The renderer can have a solid background image, and a separate arrow image with a transparent background for each possible single turn value. Then it can layer arrow images on top of the solid background to produce any combination of arrows it needs.
2. Having lane numbers in the tag name bothers me. That seems like something which would be a significant annoyance to renderers and other programs trying to parse the tags. What about having a single tag name, with the lane number in the value? When reading the tag, turn options following a number would apply to that lane number, until another number is reached in the data. So your example in the proposal:
lane3_directions=Straight_ahead, lane2_directions=Straight_ahead, lane1_directions=Right_turn_Straight_ahead
could translate to:
lane_directions=1;R;S;2;S;3;S
Or maybe have the lane numbers followed by a colon:
lane_directions=1:R;S;2:S;3:S
As for whether to count lanes from the right or left.... Here we count them from the leftmost lane, but I don't see that either way is better than the other. Regardless of which approach is decided on, hopefully everyone will follow that guideline. :)
--Diggernet 01:44, 3 June 2010 (UTC)
- You could remove the issue on whether to count the lanes from the right or left by removing the lane numbers entirely, and instead add the directions in the same order as the sign should look when rendered. For example:
Left_turn
Straight_ahead and Right_turn
Straight_ahead and Right_turn
- Counting lanes from right-to-left this would be:
lane_directions=1:Right_turn, Straight_ahead;2:Right_turn, Straight_ahead;3:Left_turn
- but
- Counting lanes from left-to-right this would be:
lane_directions=1:Left_turn;2:Right_turn, Straight_ahead;3:Right_turn, Straight_ahead
- By removing the lane numbers completely, both of these could described in the same way and be simplified to the following:
lane_directions=Left_turn;Right_turn, Straight_ahead;Right_turn, Straight_ahead
- --mso 13:59, 30 December 2010 (UTC)
I seems that I defined almost all possible directions, at least the most common. I made images only as an example of these most common directions. Concerning tags: I already said, that I'm not a programmer, so I just gave an idea. All your suggestions are very useful. Thank you! One more question: in this case lane_directions=1:R,S;2:S;3:S can I use comma instead of semicolon to define different directions of one lane?
- Oooh, very nice! Not only does it look better with commas, but that also makes it easier for a program to process the string. --Diggernet 17:48, 3 June 2010 (UTC)
turn restriction syntax
IMO this proposal should inherit some of the syntax from turn restrictions. TLA is not very human readable, and is very prone for edit errors. Syntax such as no_left_turn and only_left_turn is plain to see for anybody editing, and is just as easy to parse for any program. If the original syntax of turn restrictions fall short, add further keywords i.e. only_half_left, and problem should be solved. --Skippern 19:13, 30 July 2010 (UTC)
Why not to draw separate lanes
Any syntax you come up with will get awkward for roads with more than three lanes in one direction. Why not to tag each lane individually?
- it would look more realistic on the map and in the editor
- you can still add the turn restrictions/signs for each lane
- you get the information in which lane you should end up after the junction
- I've made some drawing on paper how this would be tagged, you will end up with drawing each lane and then adding each turn direction to each of the lanes. I'm not saying this is impossible or wrong but drawing one way with a lane_directions key would be easier. For example if you've only seen one side of a junction you couldn't map it because if you use ways you would need to do the whole junction at once. I also think it would be easier for routers to parse wich way they can go on the junction as there will actually be 1 junction node instead of a lot of ways crossing and connecting with eachother. Computerfreaked 20:15, 17 October 2011 (BST)