Proposal:Connectivity
The content of this proposal has been archived to avoid confusion with the current version of the documentation.
See on Template:Archived proposal how one may mark older proposal version to provide easy link for viewing archived content. (quick hint: {{Archived proposal|archive_id=}})
| Connectivity | |
|---|---|
| Proposal status: | Approved (active) |
| Proposed by: | LeifRasmussen |
| Tagging: | connectivity=* |
| Applies to: | 
|
| Definition: | A type of from-via-to relation that indicates how lanes in the "from" member connect to those in the "to" member. |
| Statistics: |
|
| Draft started: | 2019-04-17 |
| RFC start: | 2019-04-22 |
| Vote start: | 2019-07-01 |
| Vote end: | 2019-07-15 |
Rationale
The current lane tagging system can provide simple lane information that can be used at junctions to let data consumers know which lanes go where. The existing system does have some issues, though:
- It can't provide in depth information about lanes, and what their "fate" is on major highways. Using OSM data, it's currently impossible to know which lane to be in on a road until you're almost at the junction. This is because OSM lane data is currently only added to individual ways with tags, but no connection is really made between these ways. If a highway goes from having 3 lanes to having 6, we currently can't know which lanes those 3 connected to, so knowing in advance which lane to be in in the 3 lane road to end up in the through lanes of the 6 lane road (possibly lanes 3, 4 and 5) isn't possible.
- Some complex intersections can't be modeled properly with the current tagging system - see this one.
- Sometimes, the markings on the ground don't actually represent the connectivity at an intersection. This proposal makes it possible to tag what the real connectivity of lanes is "behind the scenes" while letting people use turn:lanes=* to mark lane markings on the ground as they already do.
This proposal will add a new type of relation that can be used together with turn:lanes=* to describe how lanes connect between highways.
Proposal
This proposal proposes the following: A type of from-via-to relation that indicates how 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 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. If a the connectivity isn't default, meaning that the driver must leave their lane to access the lane, parentheses should be used around the number representing the to lane. If not changing lanes would result in driving into the to lane, don't use parentheses. Keep in mind that it's possible for there to be several to lanes marked as "default" if none of them are any more default than the others. |
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.
Members
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.
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.
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: Lane 2 in from becomes lane 1 in to. Lane 3 in from becomes lane 2 in to.
|
| 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
|
|
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. |
| Green: 9729600 9729600
|
|
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 center turn lane technically also connects, which is why it's included. |
|
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:4,(5) - 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).
|
| 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.
|
View more example relations with this Overpass-Turbo request
Compatibility with turn:lanes=*
In complicated situations, such as those in the image below, 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 only 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.
Editor support:
- iD - full support from 2.15.0 for not breaking connectivity relations when member ways are split. See #6221
- JOSM - not supported yet.
Maintainability of member ways
Connectivity relations should behave like and be roughly as common as turn restrictions if widely adopted. Editing roads where connectivity relations have been mapped will be very similar to editing roads where turn restrictions have been mapped. Most mappers don't have much trouble with turn restrictions when mapping, however, so I very much doubt that they will have trouble with connectivity relations.
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.
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.
- 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) {
use placement of from/to including default placement
} else {
a relation is missing and no connectivity can be assumed.
}
Comments
- Via members can be ways - see this example. Any number of ways may be included as via members, but it is always better to just include 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.
- 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.
- Both_ways lanes are supported by this proposal: 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. 99% of all values of lanes:both_ways=* are 1, and the remaining 1% are mostly invalid. The few valid cases of multiple both_ways lanes will not be supported by this new feature, but since they are so rare, this shouldn't be much of an issue.
- 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.
- 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 and 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. 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.
Potential uses
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 left lane just after turning right.
This special lane assist is only possible in very simple cases where the number of turn lanes in from is equal to the number of lanes in to, but with connectivity relations, detailed instructions like these could be given much more often. Image is of this location - ... 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.
Features/Pages affected
No existing features will be affected by these new relations.
Lane related wiki pages will need to be updated to include links to a new page on this topic.
Discussion
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!
Voting
The proposal was approved with a final vote of 15 approving, 3 opposing, and 1 comment. Of the votes, 83.3% were in favor, which is over the 75% required approval rate requirement.
I approve this proposal. --LeifRasmussen (talk) 21:06, 1 July 2019 (UTC)- I approve this proposal. This is a thoroughly researched, practical proposal that addresses the biggest problems in the transit=* proposal. As long as we represent lanes with tags rather than separate geometries, connectivity relations are essential for resolving ambiguous cases. It'll be up to editors to make connectivity relations intuitive for mappers, but I think overall the proposal strikes the right balance between the needs of mappers, editors, and routers. – Minh Nguyễn 💬 00:21, 2 July 2019 (UTC)
- I approve this proposal. A very well thought out proposal with lots of examples, justifications, etc. --TheEditor101 (talk) 08:49, 2 July 2019 (UTC)
- I approve this proposal. I see no problems with this proposal. BTW, thanks for responding to feedback! --Mateusz Konieczny (talk) 08:57, 2 July 2019 (UTC)
- I approve this proposal. --Escada (talk) 05:16, 3 July 2019 (UTC)
- I approve this proposal. --Maigel (talk) 15:22, 6 July 2019 (UTC)
I oppose this proposal. This type of relation are not easy to maintain(and can get easy broken by new user) if there are a lot of small road segments bevore the intersection, because of different speed limit, surface, lit, sidewalk, width etc. --Luschi (talk) 02:20, 7 July 2019 (UTC)
- As mentioned in #Splitting member ways, the proposal depends on editors to maintain correctness when splitting. Editors would use more or less the same heuristic as they already do when splitting a way that is a member of a turn restriction relation. – Minh Nguyễn 💬 03:19, 7 July 2019 (UTC)
- I'd like to add that iD now has full support for managing connectivity relations, meaning that iD users won't destroy any connectivity relations. I plan on opening a ticket for JOSM and one for Vespucci as well, so unless turn restrictions are a major issue for contributors, connectivity relations won't be one either. I can assure you that broken connectivity relations will not be an issue. --LeifRasmussen (talk) 10:42, 7 July 2019 (UTC)
- I approve this proposal. --Jdcarls2 (talk) 11:43, 7 July 2019 (UTC)
- I approve this proposal. --Chaz6 (talk) 14:56, 7 July 2019 (UTC){{
- I oppose this proposal. Seems needlessly complicated and will only add more complexity to mapping intersections. Relations are also hard for new users to understand which will result in these relations breaking more than often and making them hard to maintain. There are also already existing tags for this type of mapping, namely placement=* which doesn't require relations and already has more than 100 000 uses. --Riiga (talk) 18:26, 7 July 2019 (UTC)
- @Riiga: The proposal states that connectivity relations would only be used in situations where placement=* is insufficient to describe the traffic pattern, such as at a four-way intersection where a certain lane only connects to a specific lane when making a left turn. It could well be that connectivity relations will be relatively rare for this reason. – Minh Nguyễn 💬 18:19, 8 July 2019 (UTC)
I have comments but abstain from voting on this proposal. sounds over-complex to me --Nospam2005 (talk) 13:36, 8 July 2019 (UTC)- I approve this proposal. --Canyonsrcool (talk) 16:37, 8 July 2019 (UTC)
- I approve this proposal. As of right now, the current mapping standard of turn lanes is too ambiguous regarding the lane of destination and which lane should be the source. While somewhat complicated, this proposal does resolve this issue. --Garylancelot (talk) 17:14, 8 July 2019 (UTC)
- I oppose this proposal. Sorry I find the scheme overly complicated and the required syntax counter-intuitive. The effect is small: OsmAnd already calculates the next turn:lane in advance, looking ahead for the upcoming junction. --Polarbear w (talk) 19:42, 8 July 2019 (UTC)
- I tried to address some of your and others' concerns about complexity on the talk page. Let's continue the conversation there since there's not a lot of space here. – Minh Nguyễn 💬 03:31, 9 July 2019 (UTC)
- I approve this proposal. --Baconcrisp
- I approve this proposal. —M!dgard [ talk ] 05:51, 9 July 2019 (UTC)
- I approve this proposal. --vespax 18:02, 9 July 2019 (UTC)
- I approve this proposal. Martijn van Exel (talk) 22:38, 9 July 2019 (UTC)
- I approve this proposal. My only concern is ensuring that the relations are correct, so I would like to see validation code in JOSM at the very least (and possibly iD) after this proposal is accepted --Vorpalblade77 (talk) 14:36, 14 July 2019 (UTC)
Comments after the vote: