User:It's so funny
Mapping mostly in the Netherlands, using a Samsung Galaxy S3 smartphone with geotagged photos and the nice 'GPS logger for Android' app. In spite of having a lot of JOSM experience I always found it difficult to understand the Vespucci app. Spending several hours on a camping recently I finally managed to get it going. And I must say: Vespucci is a great piece of software which is perfect for ground-truth editing. Though I wouldn't mind seeing an easy to use (POI) editor for the masses. It would be a huge boost for OSM if (for example) 1 out of 1000 mobile phone owners would use a simple (POI) editor for OSM on a regular basis.
Especially interested in motorways, because I would love to see navi-apps for mainstream users to be competitive to commercial products. One of the things needed for that is a reliable lane-assistent.
I believe OSM still has several unexploited opportunities. Therefore I'm active in OSM's Future Group.
I'm involved in importing buildings and addresses in the Netherlands, from government data available under a public domain license: BAGimport
________________
Lane connectivity
Related topics: [1]
Rationale
For a lane assistant it's sometimes necessary to know which lanes connect to each other in situations where the lane count of one segment (OSM way) increases or decreases to the next segment, or when it's not very clear which lanes of a junction connect to other lanes of that junction.
Solution
It could in a majority of cases be done by one tag: connectivity:lanes put on the from (=incoming) way with the following values:
- split
- merge
- continue
On oneway roads it should be applied in the driving direction. The OSM way might have to be split, to apply connectivity:lanes only to the part where the actual split/merge occurs, which often is a short distance.
Pros and cons of this and other solutions
| Data stored in | Applies to KISS | Continuity | Comment |
|---|---|---|---|
|
Yes | Good | Storing the data in the way is logical in the sense that's it's a car drivers perspective. It's also compliant to the tagging of turn:lanes=*, which is also applied to ways. A disadvantage is that a way can be broken (or merged) by a novice user, though that doesn't change the lane count. |
|
Yes | Best | The connecting node could also be used for a connectivity:lanes tag with the same values. The illogical part is that a lot of other info (like the merging of turn lanes) is stored in lane info. Another illogical thing is that the change in lane count occurs in a certain distance and not at a node. |
|
No | Good | Relations are quite hard to build and maintain. That's the reason they should be used only if there is really no other solution to collect data for the purpose of having a good lane assistant, for example at complicated junctions. Relations can be broken up by novice users, creating multiple roles. This can be problematic when from way is broken since it creates two from ways. |
Data stored in: where is the necessary data stored? It can be put in (a combination of) ways, nodes and relations
Applies to KISS: is it logical and easy to understand and apply from a car drivers point of view?
Continuity: can the data be lost easily by a novice user breaking up ways, nodes, relations?
When (not) to use / obvious connectivity
In case of no or obvious connectivity the connectivity:lanes key isn't needed
At normal junctions or T-junctions in a city/village the tag connectivity:lanes will not be necessary. The reason for that is that all data to use for a lane assistant can be derived from turn:lanes=* on the incoming segment.
| Situation for obvious connectivity | Default for obvious connectivity | Comment |
|---|---|---|
| Total number of incoming lanes = Total number of outgoing lanes | All lanes connect 1:1 counted from left to right | Total, because the number of segments is not relevant. Left-to-right complies to established lanes tagging. |
| Incoming segment = motorway or trunk. Total number of incoming lanes < Total number of outgoing lanes. | All lanes of the incoming motorway or trunk segment connect 1:1 to the lanes of the outgoing motorway or trunk segment counted from left to right. | Furthermore a default could be applied for the number of lanes if these are not tagged: motorway/trunk = 2 lanes; motorway_link or trunk_link = 1 way |
Relations for complicated junctions
In some situations it's not possible for a router to determine the correct lane in a obvious way or by using tags on the segments. Examples are junctions with 5 or more ways connected into one junction. Other examples can be the situations where automatic calculations by a router (see section below) deliver the wrong results. In these cases, a relation is needed. The routing engine won't need this data to calculate the correct way to travel, so the sole purpose is to provide correct lane information to a (car)driver. A relation has to be built up in such a manner that any routing engine can display the correct lane on your screen in arrow view. Therefore it needs two specific kinds of data: 1) the data on all lanes and 2) the data on the lane the relation is built for.
This relation is built on segments (OSM ways) with the following roles: from / via / to. You can use as many via segments as needed. Start the from segment where you want the lane assistant to show up. In some cases you might need about 20 relations to cover complicated junctions. Relations should override other calculations by a router since the human intervention to create the correct arrow display is supposed to be better than any automated calculation by a routing engine. A router should therefore first check for the presence of relations, and then check for other data for a lane assistant.
| Key | Value | Description |
|---|---|---|
| type | connectivity:lanes | Marks that this is a connectivity relation for a lane assistant. |
| turn:lanes | Same as the values used by turn:lanes=* | Values in conformity with turn:lanes=* to describe all lanes of the from way to be displayed by the lane assistant |
| highlight:lanes | yes / no | Describes the exact lane(s) of the from way to be highlighted in the lane assistant for the relation, with the purpose to present the correct lane information to a (car)driver. It has to be used for all turn:lanes and separated with a vertical bar per lane just as in turn:lanes. |
An example for a connectivity relation can be found here: [2]. The unclassified lane from the north (43391264) is the segment where the (car)driver should choose the correct lane, based on the signs above the road
which tell you to take the left lane to go directly onto the motorway and the right lane to drive to the motorway by using the roundabout. This is a complicated situation, because the primary road 43391360 is too short for a driver to change lanes when traffic is busy. In fact, this junction consists of two junctions. Note that no other connectivity relations are used at this junction, because the other turns are easy to be calculated by a routing engine. The arrow view display for the left lane would be: 
Examples
| number of incoming segments (OSM ways) | number of outgoing segments | number of lanes of incoming segments | number of lanes of outgoing segments | Situation at the end of the incoming OSM ways (@ the connecting node) | Obvious connectivity? | Tagging |
|---|---|---|---|---|---|---|
| 1 way | 1 way | 3 lanes | 4 lanes | Middle lane of the incoming OSM way splits into 2 lanes. | No | connectivity:lanes=continue|split|continue |
| 1 way | 1 way | 3 lanes | 4 lanes | A new lane to the right is added. | No | connectivity:lanes=continue|continue|continue;split_to_right |
| 1 way | 1 way | 3 lanes | 4 lanes | A new lane to the left is added. | No | connectivity:lanes=split_to_left;continue|continue|continue |
| 1 way | 1 way | 3 lanes | 2 lanes | The rightmost lane ends (merges to left). | No | No obvious connectivity, and no connectivity:lanes needed because turn:lanes=none|none|merge_to_left should be enough |
| 1 way | 1 way | 3 lanes | 2 lanes | The middle and the rightmost lane merge to one. | No | connectivity:lanes=continue|merge|merge |
| 1 way | 2 ways | 5 lanes | 3 lanes + 2 lanes | In a y-branch 3 lanes continue in one OSM way, 2 lanes in the second OSM way | Yes | No connectivity:lanes needed since there is a obvious connectivity: the number of lanes incoming = the number of lanes outgoing. A router should read the lanes left to right (as in :lanes). |
| 1 way | 2 ways | 2 lanes | 2 lanes + 1 lane | Motorway_exit situation (also for motorway_exits where no lane tagging is used) | Yes | No connectivity:lanes needed. The 2 lanes of the incoming motorway connect to the 2 lanes of the outgoing motorway |
| several ways | several ways | several lanes | several lanes | Junction with 5 (or more) ways connecting. One relation per possible direction (= about 20 relations per junction). | No | For 1 example relation: type=connectivity:lanes, turn:lanes=left|left;slight_left|through|through|right, highlight:lanes=no|yes|no|no|no, 1 from way, 3 via ways, 1 to way |
Automatic turn calculations by a router
Routers use calculations based on the number and names of ways connecting to a node and the angles of the ways to know if there is a turn and, if so, which turn it is. In reality these calculations don't always have to match the corresponding signs or arrows. In these cases a relation which overrides the calculations will be useful. OSRM uses the following instructions for the angles: source
if (angle >= 23 && angle < 67) {return TurnSharpRight;}
if (angle >= 67 && angle < 113) {return TurnRight;}
if (angle >= 113 && angle < 158) {return TurnSlightRight;}
if (angle >= 158 && angle < 202) {return GoStraight;}
if (angle >= 202 && angle < 248) {return TurnSlightLeft;}
if (angle >= 248 && angle < 292) {return TurnLeft;}
if (angle >= 292 && angle < 336) {return TurnSharpLeft;}
Questions
1. Could turn:lanes=* be expanded, so that connectivity:lanes won't be needed? Some reasons for that: 1) a value like slight left;slight_right has the same meaning as 'split' 2) Merge_to_left is a reason not to use connectivity:lanes 3) a differentiation in keys might be confusing for users
2. What's the exact importance for a lane assistant in situations where 1 segment connects to 1 segment?
3. Can the section on 'when to use relations' be further clarified?
4. How can the use of relations be further minimized?
5. Are there more obvious connections?