Proposal:Transit

How a lane continues in the next road segment
Proposal status:	Abandoned (inactive)
Proposed by:	imagic
Tagging:	`transit=continue/fork/join_with_left/join_with_right/new_on_left/new_on_right/end/leave`
Applies to:
Definition:	Specify how a lane continues in the next road segment, i.e. if and where it forks/joins
Statistics:
Rendered as:	Some renderers (e.g. included in navigation devices) may show the lanes at very high zoom level
Draft started:	2015-01-13

This proposal introduces the key and relation transit which allows to specify how a lane continues in the next road segment, i.e. if and where it forks/joins. It is intended to be used together with the suffixes :lanes, :forward or :backward.

Original idea from hurdygurdyman and others.

Due to fundamental design issues using this tag on ways was described as a horrible tagging scheme by iD, Vespucci and JOSM developers, see https://lists.openstreetmap.org/pipermail/tagging/2018-June/037082.html and https://lists.openstreetmap.org/pipermail/tagging/2018-June/037105.html and https://josm.openstreetmap.de/ticket/11054 and they refused to support it.

Short overview - TL;DR

This proposal introduces one new key transit=* with eight possible values which can be used either as a tag directly on an OSM way or within a relation with type=transit. The key can be used to specify how the lanes of two immediately adjacent OSM ways connect to each other.

While the key may only be used in simple situations (like one-ways or if the road they refer to, carries the same name or reference), the relation can be used in every situation.

Rationale

This tagging scheme is intended to provide the information how the lanes of different road segments connect to each other. A key as well as a relation is proposed, both with the same syntax:

The key transit=* can be used directly on OSM ways, usually together with the suffixes :lanes, :forward or :backward
The relation type=transit requires two OSM ways as members (from and to) and the key transit=*, usually together with the suffix :lanes.

As the connection between different road segments always refers to two OSM ways (the "from-way" and the "to-way"), the key transit=* is ambiguous as soon as more than two ways connect at one node. The reason for introducing the key transit=* nonetheless is the higher expected acceptance within the community. In many situations the data consumer is able to determine the correct to-way based on some simple rules (as explained below). If we allow the mapper to specify the lane connection in such a situation as a tag instead of a relation, it would not be necessary to switch back and forth from simple tags (e.g. turn:lanes=*) to a relation, when all the mapper does all the time is mapping lanes.

The proposed key compared to the proposed relation moves a little burden from the mappers to the consumers. It needs more processing of the data and it can not be used in all situations. But in many situation this key should be sufficient and it allows a more continuous, uninterrupted mapping process and therefore we can expect higher acceptance in the community.

Tagging

The key transit=* supports the following values:

Value	Lane change
continue	The lane doesn't fork/join/etc., but simply continues.
fork	The lane forks to two lanes, whereby both following lanes are accessible without lane change.
new_on_left	Left of that lane a new lane appears; to access the new lane, one has to change to that lane. This value does not provide information about the current lane and should be combined with another appropriate value. If it is not combined with any value besides `new_on_right`, it should be assumed that it is combined with `continue`, i.e. for example `continue\|continue;new_on_left` and `continue\|new_on_left` are equivalent.
new_on_right	Right of that lane a new lane appears; to access the new lane, one has to change to that lane. This value does not provide information about the current lane and should be combined with another appropriate value. If it is not combined with any value besides `new_on_left`, it should be assumed that it is combined with `continue`, i.e. for example `continue\|continue;new_on_right` and `continue\|new_on_right` are equivalent.
join_with_left	This lane joins with the lane to the left of the current road segment, whereby the joined lane is reachable without lane change from both lanes. This value must not be used on the leftmost lane.
join_with_right	This lane joins with the lane to the right of the current road segment, whereby the joined lane is reachable without lane change from both lanes. This value must not be used on the rightmost lane.
end	The lane ends.
leave	This lane separates from this road, i.e. it leaves.

The values fork, new_on_left and new_on_right may be extended by :number in order to provide the number of lanes the way forks to resp. the number of new lanes. For examples transit=fork:3 means that the single lane of an oneway forks into three lanes.

Combination of values

Only the values new_on_left and new_on_right (and their variants with an arbitrary number of lanes) may be combined with other values using the usual semi-colon syntax, e.g. transit=new_on_left;continue;new_on_right means that the single lane of an oneway is connected to the middle lane of three lanes in the the to-way. Other combinations are invalid as well as combinations of new_on_left resp. new_on_right with their variants with an arbitrary number of lanes.

Suffixes

The key transit=* may be combined with the usual suffixes, mostly :lanes, :forward and :backward. See the section "See also" for further reference.

Determining the correct values

When determining the correct values, only consider those two road segments the tag/relation refers to and completely ignore others, but you have to consider all lanes of both road segments. In the example on the right we only consider the left from-way and ignore the right way. Therefore we get the tag transit:lanes=continue|new_on_right, which can be read as: the first lane continues and at the right side of the second lane another one emerges, i.e. in the following road segment we have three lanes.

If we would consider both from-ways in the example to the right, we might be tempted to specify ~~transit:lanes=continue|join_with_right~~, which is incorrect as the lanes that join are from different road segments. If we only considers the left from-way, we do not see any lanes joining and therefore will determine the correct values.

Used as tag on ways

The key transit=* is added to the from-way (as defined above), usually with appropriate suffixes. The value of the key specifies how a lane forks or joins directly at the transition to the to-way.

The tag must not be used if the from-way contains lanes used by traffic going in both directions. In such case the relation has to be used.

Note: If the key is used together with the suffix :backward (i.e. either as transit:backward=* or transit:lanes:backward=*) on an OSM way it describes the transition in reverse direction, i.e. in the opposite direction of the OSM way. In such case the to-way for transit:backward=* is different from the to-way for transit:forward=*.

Rules for determining the relevant OSM ways

As soon as more than two OSM ways connect, the key transit=* is ambiguous. If the mapper decides against the use of the relation in such situation, the consumer needs to determine the to-way, which the tags refer to. This should be done according to the following rules in the given order:

Identical value of the key ref=*
Identical value of the key name=*
Identical value of the key highway=*

If after the application of those rules, the to-way can still not be determined unambiguous, it shall be assumed that the to-way is the one with the smallest angle to the from-way.

The use of the key transit=* should be limited to simple situations. Generally, in more complex situations with multiple OSM ways meeting at one node, the use of the relation should be preferred.

Used as relation

In situations where it is not possible for data consumers to determine the correct to-way of the tag, the relation can be used. The relation requires exactly two members: the from-way with role "from" and the to-way with role "to", whereas one end of both ways must be connected to each other. Note: Further members are strictly forbidden, especially so called via-nodes or -ways as known from other relations.

The following tags have to be specified for the relation:

Tag	M/O¹	Description
`type=transit`	M	Identifies as transit-relation.
`transit=*`	M	This key uses the same values as describe above. It may be used with the usual suffixes :lanes, :forward or :backward. It is possible to add this key twice, once with suffix :forward and once with suffix :backward. For sake of readability it is strongly recommended to use the suffix :forward if :backward is also used.
`through_route=yes/no`	O	This tag can be used to specify if this direction is the "main route" or if you would have to "turn" to follow that direction. This problem of determining the correct "main route" is a well-known problem of routing (so called bifurcation).

¹ M=Mandatory, O=Optional

Note: If the key is used together with the suffix :backward (i.e. either as transit:backward=* or transit:lanes:backward=*) within the relation it describes the transition in reverse direction, i.e. from the to-way back to the from-way. This is different to the use of the key directly on OSM ways! Therefore the use of the suffix :backward is not recommend within the relation.

When to use and when not

The transit key/relation is not intended to be used for all connections of road segments. It should only be used on connections which are not obvious and where it is not possible for data consumers to determine the lane connections otherwise. It is recommend that every data consumers supports at least the following and therefore mappers may not provide transit-information in the following cases:

the number of lanes is unchanged
the number of lanes changes, but on both related OSM ways the key placement=* is either specified (except with the value transition) or is unnecessary, because the OSM way is drawn in the middle of the carriageway
in case of a left-turn, all lanes leading left are marked with one, unique value *_left of the key turn=* and only one possibility to turn left exists
in case of a right-turn, all lanes leading right are marked with one, unique value *_right of the key turn=* and only one possibility to turn right exists

Examples

If not stated otherwise, the following is assumed in the examples:

Right-hand traffic
the direction of the OSM way (green line) is upwards

Using the key

#	Description	Tags on from/to way
1	A one-way road with two lanes, where a third lane starts at the right side.	To way
		lanes=3 turn:lanes=none\|through\|right placement=right_of:1
		From way
		lanes=2 turn:lanes=none\|through;right transit:lanes=continue\|new_on_right Note: the second value (i.e. new_on_right) in this example is the short form of continue;new_on_right.
2	A one-way road with two lanes, where the rightmost lane forks into two lanes.	To way
		lanes=3 turn:lanes=none\|through\|right placement=right_of:1
		From way
		lanes=2 turn:lanes=none\|through;right transit:lanes=continue\|fork
3	A one-way road with two lanes, where a third lane starts at the left side.	To way
		lanes=3 turn:lanes=left\|through\|none placement=right_of:2
		From way
		lanes=2 turn:lanes=left;through\|none transit:lanes=new_on_left\|continue
4	A road with one to three lanes in each direction. In forward direction the road starts with one lane and a deceleration lane is then added on the right side. In backward direction the road starts with two lanes and a third lane is added on the left side for overtaking because of the steep slope of the road.	To way
		lanes:forward=2 lanes:backward=2 turn:lanes:forward=none\|slight_right transit:lanes:backward=new_on_left\|continue
		From way
		lanes:forward=1 lanes:backward=3 placement:forward=left_of:1 hgv:lanes:backward=no\|yes\|yes transit:forward=new_on_right
5	A one-way road that leads to a Y-shaped junction. Although the road to the right after the junction has the same reference as the road before the junction, the "main direction" of the road (i.e. what a human would call "follow the road") is left.	This can not be specified with this tag. You need to use the relation, because it is not possible to determine the correct "following" road segment and without relation you are losing the information about the main direction of the road.
6	Two one-way roads join, whereas the lanes of these roads simply continue and do not join.	To way
		lanes=4
		From way
		Tags of the road to the left: lanes=2 placement:end=right_of:2 No transit tag necessary Tags of the road to the right: lanes=2 placement:end=left_of:1 No transit tag necessary
7	The two middle lanes of an one-way road with four lanes join.	To way
		lanes=3 placement=transition
		From way
		lanes=4 transit:lanes=continue\|join_with_right\|join_with_left\|continue
8	Two one-way roads join, whereas the inner lane of them joins.	To way
		lanes=3 width:lanes:start=2\|4\|2 width:lanes:end=2\|2\|2
		From way
		Tags of the road to the left: lanes=2 placement:end=right_of:2 transit:lanes=continue\|new_on_right Tags of the road to the right: lanes=2 placement:end=left_of:1 transit:lanes=new_on_left\|continue Note: Do not use `join_with_*` in this case, because the lanes that join are on different road segments.
9a	An acceleration lane on a motorway. The lane ends and it is necessary to change to a different lane.	To way
		lanes=2
		From way
		lanes=3 placement=right_of:1 turn:lanes=none\|none\|merge_to_left transit:lanes=continue\|continue\|end
9b	The same as before, but now it is not necessary to change the lane.	To way
		lanes=2
		From way
		lanes=3 placement=right_of:1 turn:lanes=none\|none\|merge_to_left transit:lanes=continue\|join_with_right\|join_with_left
10	A one-way road with three lanes, whereas the leftmost lane leaves this road.	To way
		Tags of the road to the left: lanes=1 placement=transition Tags of the road to the right: lanes=2
		From way
		lanes=3 placement=right_of:2 turn:lanes=left\|through\|none transit:lanes=leave\|continue\|continue
11	All OSM ways lead to the centre of the junction, whereas lanes in forward direction are in dark grey and lanes in backward direction in light grey. This examples is very complex and can only be solved with the relation (see below), as it is impossible for the data consumer to determine the correct OSM way the tags refer to.	Way A
		oneway=yes ref=A1 turn:lanes=left\|through\|right placement=right_of:1
		Way B
		lanes=2 ref=B2 name=Upway Road
		Way C
		lanes=2 ref=L1234
		Way D
		lanes=4 ref=B2 name=Somewhere Street lanes:forward=2 lanes:backward=2 turn:lanes:forward=none\|right

Note: Be cautious when tagging two-way roads. The values ending with _left and _right are viewed in the direction of the OSM-way unless they are used in conjunction with the :backward suffix. Therefore it is strongly recommend to always use the :forward/:backward suffix on two-way roads.

Using the relation

#	Description	Tags on from/to way	Relation(s)
A	A one-way road that leads to a Y-shaped junction. Although the road to the right after the junction has the same reference as the road before the junction, the "main direction" of the road (i.e. what a human would call "follow the road") is left.	To way	Left	Right
		Tags of the road to the left: lanes=2 ref=A1 Tags of the road to the right: lanes=2 ref=B2	type=transit transit:lanes=continue\|continue through_route=yes	type=transit transit:lanes=leave\|fork
		From way
		lanes=2 ref=B2 turn:lanes=none\|right
B1	All OSM ways lead to the centre of the junction, whereas lanes in forward direction are in dark grey and lanes in backward direction in light grey.	Way A	A -> C	B -> D
		oneway=yes ref=A1 turn:lanes=left\|through\|right placement=right_of:1	type=transit transit:lanes=leave\|continue\|leave	type=transit transit=new_on_right
		Way B
		lanes=2 ref=B2 name=Upway Road
		Way C	C -> D	D -> B
		lanes=2 ref=L1234	type=transit transit=new_on_right	type=transit transit:lanes=continue\|leave Alternative to relation B -> D: type=transit transit:lanes:forward=continue\|leave transit:backward=new_on_right
		Way D
		lanes=4 ref=B2 name=Somewhere Street lanes:forward=2 lanes:backward=2 turn:lanes:forward=none\|right
B2	Same as above but now for left-hand traffic.	Way A	A -> C	B -> D
		oneway=yes ref=A1 turn:lanes=left\|through\|right placement=right_of:2	type=transit transit:lanes=leave\|continue\|leave	type=transit transit=new_on_left
		Way B
		lanes=2 ref=B2 name=Upway Road
		Way C	C -> D	D -> B
		lanes=2 ref=L1234	type=transit transit=new_on_right	type=transit transit:lanes=continue\|leave Alternative to relation B -> D: type=transit transit:lanes:forward=continue\|leave transit:backward=new_on_left
		Way D
		lanes=4 ref=B2 name=Somewhere Street lanes:forward=2 lanes:backward=2 turn:lanes:forward=none\|right

Common questions

Why not only use a relation for this?

Please read the section Rationale again, especially the paragraph starting with "The proposed key compared to the proposed relation moves a little burden".

What variants of the transit key are possible

The transit key uses common and established suffixes like :forward and :backward and of course :lanes. Possible variants include:

transit
transit:forward
transit:backward
transit:lanes
transit:lanes:forward
transit:lanes:backward

What about left-hand traffic?

Everything works the same.

Are bicycle lanes covered?

Yes. As explained in the proposal of the lanes suffix, contrary to the key lanes=*, the lane-dependent values of tags ending on :lanes cover all lanes, independent of the kind of traffic they are designated to.

How are lanes connected, that allow driving in both directions

They are considered in both directions, as if they were lanes in that direction. In the example to the right the red marked way contains three lanes: one backward, one in the middle for both directions and one forward.

When one wants to specify the lane connections from the way below the red way up to the red way, one may use transit:lanes:forward=continue|continue although the red way has only one forward lane, but the lane in the middle is treated as if it was a forward lane.

Important note: If the from-way contains lanes for both driving directions, the tag must not be used. One has to use the relation if the from-way contains lanes for both driving directions.

How do I specify that some lane connection is only permitted for buses/taxi/bicycles?

With some access tags or the turning restriction relation, but not with this tagging scheme. This scheme specifies how the lanes are linked on the ground. It does not provide any access or turning restrictions as there are already established concepts for these.

In some rare situations we would need lane-based turning restrictions. But to provide such information the turning restriction relation should be extended by the well-known :lanes concept, so that all turning restrictions are kept in one place. For example if one has to turn right if driving on the third lane, one could specify this with the tag restriction:lanes=||only_right_turn within a restriction relation.

How does key/relation transit compare to the key turn?

These are two completely different concepts.

The key turn=* specifies for one road segment the indicated direction in which a way or a lane will lead
The key and relation transit=* specifies how the lanes of two adjacent road segments connect to each other.

Wouldn't be merge_with_XXX be better instead of join_with_XXX?

The values merge_to_XXX are in use with the key turn=*, where they refer to the traffic that has to merge with the traffic of a different lane. Using very similar values with the key transit=* might lead to some irritations and mistakes as the meaning would be quite different.

Current usage

transit:lanes=*

transit:lanes:forward=*

transit:lanes:backward=*

transit=*

transit:forward=*

transit:backward=*

Comments

Please use the Discussion page for this.

Related keys

turn=*
placement=*

Guideline for data consumers

This section provides a guideline how to determine lane connections between two road segments dependent on the available information, and how to render individual lanes.

This section is work in progress!

Determining lane connections

In this section the following special terms will be used:

Connecting Node means each node, that is part of more than one relevant OSM way.
All OSM ways that are connected to a Connecting Node, shall be called Connected Ways.
Entering Way in relation to a specific Connecting Node means a Connected Way, that allows driving up to that Connecting Node. Exit Way in relation to a specific Connecting Node means a Connected Way, that allows driving away from that Connecting Node. Note: a single Connected Way might be an Entering Way and Exit Way at the same time.
Connection means a specific pair of Entering Way and Exit Way and From Way means the Entering Way and To Way means the Exit Way of such Connection. For a Reverse Connection of a Connection the To Way and From Way are exchanged. Note: a Reverse Connection may not exist, e.g. if the From Way of a Connection is a Entering Way but not also an Exit Way, no Reverse Connection for the respective Connection exits.
In relation to the connection of a specific pair of Entering Way and Exit Way, Left Turn, Right Turn resp. Straight On means that that specific connection (in the specific direction from Entering Way to Exit Way!) should be considered a left turn, right turn resp. straight on, as specified below.
The rules given in this section provide the lane connections for all Connected Ways for one single Connecting Node.

Furthermore the following is assumed:

Only consider relevant OSM ways, e.g. those road classes given in the table below.
Treat all OSM ways as being split at the Connecting Node, i.e. if the connecting node is not an end-node of an OSM way, treat such OSM way as two separate OSM ways ending in the connecting node. Immediately connect all the lanes of its two parts one-on-one and make sure not to try to determine the lane connections in the further processing!
For the determination of angles between OSM ways, only consider the Connecting Node and the first adjacent node of each OSM way.
Pay attention to to possible endless loops and treat them as data errors, especially when processing join_with_left or join_with_right.
Pay close attention to the meaning of the :forward and :backward suffix when used together with the tag or relation:
- The suffix :backward will result in the same from-way but in a different to-way, when used in the transit tag.
- The suffix :backward will result in the from- and to-way replaced by each other, when used in the relation.
If not stated otherwise, in every situation only one driving direction is considered. Pay attention to lanes for both driving directions!
If after processing all possible Connections some lane connection have not been determined, treat this as data error.

Preparation:

For all Connected Ways, determine the number of lanes separately for both driving directions as follows:
- Number of lane-dependent values of all relevant key with suffix :lanes. Such number has to be identical for all keys relating to one driving direction. If the number is not identical, it shall be considered a data error. As fall-back strategy 1) use that number, that occurs most frequently resp. 2) use the lowest of those numbers if 1) is not unique.
- The value of the key lanes=* resp. its relevant subkey.
- Assume the number of lanes depending on the type of road as specified in the table below.
Pay close attention to lanes for both driving directions! Example: lanes:forward=1 + lanes:backward=1 + lanes:both_ways=1 results in two lanes in each direction.

Verify all lane-dependent values of transit tags or relation: if a value only contains new_on_left and/or new_on_right, treat it as if continue is also present.

Determine to which Exit Way the tag transit of a given Entering Way refers.
- If the OSM way is directed to the Connecting Node, do not consider transit tags with the suffix :backward.
- If the OSM way is directed away from the Connecting Node, only consider transit tags with the suffix :backward.
- Select all Exit Ways and then remove those that do not fit the following rules in the given order. After each rule verify if exactly one Exit Way is left over. If so, the tag transit refers to that Exit Way.
  - The value of ref=* of the Exit Way is identical to the value of ref=* of the Entering Way.
  - The value of name=* of the Exit Way is identical to the value of name=* of the Entering Way.
  - The value of highway=* of the Exit Way is identical to the value of highway=* of the Entering Way.
- If no result was achieved after those rules, the tag transit shall refer to that Exit Way, for which the angle to the Entering Way is smallest. If this is still ambiguous use that way of the remaining Entering Ways, that carries the smallest OSM ID.

Determine for all possible Connections of all Entering Ways that have turn indications specified via turn=*, if if they should be considered a Turn Left, Turn Right or Straight On. To do so, process all possible Connections of one Entering Way and then proceed to the next Entering Way. Verify for all possible Connections of one Entering Way the first of the following rules, then verify for all Connections that have not yet been identified the second rule, and so on. Rules are:
- If the respective To Way is the only Exit Way, the Connection is a Straight On.
- If the respective To Way is a highway=motorway, the Connection is a Straight On.
- If a turning restriction is specified for this Connection and if restriction is:
  - *_left_turn, consider the Connection a Left Turn and a potential Reverse Connection a Right Turn
  - *_right_turn, consider the Connection a Right Turn and a potential Reverse Connection a Left turn
  - *_u_turn, (TODO: fix this) if right-hand traffic, consider the Connection a Left Turn and a potential Reverse Connection a Right Turn, otherwise consider the Connection a Right Turn and a potential Reverse Connection a Left Turn
  - *_straight_on, consider the Connection/Reverse Connection a Straight On
- TODO: Bei getrennt gemappten Fahrtrichtungen, schlägt das fehl: If up to now no Straight On has been identified: If the respective To Way is the only Exit Way that has the same reference as the From Way, the respective Connection/Reverse Connection is a Straight On. If a common reference can not be found: if the respective To Way is the only Exit Way that has the same name as the From Way, the respective Connection/Reverse Connection is a Straight On. If a common name can also not be found: if the From Way has the highest road class and the To Way is the only Exit Way that has the same road class, the respective Connection/Reverse Connection is a Straight On. (This is one single rule)
- For all further rules: determine the angle between the From Way and the To Way of all (i.e. also already identified) Connections of the current Entering Way.
- If up to now no Straight On has been identified: if the smallest angle of all unidentified Connections is between -20° and +20°, that respective Connection and its Reverse Connection is a Straight On.
- If at least one Straight On has been identified: if the angle of a Connection is below the smallest angle of all Straight Ons, that Connection is a Left Turn and its Reverse Connection is a Right Turn. (In simple words: if the To Way is left of the leftmost Straight On)
- If at least one Straight On has been identified: if the angle of a Connection is above the highest angle of all Straight Ons, that Connection is a Right Turn and its Reverse Connection is a Left Turn. (In simple words: if the To Way is right of the rightmost Straight On)
- If more than one Straight On has been identified: if the angle of a Connection is below the smallest angle and above the highest angle of all Straight Ons, treat this as data error and consider the Connection/Reverse Connection a Straight On. (In simple words: if this Connection is between the leftmost and rightmost Straight On)
- Finally: If the angle of the Connection is below 0°, the Connection is a Left Turn and a potential Reverse Connection a Right Turn, otherwise the Connection is a Right Turn and a potential Reverse Connection a Left Turn.

TODO: u-turn

Determining lane connections:

Collect all Connected Ways for the given Connecting Node

First - the easy part - process all Connections, for which transit information (via tags or relations for the relevant direction!) is available. Connections may be processed in random order.
- Process one lane after the other of the From Way from left to right and connect it to zero, one or more ways of the To Way, as specified below. After connecting lanes skip to the following lane in the From Way resp. To Way, if not mentioned otherwise. If multiple values are given for on lane, process the value new_on_left first and new_on_right last.
- continue: connect this lane to the next lane of the To Way.
- fork: connect this lane to the next two lanes of the To Way.
- fork:number: connect this lane to the given number of lanes of the To Way.
- new_on_left: skip one lane in the To Way (i.e. it is not connected to the From Way). This value always must be the first value of a lane to be processed.
- new_on_left:number: skip the given number of lanes in the To Way (i.e. they are not connected to the From Way). This value always must be the first value of a lane to be processed.
- new_on_right: skip one lane in the To Way (i.e. it is not connected to the From Way). This value always must be the last value of a lane to be processed.
- new_on_right:number: skip the given number of lanes in the To Way (i.e. they are not connected to the From Way). This value always must be the last value of a lane to be processed.
- join_with_left: connect this lane to the next lane in the To Way. If this is the value of the leftmost lane of the From Way, additionally treat it as data error.
- join_with_right: connect this lane to the next lane in the To Way, but do not skip to the next lane in the To Way. If this is the value of the rightmost lane of the From Way, additionally treat it as data error.
- end: skip to the next lane of the From Way, but do not skip to the next lane in the To Way.
- leave: skip to the next lane of the From Way, but do not skip to the next lane in the To Way.

All the following rules represent some kind of "guessing-strategy", because all other tags and relations only provide hints regarding lane connectivity but not a precise specification. Also this strategy is based on the previous determination (i.e. guessing) of Straight On, Left Turn and Right Turn, which may or may not be correct. Different consumers might use different strategies.
From now on only connect lanes with identical designation, e.g. if a lane is designated to bicycles (i.e. bicycle:lanes=...|designated|...) only connect it to a lane, that is also designated to bicycles. It might be a good idea to process lanes with different designation separately.

Second process those Connections, for which transit information (via tags or relations for the relevant direction!) is not available and which are Straight On.
- If the number of lanes in the To Way compared to the number of lanes in the From Way is
  - identical: connect all lanes one on one.
  - lower: based on the (assumed or explicitly specified placement-values, determine an appropriate lane offset and connect adjacent lanes (see section below). Treat unconnected lanes of the From Way as ending.
  - higher: based on the (assumed or explicitly specified placement-values, determine an appropriate lane offset and connect adjacent lanes (see section below). Treat unconnected lanes of the To Way as new, beginning lanes.
- After connecting the lanes of a Straight On, check if the lanes in the To Way have the same turning indications as in the From Way. If so, ignore those turning indications in the From Way from now on (especially when processing a Left/Right Turn connection). Pay attention to multiple turning indications on one lane: if e.g. a lane in the From Way has the indication through;right and in the To Way only through, then treat the indication in the From Way from now on as only right.

Third process all Entering Ways, for which up to now not all possible Connections have been fully determined. Note: Differently to before one Connection is now not completely processed and all lanes are linked. Instead one or more lanes of one Entering Way are connected to one or more Exit Ways, i.e. multiple Connections are processed at a time.
- If for the leftmost lane of the Entering Way a turning indication with *left is specified (note: some turning indications may have been removed while processing Straight On connections):
  - Determine the number of variations of *left in the turning indications of all lanes, e.g. two, if "sharp_left" and "left" is present, or one if only "slight_left" is present. If this number compared to the number of all possible Left Turns (with or without transit information!) is:
    - equal to or greater than: connect those lanes of the Entering Way, which use the leftmost variation, to the Exit Way of the leftmost Left Turn, the lanes with the next variation to the Exit Way of the next Left Turn, and so on, until the last Left Turn. Ignore lanes with surplus variations.
      - If the lanes of the Connection from the current Entering Way to the current Exit Way have already been determined in a previous step, skip the current variation and Left Turn!
      - If the number of lanes of the current turn variation compared to the number of lanes in the Exit Way is:
        equal to or less than: connect the lanes in right-to-left (left-hand traffic: left-to-right) order.
        
        greater than (right-hand traffic): connect the lanes in left-to-right order and connect all surplus lanes of the Entering Way to the rightmost lane. Treat this as data error.
        
        greater than (left-hand traffic): connect the lanes in right-to-left order and connect all surplus lanes of the Entering Way to the leftmost lane. Treat this as data error.
    - less than: Identical to the case "equal to or greater than", but connect the lanes of the last variation to the lanes of all remaining Left Turns.
- If for the leftmost lane of the Entering Way a turning indication with *left is not specified, connect only the leftmost lane of the Entering Way to the rightmost (left-hand traffic: leftmost) lane of the Exit Way of all Left Turns.
- If for the rightmost lane of the Entering Way a turning indication with *right is specified (note: some turning indications may have been removed while processing Straight On connections):
  - Determine the number of variations of *right in the turning indications of all lanes, e.g. two, if "sharp_right" and "right" is present, or one if only "slight_right" is present. If this number compared to the number of all possible Right Turns (with or without transit information!) is:
    - equal to or greater than: connect those lanes of the Entering Way, which use the rightmost variation, to the Exit Way of the rightmost Right Turn, the lanes with the next variation to the Exit Way of the next Right Turn, and so on, until the last Right Turn. Ignore lanes with surplus variations.
      - If the lanes of the Connection from the current Entering Way to the current Exit Way have already been determined in a previous step, skip the current variation and Right Turn!
      - If the number of lanes of the current turn variation compared to the number of lanes in the Exit Way is:
        equal to or less than: connect the lanes in right-to-left (left-hand traffic: left-to-right) order.
        
        greater than (right-hand traffic): connect the lanes in right-to-left order and connect all surplus lanes of the Entering Way to the leftmost lane. Treat this as data error.
        
        greater than (left-hand traffic): connect the lanes in left-to-right order and connect all surplus lanes of the Entering Way to the rightmost lane. Treat this as data error.
    - less than: Identical to the case "equal to or greater than", but connect the lanes of the last variation to the lanes of all remaining Right Turns.
- If for the rightmost lane of the Entering Way a turning indication with *right is not specified, connect only the rightmost lane of the Entering Way to the rightmost (left-hand traffic: leftmost) lane of the Exit Way of all Right Turns.

Note regarding new_on_left and new_on_right: in such case, the "new" lane is not directly connected to the from-way, but it can be reached by changing the lane (if allowed). Pay attention to this when building a routing graph. For routing (but not for rendering) it may be possible to treat those values identical to fork.

Road classes and assumed number of lanes

The following table lists relevant road classes ordered by priority and the assumed number of lanes, if not specified explicitly.

Road class (ordered)	Assumed # lanes two way	Assumed # lanes one way
`highway=motorway` `highway=trunk`	4	2
`highway=primary` `highway=secondary` `highway=tertiary` `highway=unclassified` `highway=residential` `highway=motorway_link` `highway=primary_link` `highway=secondary_link` `highway=tertiary_link`	2	1
`highway=service` `highway=track` `highway=path` `highway=living_street` `highway=road` `highway=cycleway`	1	1

Determining adjacent lanes based on the placement key

Variable	Meaning
f	The number of forward lanes.
b	The number of backward lanes.
c	The number of centre lanes, i.e. lanes between forward and backward lanes, which are specified using the suffix :both_ways.

Tag¹	Right-hand traffic	Left-hand traffic
`placement=left_of:x` `placement:forward=left_of:x`	x	x - f - 1
`placement=right_of:x` `placement:forward=right_of:x`	x + 1	x - f
`placement=middle_of:x` `placement:forward=middle_of:x`	x + 0.5	x - f - 0.5
`placement:backward=left_of:x`	2 - x - c	b + c - x + 1
`placement:backward=right_of:x`	1 - x - c	b + c - x
`placement:backward=middle_of:x`	1.5 - x - c	b + c - x + 0.5
`placement:both_ways=left_of:x`	x - c	x - 1
`placement:both_ways=right_of:x`	x - c - 1	x
`placement:both_ways=middle_of:x`	x - c - 0.5	x - 0.5

¹ The mentioned tags may carry an additional :start or :end suffix. Make sure to use the correct tag, i.e. the one relating to the connecting node of both OSM ways.

Rules:

Determine for both OSM ways an offset as described in the table above. Following o1 means the offset of the From Way and o2 means the offset of the To Way.
In case the direction of both OSM ways is not identical, treat one OSM way as if it would be reversed and adjust its offset as follows: oX = c - oX. Note: the following rules assume that one OSM way ends ad the connecting node and the other one starts there.
From Way means the OSM way ending in the connecting node and To Way the one starting in the connecting node.
Determine the index i as: i = 1 + max( o1 - o2 , 0 ). If necessary, round down to the nearest integer and treat this as data error. (TODO: better strategy?)
The i-th forward lane of the From Way (viewed from left to right, starting with 1) now connects to the leftmost forward lane of the To Way; continue to the right until you reach the rightmost forward lane of either the From Way or To Way. Note: if i is greater than the number of forward lanes in the From Way, no forward lanes are connected between the From Way and To Way. This is usually a data error. In such a situation routing applications might connect the rightmost forward lane of the From Way to the leftmost forward lane of the To Way.
The i-th backward lane of the To Way (viewed from left to right, starting with 1) now connects to the leftmost backward lane of the From Way; continue to the right until you reach the rightmost backward lane of either the From Way or To Way. Note: if i is greater than the number of backward lanes in the To Way, no backward lanes are connected between the From Way and To Way. This is usually a data error. In such a situation routing applications might connect the rightmost backward lane of the To Way to the leftmost backward lane of the From Way.
The i-th centre lane of the From Way (viewed from left to right, starting with 1) now connects to the leftmost centre lane of the To Way; continue to the right until you reach the rightmost centre lane of either the From Way or To Way. Note: if i is greater than the number of centre lanes in the From Way, no centre lanes are connected between the From Way and To Way. This is usually a data error. In such a situation routing applications might connect the rightmost centre lane of the From Way to the leftmost forward lane of the To Way.

TODO: left-hand traffic

Examples

Only number of lanes available

Number of lanes and placement of OSM way available

Number of lanes and turn indications available

Transit key or relation

TODO: mixed example with tag, relation and no transit

Rendering lanes

...

Proposal:Transit

Contents

Short overview - TL;DR

Rationale