Relation:connectivity
connectivity |
Description |
---|
A type of from-via-to relation that indicates how the lanes in the "from" member connect to those in the "to" member. |
Members |
|
Status: approved |
Tools for this tag |
|
A connectivity relation is a type of relation used to indicate how the lanes of two road segments connect to each other. In most cases, the way the lanes connect is possible to infer without using a connectivity relation, but there are many cases where connectivity relations are needed.
How and when to use connectivity relations
There are several situations where a connectivity relation could be useful.
- The number of lanes on a motorway changes, but the lane connectivity can't be found by looking at the tag placement=*.
- An intersection isn't possible to accurately map with just turn:lanes=*. This is usually only in places where there are multiple intersections close together, and it matters which lane the navigator uses to make a turn so that they end up in the correct lane for the next turn.
- The lane markings on the ground don't represent the actual connectivity of the intersection, or are simplified for drivers. An example of this is a left turn lane at a junction that can also be used to continue straight and turn left at the next junction.
In all of these cases, one or more connectivity relations can be used, each to connect the lanes of two highways.
To add a connectivity relation, create a new relation with three (or more) members:
- A from way, which is the start road of the relation.
- One via node or one or more via ways, which represent the junction.
- A to way, which is the destination road of the relation.
via members should be nodes when possible, but in some cases, a way is needed. These cases are common where there are lanes behind and in front of a section of road that has no marked lanes. In this case, information wouldn't be possible if via members could only be nodes - the section of road with no markings wouldn't be able to properly be part of a connectivity relation, since it doesn't have any lanes. In this case, the simple solution is to set the unmarked way as the via member and "bypass" it by just stating how the lanes of the ways behind and in front of it connect across the via way.
The relation states how the lanes in the from member connect to those in the to member.
Each relation should have two tags:
Tag | Description |
---|---|
type=connectivity | For marking that the relation is of type "connectivity". |
connectivity=* |
For stating which lanes travellers in each lane in the from way can end up in on the to way after the via junction. The syntax of the value should look like a list of [lane number of from way]:[lane numbers of to way separated by commas] separated by pipe characters: "|". Each statement within the pipes will contain information about a single from lane, or more specifically, which lanes that from lane can access in the to way. A lane in to can be parenthesized, this indicates that a lane change is required to access this new lane. |
Examples
Relation in OSM | Image | Tagging |
---|---|---|
9496175 9496175 |
A relation should be created here with the from, via, and to members as shown in the image. Note that this highway is a two way road, and that the relations can still be used here. It should have the tags type=connectivity and connectivity=2:1|3:2. The information in the connectivity tag states the following: The lane number system is the same as the numbering already used in placement=*, where 1 is the leftmost lane in the direction considered, 2 is the lane to the right of that lane, and so on. The "lane number" bw can be used to specify the both_ways lane of a from or to way. The pipe symbol | should be used to separate different lane connections. Each lane in the "from" way that can be used to access the "to" way has its own statement which is separated from other statements. | |
9680471 9680471 |
A connectivity relation should be used here to indicate which lanes the right turn lanes in from connect to in to. Since the two lanes have very different destinations, it's important to know in advance (when turning right) which lane to use. It should have the tags type=connectivity and connectivity=1:(1),(2),3|2:4,(5) - lane #1 in from connects to lanes #1 and #2 (not default but possible), and #3 | lane #2 in from connects to lanes #4 (default) and #5 (not default). | |
9607206 9607206 | A from-via-to relation could be used on the right highway to express the lane connectivity here.
The relation should have the tags type=connectivity and connectivity=1:(1),2|2:3|3:4|4:(4) - lane 1 in from connects with the left two lanes of to, but the left lane in to can only be accessed using a lane change into a new lane, so parentheses are used | lane 2 in from connects with lane 3 in to | lane 3 in from connects with lane 4 in to | lane 4 in from also connects to lane 4 in to, but this requires leaving the ending lane, so parentheses are used.. | |
9529781 9529781 |
A from-via-to relation could be used here to represent which lanes in the from way can be used to access the lanes in the to way. It should have the tags type=connectivity and connectivity=1:1|2:2,(3) - lane #1 in the from way goes to lane #1 in the to way | lane #2 in the from way goes to lanes #2 and #3 in the to way. Note that lane #3 in the to way opens as an extension of lane 2. This means that it should be marked as one of the lanes that #2 can access from the from way using parentheses. | |
9646478 9646478 |
A from-via-to relation of type connectivity could be used here to describe how the lanes in from connect to those in the to way. It should have the tags type=connectivity and connectivity=1:1|2:(2),(3),4|3:5 - lane #1 in the from way connects to lane #1 in to | lane #2 in from connects to lanes #2 (requires leaving default lane), #3 (requires leaving default lane), and #4 | lane #3 in from (a bus lane) connects to lane #5 in to (also a bus lane). | |
9526433 9526433 |
A from-via-to relation of type connectivity was used here to describe how the 3 lanes in from transition into the 4 lanes of to. The relation should have the tags type=connectivity and connectivity=1:1|2:(2),3|3:4 - lane #1 in from connects to lane #1 in to. | lane #2 in from connects to lanes #2 (not default) and #3 in to | lane #3 in from connects to lane #4 in to. Parentheses indicate that the connectivity isn't default - if the person driving doesn't change lanes, they can't end up in that lane. This could be useful to navigation because the highway soon splits, and the right two lanes separate from the left two lanes. Knowing which lanes end up in which destinations in advance would be useful to navigation. | |
9619789 9619789 |
After the split, this road has two lanes. Then, at node labelled Via, highway becomes three-lane. A relation can be used here to describe this: it should have tags type="connectivity" and connectivity="2:3" - lane #1 in from way access lanes #2 to |A connectivity relation could be used to mark how 2 lanes become 3 lanes at the point. The connectivity relation should have the tags type=connectivity and connectivity=1:1,2|2:3 - lane 1 in from connects to lanes 1, 2 in to. | lane 2 in from connects to lane 3 in to. | |
Two connectivity relations could be used to mark what the actual connectivity of this small junction is, since the turn:lanes values aren't representative of reality.
Green relation: type=connectivity and connectivity=bw:(1) - lane one in to can be reached from the both_ways lane in from, but it's not default. Red relation: type=connectivity and connectivity=bw:bw|1:1|2:2|3:3 - all four lanes connect to each other. The centre turn lane technically also connects, which is why it's included. | ||
9502717 9502717 |
A connectivity relation could be used to mark how 3 lanes become 6 lanes at the point. The connectivity relation should have the tags type=connectivity and connectivity=1:(1),(2),3|2:4|3:5,(6) - lane 1 in from connects to lanes 1, 2 and 3 in to. | lane 2 in from connects to lane 4 in to | lane 3 in from connects to lanes 5 and 6 in to. | |
9516178 9516178 |
A connectivity relation could be used to mark what the "through" part of the oneway road actually means. The relation should have the tags type=connectivity and connectivity=2:1 - lane #2 in from (the oneway highway) connects to lane #1 in to (which has no "lanes", and should be considered to have only 1 forward lane). Note that this intersection could be modelled differently to make this work without connectivity relations, but that would change other factors (such as the angle at which they connect to the secondary road), and would not be preferable. | |
9502616 9502616 |
A connectivity relation could be used here to describe how the 4 lanes in from connect to the 5 in to. After the via node, the left lane of from becomes a left turn lane (at the next intersection) in to, and the right three lanes of from become through lanes (at the next intersection) in to. This means that navigation apps shouldn't instruct drivers to use the left lane unless they are going to turn left soon, but they currently do this anyway. The relation should have the tags type=connectivity and connectivity=1:2|2:3|3:4|4:5. Since the leftmost lane in to isn't the destination of the leftmost lane in from, it shouldn't be included as a destination of that lane. | |
16622295 16622295 | This unusual sign, which has corresponding road markings, is located at a T-intersection near another intersection. The three left turn lanes are assigned to specific lanes after the T-intersection. |
Default connectivity
Basic summary
In most cases, no connectivity relation is needed, since the connectivity can be assumed based on other factors.
If the number of lanes in from that can be used to access to is the same as the number of lanes in to, no relation is needed. This number of lanes is based on the turn:lanes=* tag of the from way.
In some cases, a connectivity relation can be used to override turn:lanes=* tags, making it totally fine to have what appears to be the default connectivity.
The tag placement=* can also specify lane connectivity. If two roads connect at a node, and placement tags have been added to both, the lane connectivity should be assumed based on those tags.
For placement=*, it should be assumed that any new lanes (lanes that just started and aren't directly connected to a lane in from according to the placement=* tags of from and to) are extensions of existing lanes. This means that if a 2 lane highway with placement=right_of:1 becomes a 3 lane highway with placement=right_of:1, the connectivity is assumed to be 1:1|2:2,(3), not 1:1|2:2.
The tag placement=* should not be used to specify lane connectivity if there are more than 2 highways connected to the via node. This is usually at intersections, motorway junctions, or places where two highways merge together.
In the case where several highways merge together into one highway, it can be assumed that the leftmost highway's lanes connect to the left lanes of to, and that the rightmost highway's lanes connect to the rightmost lanes of to. For example, if two 2 lane highways merge together into a 4 lane highway, the connectivity is assumed to be 1:1|2:2 from the left from way, and 1:3|2:4 from the right from way, and no relation is needed.
When 3 or more highways merge together at a certain point, the left and rightmost from ways can have assumed connectivity, but any from highways in between will need a relation to clear up ambiguity.
In sum, connectivity can be assumed in the following cases:
- The number of lanes in the from way equals the number of lanes in the to way.
- Placement tags specify the connectivity between two ways, but not at an intersection.
- Several highways merge together - assume that the lanes of the left and right from highways stay to their side in the to way.
Data consumer / pseudocode summary
Data consumers should get the lane connectivity between two ways in OSM as follows:
if (connectivityRelationExistsBetweenRoadsAtVia) { use the relation } else if ((number of lanes in from that can access to) == (number of lanes in to)) { use default connection } else if (placement of from/to has clear connectivity AND there are only those two highways connected at the via point) { use placement of from/to including default placement } else if (several oneway roads connect with only one outlet... aka roads merge together) { The leftmost from way's lanes should be assumed to stay to the left in 'to' The rightmost from way's lanes should be assumed to stay to the right in 'to' Any middle roads shouldn't have any assumed connectivity unless the number of lanes in those are equal to the number of lanes in 'to'. } else { a relation is missing and no connectivity can be assumed. }
Additional notes
- Via members can be ways - see this example. Any number of ways may be included as via members, but in a situation where either a way or a node could be used, it's better to just use a node for clarity.
- All lanes included in the :lanes tags of the from / to ways can be included in connectivity relations. For example, if bike lanes are tagged in the turn:lanes tag of the from and to ways, then they should be included in the corresponding connectivity relation as if they were a normal lane. Bus lanes are the same.
- These relations should only be used in places where lane connectivity is not default - see above.
- Both_ways lanes are supported by this relation: simply use bw instead of the lane number inside of the syntax. For example, the tag connectivity=bw:bw|1:1|2:2 specifies that the both_ways lanes in from and to connect to each other, and that lanes 1 and 2 do so as well.
- This is invalid syntax: connectivity=1,2:1|3:2 - don't place two different from lanes in the same statement (1,2:1 has both 1 and 2 from the from way inside of the same statement). Use connectivity=1:1|2:1|3:2 instead.
- These relations can be used with two way roads without additional tags - just tag the lane numbers for the direction of the relation.
- It should be assumed that no lane changes are possible at the intersection that the relation is located. For example, if the from way and to way both have 2 lanes and no change allowed, it should not be assumed that you can jump from the left lane to the right lane at the via node / way(s).
- Conditional lane connectivity, or lane connectivity that changes depending on the time, should be mapped with type=connectivity and connectivity=*, with connectivity:conditional=* being used to override the main connectivity tag at certain times or conditions. These cases are very rare, so connectivity:conditional=* wont be needed often. See this example mapillary image of modular turn lane signage for proof that this is possible.
- This relation type doesn't specify what "turn" travelling from the from way to the to way is - that should be added in the turn:lanes=* tag of the from way, since that is where it is specified in the real world. Another option for this is to use a type=manoeuvre or type=maneuver relation, which are supported by OSRM, but aren't very common.
- When a from/to highway doesn't have any "lanes", or is completely unmarked, its "lane" should be given the lane number 1 in the syntax of connectivity=*, since one line of vehicles can enter/leave the highway.
Software support
The Lane Connectivity plugin (listed as intersection in the JOSM plugin list) allows you to create connectivity relations visually in JOSM. JOSM will also validate connectivity relations as of r16295.
The iD editor has a preset and field for entering connectivity relations. It lacks a lane editor in general, but you can easily create a connectivity relation using the turn restriction editor: select the node that connects the ways, create a turn restriction from and to the same ways that you want to connect, select the relation that you just created, and change the preset to Connectivity, ensuring that the restriction=* tag has been removed. This workaround sets the correct from, via, and to members.
The Valhalla routing engine supports an older, incompatible syntax from this draft proposal. This issue tracks upgrading Valhalla to the approved syntax.