|Status:||Proposed (under way)|
|Definition:||A type of from-via-to relation that indicates how lanes in the "from" member connect to those in the "to" member.|
The current turn:lanes=* tagging system usually provides accurate information about where lanes end up on the next highway, but there are many cases where turn:lanes=* can't provide that information. These places include multi-lane roundabouts, some single point urban interchanges, and anywhere the tag transit:lanes=* has been added. This proposal will add a new type of relation that can be used together with turn:lanes=* to describe how lanes connect between highways.
This proposal proposes the following: A from-via-to relation that states which lanes in the "from" way connect to which lanes in the "to" way.
Each relation should have two tags:
|type=connectivity||For marking that the relation is of type "connectivity"|
|connectivity=*||For stating which lanes travelers 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.
This proposal would replace the abandoned tag transit:lanes=* (in any place it is still mapped) and the relation type type=turnlanes:turns. Practically every intersection on the planet will be fully mappable with just turn:lanes=* and connectivity relations.
The members of a connectivity relation should have the same format as turn restriction relations. Each relation will have at least 3 members:
- A from way, which is the start road of the relation.
- One or more via node or ways, which represent the junction.
- A to way, which is the destination road of the relation.
|Relation in OSM||Image||Tagging|
|Relation 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.
The information in the connectivity tag states the following:
Lane 2 in from becomes lane 1 in to.
Lane 3 in from becomes lane 2 in to.
|Relation 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 | 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.
|Relation 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.
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.
|Relation 9496170||A from-via-to relation of type connectivity could be used here to describe how two lanes (close to "camera") become four lanes (near the traffic signal). Note that this highway is a two way road, and that the relations can still be used here.
The relation should have the tags type=connectivity and connectivity=1:1,2,4|2:3 - lane #1 in the from way goes to lanes #1, 2, & 4 in the to way | lane #2 in the from way (the cycle lane) goes to lane #3 in the to way (also a cycle lane).
Note that the two lanes are tagged as crossing each other. This was one of the weaknesses of the transit:lanes=* proposal - crossing lanes could not be tagged properly.
A from-via-to relation of type connectivity could be used here to describe how the lanes in from connect to those in the 2 to ways.
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 & #3 in to | lane #3 in from connects to lane #4 in to.
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.
|Relation 9619789||lane #2 in the from way can be used to access lane #3 in the to way.|
|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:4,5 - lane 1 in from connects to lanes 1, 2, & 3 in to. | lane 2 in from connects to lane 3 in to | lane 3 in from connects to lanes 4 & 5 in to
|Relation 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).
View more example relations with this Overpass-Turbo request
Compatibility with turn:lanes=*
In complicated situations, such as those in the image bellow, it is very difficult for routers to understand what the turn lanes values actually mean in terms of navigation.
In these cases, connectivity relations can be used to show where each lane connects to, meaning that the existing turn:lanes=* tags are simply just for stating the lane markings, and that the connectivity relations are for stating the "behind the scenes" lane connectivity.
Splitting member ways
Without improved editor support, these relations could easily become broken by contributors who split a member way. Because of this, these relations will need to be handled in the exact same way as turn restrictions.
No additional code for handling these relations will need to be written, since it already exists for turn restrictions.
- iD - full support from 2.15.0 for not breaking connectivity relations when member ways are split. See #6221
- JOSM - not supported yet.
- Via members can be ways - see this example
- Bicycle lanes and bus lanes should also be included in this syntax. Note that the lanes=* tag only includes traffic lanes, and not bike lanes. Sidewalks, separate bike lanes mapped as ways, and parking lanes should not be included in the syntax.
- These relations should only be used in places where lane connectivity is not obvious. If two 2 lane highways merge together into a 4 lane highway, the connectivity is obviously 1:1|2:2 from the left from way, and 1:3|2:4 from the right from way, and no relation is needed. If the connectivity is actually 1:1,2|2:3 from the left highway, and 1:3|2:4 from the right highway, relations should be used - see image below.
- These relations can be used anywhere transit:lanes=* was added, but also to complex intersections to indicate what the turn:lanes=* values actually mean.
- These relations are rather easy to parse: If a routing engine wants to know which lane in the to way the driver will end up in after passing by the via node, they should simply look for the id of the lane that the navigator is currently in, and see which lanes (after the ":") the vehicle will end up in.
- 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 & 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.
- The number of lanes in the from way that can be used to travel to the to way should always be the number of pipe characters (|) +1. If the tag connectivity=1:1|2:1|3:2 has 2 pipes, there are 3 lanes in from that can be used to access to (in this case, the lanes numbered 1, 2, & 3).
- 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" traveling 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.
There are many ways in which this type of relation could be used. Here are a few examples.
- Making lane assist possible in complex intersections where turn:lanes=* isn't sufficient.
- Allowing navigation apps to know what the "fate" of a lane on a motorway is far in advance - it would be possible to suggest which lane the driver should get into 10 minutes in advance, or it might even be possible to have the navigation always show the "best" lane to be in for the upcoming turns. This would be especially useful for driverless vehicles, since it would allow them to get in the correct lane for the next exit much more easily. One example of this is Tesla, which has cars on the road now that will automatically change lanes and take exits using Google Maps data. Providing the same level of detail in OpenStreetMap would allow for new use cases of our data.
- Allowing lane connectivity to be specified in places where the road markings don't represent the actual lane connectivity or are simplified to be easier for humans to read. An example of this would be an intersection where the right lane can either turn slight right or right, but the lane markings just have a right turn arrow.
- Allowing lane assist to know which lane to use to turn onto another highway to best complete the next turn - if you are going to turn right, and then immediately left, and there are two lanes that can be used to turn right, it would make sense to use the left lane to turn right so that you don't have to get into the right lane just after turning right.
- ... and possibly more. OpenStreetMap data is continually being used for more and more projects. The better quality the data we provide is, the more use cases there are going to be for it.
Please use the talk page for feedback. Any comments for improving the proposal would be highly appreciated! I would like this proposed relation type to be able to work in all cases possible, so please comment if anything is missing!