Proposal talk:Connectivity

Focus on relations

Thanks for starting this proposal, LeifRasmussen! A proposal along these lines has been sorely missed since transit:lanes=* was scuttled. I like the fact that you're only proposing a relation, which follows the principle that any relationship between two ways should be explicitly bound together by a relation to facilitate routing. (These days, a modern OSM editor already needs to have some routing-ish logic embedded in it.) – Minh Nguyễn ^💬 17:25, 18 April 2019 (UTC)

Provided that we get the commitment of the editor developers to build a fully functional graphical interface, using a relation seem to be better than the relationships of the transit proposal, which were tagged on the highway.

Having said that, applying the new proposal in the current state of OSM would flood the database with relations which were a nightmare for editing highways especially with iD. We need to invent other means to reduce the number of required relations, or to reduce the impact of the relations on editing.--Slhh (talk) 23:35, 25 April 2019 (UTC)

69354363 (achavi, OSMLab) adds two connectivity relations that were previously inexpressable under the old transit:lanes=* proposal because they both span T-intersections. – Minh Nguyễn ^💬 17:56, 18 April 2019 (UTC)

Thanks! --LeifRasmussen (talk) 19:24, 18 April 2019 (UTC)

I think this was expressible using the relation defined in the transit proposal. The real functional limitation of the transit proposal was the missing support of crossing lanes.--Slhh (talk) 23:35, 25 April 2019 (UTC)

Order of operations

- is concise, but it's already used in other tags to denote a range, which could lead to some confusion. What's more, the example connectivity=1-1|2-2;3 implies an order of operations where ; is evaluated before -. This usage conflicts with:

opening_hours=* and conditional restrictions, where - is evaluated before , or ;
addr:housenumber=* and junction:ref=*, where ; and - could be evaluated equivalently left to right
grades=*, where - can be used as a unary negative sign

Is it necessary to put all the connectivity information into a single tag? How about splitting it up into from=* and to=* tags? That would avoid the need for a - operator, though it would introduce the awkwardness of having to cross-reference multiple tags for a single lane progression.

– Minh Nguyễn ^💬 17:44, 18 April 2019 (UTC)

Thanks for pointing this out! I think that cleaning up the format a bit would be good.

Currently, I have - representing "transitions to" or "can be used to access the following lanes." An arrow symbol like → would be good, but no keyboards can easily type that. Another idea I had was the > character, since it also looks like an arrow. Unfortunately, it also looks like greater than, so the whole syntax starts looking like some kind of math expression. I like the - best of all of the options I have looked at, but would love suggestions for different characters to use.

As for the ;, would a comma be OK with you? The only two list separators I know of are ; and ,, so if there are others that are easy to type, please let me know! I would be more than happy to use a comma instead of semicolon, especially since it would make the numbers on either side of the comma pop out more, making them more visible, and the syntax more readable.

Finally, I would like to keep the information in one tag, since two tags are harder to work with. I originally tried sticking the information inside of a from:lanes=* and to:lanes=*, but found that it was quite complicated to connect the two if I wanted lane crossing to still be supported. My original syntax looked like from:lanes = 1|2|3|4;5 and to:lanes = 2|3|4|5 which can now be written like connectivity=1-2|2-3|3-4|4-5|5-5. --LeifRasmussen (talk) 19:24, 18 April 2019 (UTC)

I kind of like the original syntax with from:lanes=* and to:lanes=*, if for no other reason than consistency with the lanes extension. If we keep -, then , is better than ;, because at least it doesn't visually seem more important than -. Then ; can replace |, making it just a list (potentially unordered) of connections. Some other options include : or to (following grades=*) instead of -. Whatever we end up with, we should clarify what happens when a lane is added or dropped from one way to the next. Is the lane numbering specific to the way in question, even within the same tag? – Minh Nguyễn ^💬 19:37, 18 April 2019 (UTC)

I like the idea of replacing the ; with ,, and will update the examples, real life cases, and proposal accordingly. As for using : instead of -, I am OK with this as well, but think that it would make it harder to understand the syntax, since it will look like the : is less important than the comma, and that the comma is separating different groups of colon separated numbers.

As for removing the pipe, | indicates quite clearly that each statement refers to a lane, or a pair of lanes. Changing to ; would make the syntax more confusing at first sight in my opinion.

What do you think of this syntax: Changeset 69358332 (talk) 20:05, 18 April 2019 (UTC)

I still end up doing a double-take because I'm familiar with opening_hours=* syntax, in which - is evaluated before ,. But maybe optimizing for manual entry and sightreading isn't super important. – Minh Nguyễn ^💬 21:25, 18 April 2019 (UTC)

Instead of using e.g. connectivity=1-1|2-2;3 we could use the tags connectivity:1=1 and connectivity:2=2;3. This means more tags, but less complex syntax.

We could also use the lanes scheme (based on lanes of the 'from' way): connectivity:lanes=1|2;3. This means using lane numbering for the 'to' way only.-- Slhh (talk) 23:28, 18 April 2019 (UTC)

I see 2 potential issues with that:

1) People might not realize that you can have connectivity:2=* without connectivity:1=*.

2) Data consumers (and editors) have to consider a ton of tags, which I know from working with osm data is more difficult. Making it harder to consume / modify this type of relation will lead to less support.

After thinking more about the syntax, I've realized that using a colon wouldn't be a problem. What do people think of this syntax? 1:1,2|2:3|3:4|4:5,6 (The ; becomes , and - becomes :). --LeifRasmussen (talk) 00:21, 19 April 2019 (UTC)

Roles

It should be stated more clearly that members should have from, via, and to roles, just like in a turn restriction relation. – Minh Nguyễn ^💬 17:52, 18 April 2019 (UTC)

I'll do this. --LeifRasmussen (talk) 19:24, 18 April 2019 (UTC)

Cycleways

Lanes can be bicycle lanes, which might not connect to a subsequent lane, but to a sidepath. We need to support all kinds of cycleways/bicycle lanes as source and destination.--Slhh (talk) 00:13, 19 April 2019 (UTC)

The proposed relation already supports all types of lanes supported by turn:lanes=*, which includes bus lanes and cycle lanes. Just treat the lanes as normal driving lanes, and give them the number accordingly. --LeifRasmussen (talk) 00:33, 19 April 2019 (UTC)

I see the following major kinds of cycleways:

cycle lanes mapped similar to regular lanes using the *:lanes keys like turn:lanes=*.
cycle lanes mapped using e.g. cycleway=lane independent of regular lane mapping. This seems to be the standard mapping for normal cycle lanes.
cycle tracks mapped on the main highway using e.g. cycleway=track.
cycle tracks mapped as a separate {tag|highway|cycleway}.

The proposal seems to support the first one only by now. The kind of cycleway in the "from" way and the "to" way might be different. The proposal needs to be extended to support mixed cycleway connections.-- Slhh (talk) 13:11, 21 April 2019 (UTC)

Way without lanes

The "from" way and the "to" way might not have dedicated lanes, but still needs to be connected to specific lanes of the other one? How to handle this. Separately mapped cycleways or service ways seem to be some typical usecases.--Slhh (talk) 13:11, 21 April 2019 (UTC)

If I understand you correctly, the answer is that a way without dedicated lanes should be tagged with lanes=1, and the relation should have the destination lane number 1, since the only lane is number 1. --LeifRasmussen (talk) 14:47, 21 April 2019 (UTC)

Lane change restrictions

How does this proposal relate to change:lanes=*, which is in widespread use despite it still being a proposal? We can think of change=* as dealing with lane changes partway down a road way, whereas this proposed relation type deals with lane changes between two ways. Routers need to be able to greedily find opportunities to make lane changes, holes where a change=* is absent, so this relation would allow routers to interpret change=* more strictly and avoid making assumptions about its value across ways. But some intersections allow lane changes while others don't. Should we recommend that change:lanes=* be added to connectivity relations where it's ambiguous (or in the same situations where change:lanes=* would be used)? – Minh Nguyễn ^💬 18:23, 19 April 2019 (UTC)

The way I think of it is like this: these relations should say what happens at the intersection. What is assumed is that no lane changing is possible at that instant. I don't think that it's a good idea to introduce a change:lanes at the intersection point, since it is better to just assume that lane changing at the via is not possible. If the tag change:lanes=* were to be added, the result would be that your navigation system would tell you to change lanes at an intersection just because it's "possible". I will make it clear that no lane changes are assumed possible in the relation. --LeifRasmussen (talk) 18:47, 19 April 2019 (UTC)

We don't need to to map lane change opportunities in the via node, where the lane would typically be changed in one of the adjacent ways. In addition, we don't need to map impracticable lane change opportunities in the via node, even if they might be legal.

Nevertheless, some instant lane changes in the via node are quite practical or even designated, and need to be mapped. E.g.:

Changing (crossing a lane divider) to a new lane which instantly starts at the via node. (In contrast to a new lane which starts with zero width at the and gets wider along the "to" way.)
Assume a bus and a general incoming lane and two outgoing general lanes. Enabling one of the incoming lanes only at a time by signals makes changing to the other lane safe.

We need to map these lane change opportunities, but change:lanes=* doesn't seem to be applicable here, because we haven't a well defined set of lanes passing through the via node in general.

We could integrate these lane change opportunities in the connectivity tag, but put the "to" lane number in parenthesis to indicate that a divider has to be crossed, which is important information for route guidance.--Slhh (talk) 00:04, 22 April 2019 (UTC)

Conditional lane connectivity

Lane connectivity can be conditional. Some cases can be covered by access tagging of the adjecent ways, but not all.

A rea l example which I had in my city:

Two incoming lanes were connected to four turn lanes in front of an intersection, but the connection was changed based on traffic volume. Lane dividers were switchable lights in the carriageway. Three different connection layouts were used:

1 -> 1 and 2 -> 2, (3), (4)
1 -> 1, 2 and 2 -> 3, 4
1 -> 3, (1), (2) and 2 -> 4

Numbers in () indicate require crossing a lane divider where the 4 lane section starts. The example shows that lane connectivity can be conditional, but there aren't well defined conditions in this special case. The intersection was recently rebuild, removing this strange situation. --Slhh (talk) 10:32, 22 April 2019 (UTC)

I think that connectivity:conditional would make sense for any super rare case like you mentioned. I can include it in the additional notes section.

connectivity:conditional would be the exact same format as conditional turn restrictions. --LeifRasmussen (talk) 14:52, 22 April 2019 (UTC)

Does the conditional tagging syntax allow for the value before the @ to be enclosed in parentheses, not just the conditional after the @? If not, then there's some ambiguity (at least visual ambiguity) between commas used as part of the value and commas separating conditions. – Minh Nguyễn ^💬 15:12, 22 April 2019 (UTC)

I don't think so, but any ambiguity would only be visual, since no commas are actually used in the conditional syntax (except for perhaps inside of the parentheses for the opening hours syntax). No pipes or colons are used either, so I don't see any issues.

Even if some issues do exist, there will likely only be about 10 of these relations on earth, so I don't think it needs to be such a big part of this proposal.

Here is an example of what a connectivity relation with conditional could look like: connectivity=1:1,2|2:3,4 & connectivity:conditional=1:1,2,3|2:4 @ (Sa,Su 12:00-15:00). I don't think that that is all that difficult to read. --LeifRasmussen (talk) 15:24, 22 April 2019 (UTC)

Even if the conditional connectivity had several values, the values would be separated by semicolons, not commas, so no issues would arise. My old syntax, though, would have caused a ton of issues. --LeifRasmussen (talk) 15:26, 22 April 2019 (UTC)

A conditional tag is actually a comma-delimited value, not semicolon-delimited. If it were semicolon-delimited, then that would be a problem for turn:lanes:conditional=* and its semicolons. You're right that it's quite an edge case; I'm just trying to make sure a general-purpose tag parser wouldn't have to special-case this tag. – Minh Nguyễn ^💬 00:06, 26 April 2019 (UTC)

I would like to add a comment regarding using parentheses to mark where lane changes are needed. I like the idea in terms of knowing which lane is the "most important," but using the parentheses would also many disadvantages.

1) A visual lane editor could no longer have a user interface of drag each "from" lane to some "to" lanes - it would need to support where dividers must be crossed.

2) Data consumers would need to understand this extra complexity, meaning that fewer of them would be likely to support any of this proposal.

3) There are very few benefits - crossing a dashed line shouldn't affect how you enter a lane. The lane is still accessible from the "from" way.

4) Cases like this get very difficult to map:

How do you know if entering the roundabout counts as "crossing a lane divider?" Many people might end up with different tagging styles, meaning that it would be harder for data consumers to use the information.

5) There will be an even bigger learning curve for new mappers - keeping things simple will encourage more people to use the new relation.

If there are some very good advantages to using parentheses, I will add it to the syntax in the proposal. Otherwise, I will try to keep the proposal as simple as possible.

Thanks for all of your comments Slhh! --LeifRasmussen (talk) 13:50, 23 April 2019 (UTC)

I am starting to wonder about adding the parentheses to the proposal Slhh. I have an actual "very good advantage" that could make it worthwhile: the current rules on how to map connectivity and what "counts" as connectivity (when crossing a lane divider is still "connectivity") are very confusing, and many people probably won't read the documentation properly. As a result, a third of all connectivity relations will be like mine, a third will consider all lane change to not be connectivity, and a third will consider changing lanes to always be connectivity. This would clearly make this entire proposed system practically useless to data consumers.

To stop this, I am going to make it possible (and required) to add a lot more detail about the connectivity by implementing the parentheses idea. I'll update all of the examples, and also every connectivity relation on earth.

This will actually be better for data consumers, since they can choose whether or not lane changes are important. The only issues to consider now are the learning curve (not very big issue) and editor support (quite complicated). I think that something could be implemented, however, to allow users to select the type of lane connectivity when using a graphical editor, which might also open up other possibilities.

Thanks for your comments! --LeifRasmussen (talk) 17:42, 26 May 2019 (UTC)

Sidewalk connectivity

In addition to lanes and cycleways we should also care about connectivity of sidewalks, which are tagged on the main highway. Example usecase: Three roads with sidewalks on both sides are connected, but one isn't crossable for pedestrians near to the intersection. --Slhh (talk) 11:19, 22 April 2019 (UTC)

No, sidewalks are not included in this syntax. Any lane that could be represented by turn:lanes=*|*|* can be represented by this proposal. This includes bike lanes, bus lanes, hov lanes, etc, and does *not* include parking lanes, sidewalks, separated bike lanes mapped as separated ways, or anything else that the key turn:lanes does not represent.

Thanks for asking about this! --LeifRasmussen (talk) 14:52, 22 April 2019 (UTC)

Additional means to require less relations

To reduce the impact on general highway editing, we should try to reduce the number of required relations dramatically. Let's collect ideas to do so here. --Slhh (talk) 22:32, 1 May 2019 (UTC)

Some of these ideas seem to optimize for manual editing of raw tags at the expense of using an editor that can streamline the editing of relations. There's a risk that such optimizations could doom this proposal as it did transit:lanes=*. It's a problem when a tag on a node makes statements about the relationship between adjacent ways – that's the responsibility of a relation. I support the idea that connectivity relations should be used only where lanes=* and placement=* leave some ambiguity, but the rules for when connectivity=* is required and not required should be as intuitive and simple as possible. – Minh Nguyễn ^💬 14:27, 3 May 2019 (UTC)

Some of the ideas might optimize manual editing by experienced users, but their focus is graphical editing. The decision whether to use connectivity relations or other means would indeed be too complicated for general users, but user don't need to care, because the editor software has to decide. The rule for the user would be easy: check if the (default) connectivity shown by the graphical editor is correct, and change it otherwise.--Slhh (talk) 16:06, 4 May 2019 (UTC)

Here is how I envision graphical editors could prevent people from adding unnecessary relations is this:

The graphical editor could show faint green "connectivity" lines showing the default connectivity based on the number of lanes in all ways, the tag "turn:lanes", and the tag "placement". Then, the user could create a different connectivity at the intersection by dragging the tips of the "from" lanes into plugs in the "to" lanes. This way, people wouldn't be tempted to add connectivity relations in stupid places where the connectivity can reliably be calculated using existing tags. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Simplifying the relation for roundabouts

Is there a way to simplify the use of these relations for roundabouts?

The way you explained it in your example makes sense, but it would require you to split the roundabout multiple times and create multiple relations.
Is there a way for it to function similar to roundabouts in bus route relations where the roundabout is recognized as a junction and still functions the way it was intended to? Using your first roundabout example as a demonstration, if you wanted to specify how to get from 1-4 your “from” member would be “1”, the “via” member would be the roundabout, and the “to” member would be “4”. This would allow you to minimize the amount of relations needed to accurately describe the lane transitions of this roundabout. --Baconcrisp

Using lane width

If the width of the lanes at the start and the end of an OSM way were tagged, lane connectivity of consecutive ways would be computeable with no other way connected, except where lanes are crossing. Tagging some functional width like zero width of starting or ending lanes, or double width to fork or merge were sufficient. Some pseudo values like "double" or "triple" could be allowed in width:lanes to support this, where the exact width of the lane is unknown. Without requiring any relations the connectivity of following example can be tagged as:

width:lanes:start=0||||0
width:lanes:end=double||||

The :start and the :end suffix need some special handling in editors, but they are required to be used with the placement keys anyway. --Slhh (talk) 22:32, 1 May 2019 (UTC)

An increase in lane width doesn't guarantee anything about connectivity. A lane width could double for no reason at all. – Minh Nguyễn ^💬 14:27, 3 May 2019 (UTC)

Even if it doesn't guarantee anything, it is a good base to calculate the most likely connectivity as a default, which can be overriden by relations where required. In addition zero width guarantees no connectivity of the lane, and where a lane is widened for no reason at the last node, the corresponding lane of at the first node of the consecutive way would also be widened.--Slhh (talk) 16:06, 4 May 2019 (UTC)

The issue here is that splitting a way with the :start and :end tags will instantly break those tags (you mentioned this above). This is the same issue that transit:lanes ran into, and is the reason that that proposal (which tried very hard to avoid relations) failed.

Another reason that this is a bad idea is that it would require splitting highways much more often. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Connectivity tagged on the connection node

It is not possible to tag connectivity on a node in general, but some standard cases could be covered using tagging on the node only. Users do not necessarily need to care about whether connectivity could be tagged on the node, the connectivity can be edited graphically, and the editor has to decide wheather a tag on the node or relations have to be generated.--Slhh (talk) 22:32, 1 May 2019 (UTC)

I think that the use of relations really should't be to much of an issue, and that using tags on nodes wouldn't actually make roads more maintainable. Editors like iD can handle turn restrictions and connectivity relations very well when editing highways, so well in fact that I've only ever been bothered by them a few times. The only thing that iD prevents is disconnecting at the via node. This is actually good, because otherwise the relations would get broken. If the tags where on a node at the connection, disconnecting would not be prevented, and the tagging would become broken. Relations are much easier to maintain than tags on nodes thanks to modern editors like iD. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Splitting of carriageways

A tag like connectivity=devide could identify connecting nodes where the lanes of the way with most lanes are divided up only to the other connected ways. Usecases are e.g.

starting or ending physical separation of directions
connection of motorway-link to motorway (the tag might be assumed as default in this case)

--Slhh (talk) 22:32, 1 May 2019 (UTC)

I'm not sure I understand what this tag would indicate or where it would go. Could you give more details? --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Minor roads connected to major roads

In many cases minor roads like residentials, service, or driveways connect to major roads without influencing the lanes of the major road. A tag on the node could indicate whether the minor road connects to the first lane, the facing direction, or both directions of the major road. This is potentially saving splitting of the major road and many relations.--Slhh (talk) 22:32, 1 May 2019 (UTC)

stop=minor is poorly supported by routers (though this PR would implement it for OSRM). It's also fragile because people can change a way's highway=* class without realizing the effect on nodes along the way. Relying on tags on nodes could exacerbate that situation. – Minh Nguyễn ^💬 14:27, 3 May 2019 (UTC)

A stop sign doesn't seem to be essential for routers, which might be a reason for poor support. stop=minor is indeed fragile due to relying on the full ranking of highways, and the same applies to the transit proposal.

Tagging the minor to major road connectivity on the node can be made much less fragile by using a coarse ranking of highways:

tertiary to motorway
unclassified and residential
service, track, path, cycleway

In case the connected highways are minor/major according to this limited ranking, it is very unlikely to break without being detectable by validators. Requiring lanes on the major road does also support validation.--Slhh (talk) 16:06, 4 May 2019 (UTC)

Default Connectivity

A tag like connectivity=default on the node could be used to indicate that the default connectivity really applies where otherwise some uncertainty would remain.--Slhh (talk) 22:27, 5 May 2019 (UTC)

I like where you are going with this, but again, using a tag on a node is less maintainable with modern editors like iD than relations are. In that case, a default relation would be needed, but that would not be much better than just specifying the lane connectivity with a connectivity relation. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Changes in the Number of Lanes

Is this necessary for changes in the number of lanes?

If a road has 2 lanes and expands into 3 lanes but there aren’t any turn lanes, is a connectivity relation needed? It’s my understanding that showing the lane change in the data would be able to describe this in a general sense. I can see how it would be helpful for drastic lane changes as it would provide more detail to navigation systems, but is a connectivity relation needed for subtle lane changes? --Baconcrisp

@Baconcrisp: As long as placement=* is added to both ways, no relation is needed.

If placement tags would result in incorrect connectivity, a relation should be used. LeifRasmussen (talk) 11:16, 9 July 2019 (UTC)

Turn Lanes Relation

Are you aware of the (abandoned) Turn Lanes Relation proposal? It pretty much goes into the same direction as I understand and is actually in use somewhat. There is also a JOSM plugin available. -- TZorn (talk) 10:28, 6 May 2019 (UTC)

Yes, I am aware of it. It unfortunately has several issues, including

The lack of tagging to state which lanes in the "to" way the lanes in "from" connect to.
Incompatibility with the :lanes suffix (turn:lanes).
Mapping lanes on roads as relations, including how far back those lanes start (this can be very bad in places where roads get split).
Inconsistent use of the tag lanes
Not useful for stating lane connectivity anywhere other than intersections.

This proposal will replace the turnlanes:turns relations in places where turn:lanes is not sufficient. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

I think if you were able to make a plugin for this relation that functions in a similar manner as the plugin mentioned above that it would simplify the tagging for these relations drastically. Right now there is a lot of room for human error. You could accidentally map the incorrect lanes, leave out a lane, etc. If you had a plugin that allowed you see the lanes of the intersection and connect the "from" lane to the appropriate "to" lanes, then have it create the relation(s) for you that would save the editor a lot of time and make maintenance on the relation more manageable. This is just an idea I had. I would be interested to hear your thoughts on it. --Baconcrisp

Ive been slowly working on one, since plugins are written in Java, the language I'm best at. I'll try my best to make it easy to use.

The hard part that am trying to work out is displaying default connectivity. I will need to parse turn:lanes values to do this, which is difficult. Doing this, however, would prevent contributors from adding useless connectivity relations. --LeifRasmussen (talk) 13:15, 7 June 2019 (UTC) LeifRasmussen (talk) 13:15, 7 June 2019 (UTC)

Different connectivity for different transport types

I realized after visiting Denmark last week that there are many cases where a bike lane and vehicle lane will merge into one just before an intersection, and bicycles in that lane will be allowed to go through the intersection, but vehicles can only turn right. In this case, the lanes accessible from the lane in "from" depend on the type of vehicle. I will add a section to this proposal on using connectivity:bicycle, connectivity:motor_vehicle, connectivity:bus, connectivity:psv, and others for these cases. If anyone has any comments about that, please share them here. --LeifRasmussen (talk) 18:10, 14 May 2019 (UTC)

Could you explain the “different connectivity for different transport types” a little more?

I was a little confused in your example with the cycle lane, because I didn’t count that as a traffic lane. If you could give a brief yet detailed explanation of how you would map these that would be very helpful. I believe you have a few examples of bike/bus lanes already in your proposal. I think if you were to explain how to map those types of situations with examples that would help clarify a lot. --Baconcrisp

Yes, I can. By default, the "connectivity" tag indicates the lanes that can be accessed in the "to" way from each "from" lane. It is assumed that whatever type of vehicle that is in the "from" way will be able to access all of the lanes specified in connectivity relation.

For example, if a bike lane in "from" connects to one in "to", it is assumed that since only bikes can use the bike lane in "from", the connectivity is bicycle-only. If a bus lane in "from" is "bus only", and it connects to a normal traffic lane in "to", it can be assumed that the data in the tag "connectivity" is only for buses, since only buses can use the "from" way.

In some rare cases, however, a lane can have different destinations based on which type of vehicle is being used. An example of this would be a bus lane that is also a right turn lane for cars. The connectivity going through the intersection from that lane is only for buses, not cars, so it would make more sense to include all of the other connectivity in the "connectivity" tag, and then specify the connectivity for that lane in a "connectivity:bus" tag.

Unfortunately, that is quite complicated, and not so easy for contributors to understand, so contributors will likely not use them correctly. I am considering removing the tag in favor of forcing data consumers to look at both the "from" lane and "to" lane to make sure that the type of vehicle being used can access both of those lanes. What this means is that a data consumer can't just see that the person using navigation is in the right lane and that a connectivity relation shows that lane as connecting with the road straight ahead. They will also need to ensure that the lane in "to" that the connectivity relation connects the "from" lane to is a normal lane, not a bus or bike lane.

This should cover the vast majority of cases very well, so let me know if I'm missing anything.

I will remove the different connectivity for different modes of transport section from the proposal, since I've realized that it isn't actually necessary in the vast majority of cases, and will most likely just confuse people.

Thanks for asking about this! --LeifRasmussen (talk) 15:43, 22 May 2019 (UTC)

That clarifies a lot. Thank you for taking the time to explain it! I agree that this method should cover the majority of these cases. --Baconcrisp

Direction of Travel in other Countries/Roads

How would this work in countries that drive on the opposite side of the road?

Would the lane syntax remain the same as turn:lanes going from left-right in the direction of travel or would it be flipped to match the local driving customs? --Baconcrisp

This will use left to right numbering in left hand driving countries to match the numbering used in the tag "placement".

Would you need to indicate the direction of travel on the road with a :forward/:backward suffix?

For a two-way road do you need to indicate the direction of travel in the “connectivity=*” tag with the “:forward/:backward” suffix or does the relation define this for the user? --Baconrisp

No. It is assumed that the direction that the numbers refer to is the direction going towards the "via" node/way. --LeifRasmussen (talk) 15:43, 22 May 2019 (UTC)

Clearer Examples

You have a lot of great examples in your proposal, but it’s really hard to see what’s going on in each one so we can compare them to your tagging scheme.

You could have two of the same example, one with the data and notes and one with only the imagery. This would allow readers to easily compare your tagging scheme to the image without having to pull it up.
You might also consider using arrows on some of the more complicated intersections like roundabouts to visually describe how the tagging works.

Overall, I think this would be a very useful addition to OSM. I look forward to seeing it develop further. Please let me know if you have any questions or would like more feedback! --Baconcrisp

I'll clean up the examples. I had placed a link on the right to each relation, but that wasn't very obvious to most readers, so I'll reformat the table. --LeifRasmussen (talk) 15:43, 22 May 2019 (UTC)

Correspondence to turn lanes

Thanks for this proposal!

Consider this situation:

A, B and C have cycleway=lane.

B has turn:lanes=through|right. (Cycle lanes are not treated as a lane and are not taken into account in turn:lanes=* mapping.)

Since for connectivity we should count cycle lanes, we could create these connectivity relations:

from A via i to B: connectivity=1:1,(3)|2:2
from B via ii to C: connectivity=1:1|2:2
from B via ii to D: connectivity=3:1

Doesn't this make seeing a correspondence with the lane-based tags hard? Cross-referencing with turn:lanes=*, destination:lanes=*, maxspeed:lanes=* e.a. is important for lane assistance during navigation. —M!dgard [ talk ] 12:46, 31 May 2019 (UTC)

Thanks for asking about this! I originally read on the osm wiki (when writing this proposal) that bike lanes should be included in turn:lanes=*, so I made my proposal consistent with that.

Few people actually map like that, however (I don't - I did try it, but it was overly complicated and not any better than cycleway=*), so I think that it would better to officially remove bike lanes from all :lanes suffixes and this proposal. The reason for this is that users of:lanes data don't care about (and don't expect to have to process) bike lanes, and users of bike lane data don't care where the bike lanes are relative to vehicle lanes.

So, I'm going to remove bike lanes from this proposal and only include all vehicle lanes (including bus lanes).

I will email the tagging list about this too, and see how many people want to remove the current wiki recommendation of including bike lanes in :lanes suffixes.

Thanks for bringing this up! --LeifRasmussen (talk) 14:42, 31 May 2019 (UTC)

Sad to hear. This will make lane navigation for bicycles impossible. Sometimes bike lanes are quite hard to follow, so this would be a very useful thing.

I think M!dgard isn't quite right about cycle lanes being ignored:

Only the lanes= tag ignores bike lanes (which is weird, why are designated bike lanes ignored but not designated bus lanes? What about bike lanes where buses are allowed on? It's a quite arbitrary exclusion …) See also here.
However, :lanes is explicitly meant for all lanes, including bicycle lanes. There's even an example for OP's situation.

Can you please try to find a solution that doesn't exclude bike lanes? Ideally, there'd also be a proposal to count all lanes in lanes= and restrict individual lines for certain vehicles, if necessary. --Jomox (talk) 11:19, 3 June 2019 (UTC)

Why I'd ignore bike lanes but not bus lanes: because by law they are a special case (they aren't part of the "road for driving", Dutch: "rijbaan"), and the vast majority of bike lanes over here are not interesting when you look at lanes (see photo). We have a large amount of cycle lanes but I've never seen one being taken into account in …:lanes.

So we should add lanes=2, access:lanes=||no, bicycle:lanes=||designated, moped:lanes=||designated, moped_b:lanes=||yes and turn:lanes=left;through|through|none to the SW→NE street before the junction? —M!dgard [ talk ] 14:31, 3 June 2019 (UTC)

The situation is quite different depending on the country. Obviously when the 'rijbaan' is a separate bikeway and not a lane on the road (I guess that's most bikeways in NL, from my personal experience), it shouldn't be tagged as such. Otherwise it should be tagged what's on the ground, not what's the local legal definition of a lane.

[Edit: 'rijbaan' (bike path) is different from 'fietsstrook' (bike lane, which IS part of the road but not a lane by legal definition)]

In Germany it's not totally uncommon to have multiple bike lanes between car lanes on the road, with each car and bike lanes having different turn restrictions. One example of crazy bike lanes can be seen here. How would bike lanes like these and their connectivity (and turn restrictions) be tagged under this proposal? --Jomox (talk) 17:14, 3 June 2019 (UTC)

Here's how I'll word the proposal to work everywhere: include all lanes tagged in the :lanes tags in connectivity=*. This way, connectivity relations can be used wherever and however people want. --LeifRasmussen (talk) 19:22, 3 June 2019 (UTC)

Looks good to me! —M!dgard [ talk ] 20:54, 3 June 2019 (UTC)

Using ways as via members

The examples should clearly indicate whether a way or a node is used as the via member, but there are issues with using via ways anyway:

In case of a via member way, the used lane of this way needs to be defined for each connectivity. This is required to generate reasonable instructions for the driver.

In case of supporting a way as the via member, we need to support multiple via ways too. Otherwise, splitting the via way needs to be prevented in the editor to protect the connectivity relation, which is quite undesirable because splitting a way is too essential to be prevented.

The combination of both points seems to be hard.--Slhh (talk) 00:46, 5 June 2019 (UTC)

Here's how I thought way members would work: if a person is driving in a lane in "from" and will traverse all specified via ways to get to "to", then their navigation can use the connectivity relation to "bypass" the via ways and just know the in-to-out connectivity of the intersection. This would really only be used where the via ways don't have marked lanes (common in multi lane traffic circles) but the connectivity of the ways entering and leaving this way is specified in some way on the ground. If the via way has marked lanes, no connectivity relations with via ways should be necessary.

As for having multiple via ways, I see no reason why this isn't valid. I'll specify more clearly in the proposal that it's possible to use multiple via ways, and add a section explaining what that would mean.

Thanks for pointing this out! --LeifRasmussen (talk) 02:13, 5 June 2019 (UTC)

“Any number of ways may be included as via members, but it is always better to just include a node for clarity.”

I'm confused by the last part of that sentence. Do you mean to ask for “use a node instead of a way if you can” and “use as few via ways as possible”? It's not completely clear to me how you even could use ways if you should be using a node. Something like a connectivity relation from

332035034 to

9934744 and using the in-between ways as via? Do you have other potential errors in mind? —M!dgard [ talk ] 15:45, 5 June 2019 (UTC)

I updated the page to be as clear as possible about via ways. LeifRasmussen (talk) 09:40, 3 July 2019 (UTC)

Connectivity and markings

What does it mean visually for two lanes to be connected? At a non-junction node, my interpretation of the proposal so far is that a connectivity relation tells me something about the markings: If there's a connection without brackets, then the lane continues without having to cross markings:

I'm also wondering about junction nodes and ways (which may lack most or all markings), but is the reading illustrated above accurate for non-junction nodes at least? --Tordanik 16:02, 4 July 2019 (UTC)

Yes, that's accurate. For junctions, here's how I think about what counts as what: if the connection is default, meaning that staying in the same lane would result in entering the to lane, no parentheses are used. Else, parentheses are used (as long as the to lane is still a connected to the from way). If there are two lanes that are both equally default, no parentheses are used. This is regardless of lane markings, but lane markings will often times corispond accurately to the connectivity.

LeifRasmussen (talk) 20:24, 4 July 2019 (UTC)

Adding to that comment, the data consumer reason for splitting up the two types of connectivity was to allow for two different formats at once. One format (no parentheses) is for knowing where a lane will end up if it's followed to the end. The other (with parentheses) is for knowing all lanes that will be directly accessable from a given lane. An example of this is taking an exit: it's not the default path of the lane, but is still possible. LeifRasmussen (talk) 10:42, 5 July 2019 (UTC)

If all the other accessible lanes are tagged with parenthesis, a simple connection of two adjacent oneways with two changable lanes each will already need a connectivity=1:1,(2)|2:(1),2. This special example case might be considered as a default connectivity, but it shows the unnessesary complexity.

All connectivity in parenthesis should better be omitted where the connectivity is not essentially focused to the via node.

The examples geometries drawn above might indeed be reasonable usecases for tagging such connectivity in parenthesis, because there are quite steep angles with are essentially focussing the lane change to the via node. Especially, if lanes aren't changeable in the "to" way anymore, the connectivity tagged in parenthesis is functionally mandatory. If the angles were slight and lanes were still changeable in the "to" way, the lane would substantially be changed in the "to" way, which allows to omit the tagging of that connectivity because it is alrady defined using key "change:lanes".--Slhh (talk) 00:27, 10 July 2019 (UTC)

Complexity

Some of the voters so far have commented on this proposal's complexity. I'd like to point out that lane connectivity is inherently complex, and that this proposal does a good job of making it no simpler than required for the job. As a mapper who does a lot of manual tagging, I understand the reticence to introduce another relation type, but relations are the most robust tool for expressing relationships between different ways. The transit=* proposal failed in large part because it tried to avoid relations in favor of tags on ways, tags that can easily become invalid and outdated as ways are split. By contrast, this connectivity relation proposal optimizes for ongoing maintenance over initial entry. I think that's a fair tradeoff, because while connectivity relations wouldn't be exceedingly rare, they'd be uncommon enough that only mappers focused on lanes would need to worry about them for the most part. Someone focusing on road names or speed limits can split ways without worrying about breakage.

It's true that some OSM-powered navigation software can already display lane guidance. I work on one such library for Mapbox, though I got involved with this proposal on a personal basis. I've done lots and lots of turn lane mapping on the side and have discovered situations where these these relations are needed for proper lane guidance. Besides the examples given in the proposal, here are just a few more off the top of my head (switch to OSIP or Mapbox imagery):

Fast-growing American suburbs have lots of four-way intersections with multiple left or right turn lanes. By default, or in the absence of dashed lane markings, the leftmost lane connects to the leftmost lane of the cross street, the #2 lane connects to the #2 lane, and the rightmost left turn lane connects to any remaining lanes of the cross street. [1]
But there are countless exceptions where dashed lane markings are required, like this four-way intersection in West Chester, Ohio. The leftmost turn lane on northbound Mulhauser Road connects to only one lane on westbound Union Centre Boulevard, whereas the leftmost turn lane on southbound Mulhauser connects to two lanes on eastbound Union Centre. The lane you take depends on whether you want to take the ramp onto southbound I-75 or continue eastbound on Union Centre.
Similarly, in this intersection in Florence, Kentucky, the leftmost of two left turn lanes on southbound Houston Road connects to two lanes on eastbound Burlington Pike, while the leftmost of two left turn lanes on eastbound Burlington connects to just one lane on northbound Houston.
Sometimes the middle lane connects to multiple lanes. In this intersection in San José, California, the freeway off-ramp has three right turn lanes, which connect to one lane, two lanes, and one lane of Tully Road, respectively.
At a superstreet intersection, like this one in Fairfield, Ohio, you need to take a specific right turn lane in order to take a specific U-turn lane in order to take a specific right turn lane. Elsewhere along this superstreet, going southbound, which right turn lane you take determines whether you go northbound or southbound on Dixie Highway via the connector road. But going northbound, the single left turn lane connects to any of the three lanes on the connector road.
This intersection in Bedford, Texas, features a Texas U-turn, in which a single lane connects to two channelized U-turn lanes (mapped as a single highway=secondary_link way) and a left turn lane that's part of the main intersection.
I can't understand why they laid out the road this way, but in Cupertino, California, one of the middle lanes of Wolfe Road merges into another middle lane, with the lane to the right continuing past unaffected.

In these examples, placement=* would be of little help, and change:lanes=* also fails to capture lane-change restrictions through the intersection. Where there are per-lane destination signs, destination:lanes=* could indicate the best lane to take, but routers can't be too strict about per-lane destinations, or else there would be false negatives on motorways where destination signs are inconsistent, like alternating between John F. Kennedy Road and Kennedy Road based on available space. Along this stretch of eastbound Fort Washington Way leading to I-471, the set of destinations for a given lane changes multiple times as less important destinations get bumped down in priority.

Mapbox/OSRM and OsmAnd display turn lane icons based on the way closest to the maneuver, but the logic for timing a voice instruction is based on a hardcoded distance or time, irrespective of lane change restrictions. It's a poor experience if the driver is told to get into a turn lane after the lane change restriction begins and they have to ask to cut in line. I wrote Apple Turnover, a sloppy, proof-of-concept turn lane analyzer, in attempt to gain insights about turn lane lengths in aggregate. In doing so, I learned that there's a ton of variance in turn lane lengths that can't necessarily be generalized based on road class, speed, etc. Figuring out how many ways form a single turn lane can be challenging in itself. For that weekend project, I didn't get as far as adding support for placement=* or turn restrictions, but I did have to make lots of assumptions about how turn lanes behave across intersections.

I was unsurprised and not particularly saddened about the rejection of the transit=* proposal, but this proposal is different. It fills a hole in our data model in a way that respects existing tagging patterns. Even if you're satisfied with the current state of OSM-powered lane guidance, I'd suggest that less experienced, more stressed-out drivers would still benefit in the form of better instruction timing. Hopefully these relations won't be ubiquitous, but where they exist, they'll be essential for drivers.

– Minh Nguyễn ^💬 02:49, 9 July 2019 (UTC)