Proposal:Advanced navigation

Page in work. Please collect here your ideas and/or wait for advanced navigation meeting results.

In German OSM-Forum several discussion started about the kind of mapping lanes to make OSM-based advanced navigation possible. [1] [2] [3] At the moment there is more or less an agreement, that sheme [4] in combination with [5] should be used and modified.--Hurdygurdyman 13:16, 31 October 2012 (UTC)

---

In Germany commonly a double solid line on highways is interpretated as divided highways [6] and such highways should be mapped as two separated oneways. There's a discussion, wether single solid lines should be interpretated the same way, because in german rules they both may not be exceeded. The only difference is, that double solid lines should be used, if each carriageway has two or more lanes. --Hurdygurdyman 13:39, 31 October 2012 (UTC)

There is also the position that neither single nor double white lines should be a reason for splitting a highway into two separate oneways, and that mapping style should be reserved for actual "physical separation" (with a barrier, e.g. guardrail, grass strip, wall). From this point of view, representing a highway painted with certain road markings as two separate oneways will become obsolete if we agree on a road marking tagging scheme (such as the previously proposed divider=solid_line/solid_area/dashed_line/... scheme).--Tordanik 16:27, 31 October 2012 (UTC)

---

"Advanced navigation" means: I still know possible connections to the next lanes, especially for big, complicated crossings.

Example crossing 1

(without "right" OSM syntax):

Numbering of lanes counterclockwise around point M.

--Marek Kleciak 08:05, 5 November 2012 (UTC)

Issues

Connectivity

End Node Connectivity Lane to Way

Which OSM way does a lane of an OSM way connect to at the end node in view of traffic flow? In case of backward direction the end node has to be replaced by the start node of the OSM way.

Partial solutions

1. Using information from Key:turn:lanes only

Full solutions

1. Key:turn:physical:lanes
2. Lane Labeling

Lane naming

Please describe here your ideas

End Node Connectivity Lane to Lane

Which lane of a given OSM way does a lane of an OSM way connect to at the end node of the OSM way in view of traffic flow? In case of backward direction the end node has to be replaced by the start node of the OSM way.

Partial solutions

1. Key:turn:into

Full solutions

1. Lane Labeling

Tagging examples including lane to way connectivity

1. Crossing 1 with Lane labeling

   In this specific example lane to way connectivity can be fully based on turn values of key:turn.

   Lane to Lane connectivity can be based on lane quantity evaluation being supported by key:turn:into.

   Way A

   turn:into:lanes:backward=through|through|right

   turn:lanes:forward=left;through|through;right|right

   Way B

   turn:into:lanes:backward=all|left;right

   turn:lanes:forward=through|right

   Way C

   turn:into:lanes:backward=left;through|left;through|left;right

   turn:lanes:forward=left;through|through;right|right

   Way D

   turn:into:lanes:backward=all|left;right

   turn:lanes:forward=all|right

2. Crossing 1 with Lane labeling

   In this specific example lane to way connectivity can be fully based on turn values of key:turn.

   Lane to Lane connectivity can be based on lane quantity evaluation being supported by lane labeling.

   Way A

   lanelabel:lanes:backward=A3|A2|A1

   turn:lanes:forward=left;through:C3|through:C2;right|right

   Way B

   lanelabel:lanes:backward=B2|

   turn:lanes:forward=through:D2|right:C1

   Way C

   lanelabel:lanes:backward=C3|C2|C1

   turn:lanes:forward=left:D2;through:A3|through:A2;right|right

   Way D

   lanelabel:lanes:backward=D2|

   turn:lanes:forward=left;through:B2|right:A1

3. Crossing 1 with Connectivity purely based on Lane Labeling

   Way A

   lanelabel:lanes:backward=A3|A2|A1

   turn:lanes:forward=left:D2:D1;through:C3|through:C2;right:B2|right:B1

   Way B

   lanelabel:lanes:backward=B2|B1

   turn:lanes:forward=through:D2|right:C1

   Way C

   lanelabel:lanes:backward=C3|C2|C1

   turn:lanes:forward=left:D2;through:A3|through:A2;right:D2|right:D1

   Way D

   lanelabel:lanes:backward=D2|D1

   turn:lanes:forward=left:C1:C2:C3;through:B2|right:A1

End Node Connectivity Lane to Lane between adjacent Sections of a Highway

This is a special case of the previous issue. At the interconnection lanes could end or be added. The router needs to know how this is done.

Example

1. An OSM way with 3 lanes is connected to an subsequent OSM way with 4 lanes. Some examples:
   1. The right lane is split into two lanes
   2. An additional lane is added on the right side
   3. The middle lane is split into two lanes
   4. The left lane is ending, the middle and right lane are each split into two lanes.
   5. The left lane is ending, but two new lanes are added on the left side.

Full solutions

1. Key:turn:input combined with Key:turn:physical

Key:turn:input can be used to specify splitting or adding lanes Key:turn:physical can be used to specify merging or ending lanes

1. Lane Labeling combined with Key:change:lanes

Lane change

Lane Change within an OSM Way

Partial solutions

1. Key:change:lanes (negative variant)

This variant is limited to changes to the next lane

Full solutions

1. Key:change:lanes (positive variant)

This variant can also cover lane changes to the next but one lane using special values. This might be required in case a bicycle turn lane is between the lanes.

1. Key:change:lanes (negative variant) mixed with positive special values

Lane Change between adjacent parallel OSM Ways

How to specify the ability to change to a lane of an adjacent OSM way. This is required in case of some lane mapping with different OSM ways.

Driving instructions

The navigation system needs to generate reasonable instructions for the driver.

Turn instructions

The angle between OSM ways at the interconnection point is not a good indicator of the type of turn manoeuvre.

In case there are road markings the turn instruction needs to sufficiently match with the road markings.

Partial solutions

1. Special values of the turn key could denote that it is not a rood marking, but only intended for driving instuctions. For example "(right)" can be used instead of "right"
2. Extending the turn:lanes key to include routing connectivity enables transformation of the found route back to turn key values.

Destination instructions

In view of the destination driving instructions needs to match the signage on the road. Unfortunately destination signage might be different for different roads towards the interconnection. Therefore purely using the destination of the road leaving the crossing is not sufficient.

Angular distortion due to the lateral offset

Partial solutions

1. Virtual segment of an OSM way
2. OSM way highway=lateral_connection

Splitting of OSM Ways due to Lane Tagging

Partial solutions

1. Key:start:lanes
2. Key:ends:lanes
3. Key:start:turn:lanes

Partial solutions

1. Virtual segment of an OSM way
2. OSM way highway=lateral_connection

Compatibility with Micromapping

The structures which are used for advanced navigation need to be compatible with macromapping. Otherwise the navigation structure will likely be destroyed in future due to micromapping. The best way to achieve the compatibility is exactly drawing of street area as a pysical limitation for rendering of lanes.

This means the schema must work with areas and lines or it will not work in long term. It should be an area schema which can be reduced to a line variant, such as .

Partial solutions

1. Key:position:lanes
2. OSM way highway=lane_position

Means for solutions

Key:turn:physical:lanes

This tag could be used to specify how a vehicle can turn at the end of the OSM way or the lane in view of the physical angle between osm ways. The values of a turn:lanes tag can be used as a default for turn:physical:lanes, but "none" has to be translated to "all" because no turn marking means the vehicle can turn in all directions.

Key:turn:into:lanes

This tag could be used to specify how a vehicle can turn into the lane at the beginning of the OSM way or the lane.

Lane Labeling

Lanes could be labeled with a name using a key like

label:lanes=<lanename1>|<lanename2>|<lanename3>

lanename:lanes=<lanename1>|<lanename2>|<lanename3>

lanelabel:lanes=<lanename1>|<lanename2>|<lanename3>

This name could be used in an extended variant of key:turn or key:turn:lanes to specify the connected lane of the subsequent OSM way:

turn:lanes=left:<lanename1>|through|right:<lanename3>

The lanename needs to be unique within all OSM ways connecting to the end node of the OSM way which is using the lanename in its turn tag.

Naming convention

In principle label names can be freely chosen, but a naming conventions seems to be useful. The label name should consist of:

1. Abbrevation or acronym of the street name
2. Indication of direction of the lane (preferably one or two letters indicating rough geographic direction)
3. Indication of the lane within the all lanes of same direction of the steet.

Automatic Numbering

Instead of defining lane labels explicitly they can be generated by numbering the the OSM way and their lanes automatically.

Automatic Numbering of connecting ways at the interconnection

Beginning at an starting angle the Osm ways at the interconnection can be counted (for example using letters) in counterclockwise angular direction. Unfortunately the starting angle needs to be adjustable by tagging because ther must not be any OSM way at the interconnection with a similar angle. Otherwise minimal geometric changes could change numbering, and disturb the routing information accordingly.

Adding or removing an OSM way at the interconnection is also disturbing the method. Especially this can occur due to splitting an OSM way into two antiparallel oneways.

Automatic Numbering of lanes within an osm way

Within an OSM way lanes can be numbered automatically, but there are also some disadvantages: Special purpose lanes like bus or cycling lanes can not be easyly identified by the labelling. Along consecutive sections of a highway the lane numbers of the straight lines are often changing because sometimes turn lanes are added on the left or right side.

Key:change

A key change=* with values right, both, left could be used in order to specify the ability to change to the next lane on an adjacent OSM way.

Values denoting a position within an OSM way

With <count> and <offset> being numbers the following values could denote a position within an OSM way:

1. +<count>

<count> nodes behind the first node of the OSM way

1. -<count>

<count> nodes before the last node of the OSM way

1. +<offset> m

<offset> meters behind the first node of the OSM way

1. -<offset> m

<offset> meters before the last node of the OSM way

1. -<offset> m +<count>

<offset> meters before the node, which is <count> nodes behind the first node of the OSM way

Node labling

The values +<count> and -<count> are difficult to handle in case of large <count>. Therefore thess can be replaced by a freely chosen string <nodename>, which needs to be locally unique within all node of the OSM way. The denoted node of the OSM way needs to be tagged with something like:

1. nodelabel=<nodelabel>
2. node=<nodelabel>

Key:start:lanes

A key start:lanes=*|*|* with values denoting the position within the OSM way could be used in order to specify that a lane doesn't start at the first node of an OSM way (in driving direction), but to start at a specified position within the OSM way.

Key:end:lanes

A key end:lanes=*|*|* with values denoting the position within the OSM way could be used in order to specify that a lane doesn't end at the last node of an OSM way (in driving direction), but ends at a specified position within the OSM way.

Key:end:turn:lanes

A key end:turn:lanes=*|*|* with values denoting the position within the OSM way could be used in order to specify that the turn makings of a lane don't cover the full length of the OSM way, but start at a specified position within the OSM way. This information is intended for advanced rendering, but the reason for this tag is to avoid splitting of the OSM way.

Virtual segment of OSM way

In order to compensate lateral offset at the connection of two consecutive OSM ways due to ending or starting lanes both OSM ways could be mapped at the correct position, but a lateral segment has to be added to one of the ways for logical connection. This segment does not exist in reality. Therefore Key:virtual with values first, last, or both can be used in order to mark the first or last segment of an OSM way to be nonexistant in reality. Calculations of the interconnection angle must ignore such virtual segments.

highway=lateral_connection

In order to compensate lateral offset at the connection of two consecutive OSM ways due to ending or starting lanes both OSM ways could be mapped at the correct position. The logical connection can be realised using an additional OSM way in lateral direction, which is tagged with highway=lateral_connection.

OSM way highway=lane_position

A separate OSM way with highway=lane_position could be used to override the position of a lane of an adjacent highway. A tag lane=<lanelabel> could denote the specific lane (using Lane Labeling). A tag lane=<lanelabel>:right means that the lane_position OSM way is defining the position of the right side of the lane.

The lane_position OSM way needs to be connected to the main OSM way of the highway. A virtual segment could be used if required. An indirect connection using an OSM way with highway=lateral_connection is also possible.

Key:lane_snap

This key can only be used in combination with Lane Labeling. It is intended to override the rendering position of a lane of an highway. Being used on the highway itself this key specifies a specific lane to be aligned to the position of the OSM way instead of the center of the road. The tag can also be applied to any OSM way alongside the highway (within a limited distance). In this case the specified lane of the highway is aligned to the other OSM way.

The value of Key:lane_snap can compise

1. "<lanelabel>" indentifing the lane, which has to snap to the OSM way,
2. ":left", ":right", or ":center" specifying which part of the lane has to snap,
3. an optional ":+<offset>" of ":-offset" value with positive values shifting the lane to the right in view of lane direction.

Multiple values, even for different highways, can be combined within one tagbeing separated by a semicolon.

Using a relation combining the highway with other OSM ways to which lanes can snap for rendering is likely beneficial, but not essential due to limited distance. A single relation can contain multiple segments of an highway.