Proposal:Lane group

From OpenStreetMap Wiki
Jump to navigation Jump to search
Lane group
Proposal status: Abandoned (inactive)
Proposed by: polderrunner
Tagging: lane_group=(list of comma separated lane values)
Applies to: way
Definition: Define properties of individual lanes
Statistics:

Rendered as: none on standard map, navigation devices etc may display detailed lane information
Draft started: 2012-01-18
RFC start: 2012-02-03


Modern gps navigation devices are able to guide the driver to select the appropriate lane to follow. In more advanced devices a detailed '3D' street layout with individual lanes can be displayed. In order to implement such functions the necessary data must be available. The present tagging scheme allows for an easy way of mapping such data.

Rationale

Despite various attempts to create a lane tagging scheme none have so far succeeded in gaining any support.

This proposal addresses a number of problems of those previous attempts.

  • Backward compatible with existing tagging, e.g. 'lanes' tag. Lane tagging is primary for one specific purpose, namely to enable detailed lane guidance and should therefore not interfere with existing applications such as renders and route planners that don't need such information.
  • Simple editing: Mostly one single tag per highway section allows for efficient editing. Does not need special editor plugins to make editing practical.
  • Clear overview: The lane pattern and usage are directly evident from the single tag.
  • No relations: Relations are in general difficult to edit, error prone and should be avoided if possible.
  • No need to map lanes as separate ways.
  • Accommodate special lane types, e.g. cycle lanes, bus lanes, center turn lanes, hard shoulder running
  • Accommodate (almost) all situations possible, including strange ordering of lanes
  • Provide for lane crossing restrictions.
  • Specify lane specific properties using additional tags.
  • No a priori knowledge about left-hand/right-hand driving required.
  • Easy to parse by applications, just a straight list of values to be evaluated
  • Unambiguous, no implicit rules: The tag comprises an ordered list of all lanes present.

Tagging

lane_group=lane_value,lane_value,...

Example showing the use before discussing the dry stuff: 

lane_group=l,s,s,r

This describes a 4 lane highway having a left-turn lane, two straight-through lanes and a right-turn lane.

lane_value

The tag value is an ordered list of comma separated lane values starting with the left-most lane and ending with the right-most lane. Each lane must be listed exactly once even if there are multiple lanes of the same type.

The lane value has the general format: (flow-dir)(type:)dir. Fields in brackets are optional.

flow-dir: Flow-direction prefix, used for lanes where the traffic flow is not in the forward direction. Possible values for flow direction are:

  • -: backward, for lanes having a traffic flow opposite the direction of the way.
  • +-: two-way driving, usable in both directions, e.g. for a center turn lane
  • +/-: reversible direction, used for lanes that may alternate driving direction, e.g. between morning and evening rush hours.

type: Usage field describing who may use the lane. This field is optional. Possible values for 'type' are:

  • bus: bus lane, general traffic not allowed
  • psv: bus and taxi lane, general traffic not allowed
  • hgv: truck-only lane, lane reserved for heavy goods vehicles (such lanes are e.g. found in Rotterdam)
  • tram: lane with embedded tram rails (not for rails that are not part of a driving lane).
  • hov: high-occupancy-vehicle lane, 'car pool' lane
  • emergency: Emergency vehicles only (eg from a fire station)
  • cycle_lane: bicycle lane.
  • cycle_track: bicycle track (when not mapped as a separate way).
  • sidewalk: sidewalk

The use of cycle_lane, cycle_track and sidewalk values is optional if the highway is already tagged with corresponding cycleway:* or sidewalk:* tags. But the cycle_lane value should be used when cycle lanes are located between other lanes.

dir: Connection field describing where the lane leads to. This field is mandatory. Possible values for 'dir' are:

  • n: normal lane
  • l: left-turn lane, typically indicated by a left-arrow
  • s: straight-through lane, typically indicated by a forward arrow
  • r: right-turn lane, typically indicated by a right-arrow
  • zl: 'soft' left-turn lane, used for the 'lesser' turn when necessary to distinguish between two different left turns.
  • zr: 'soft' right-turn lane, used for the 'lesser' turn when necessary to distinguish between two different right turns.
  • ll: double left-turn lane, two different left turns possible from this lane (typically indicated by a double left arrow symbol)
  • rr: double right-turn lane, two different right turns possible from this lane (typically indicated by a double right arrow symbol)
  • ul: u-turn-left lane
  • ur: u-turn-right lane
  • ml: merge lane, merging with adjacent lane left
  • mr: merge lane, merging with adjacent lane right
  • w: weave lane, e.g. between on-ramp and next exit ramp.
  • hsr: hard-shoulder-running, hard shoulder used as drive lane during rush hour. Could also be used on similar intermittant lanes not actually serving as a hard shoulder, such as "plusstroken" found on Dutch motorways.
  • parking: parking lane
  • hatched: hatched or chevron-marked area, driving on this area normally not allowed.

The turn directions may be combined with the plus ('+') character, e.g. a lane for straight-through and right-turn traffic may be coded as 's+r'. Multiple directions should be ordered from the left-most direction to the right-most direction.

Please note that 'left' and 'right' are relative to the traffic flow direction, not to the direction in which the way has been drawn.

Lane Crossing Restrictions

Overtaking and lane crossing restrictions can easily be added to the present scheme. The commas corresponds to the lane separators (e.g. broken or solid lines). A '#' character at either side of the comma marks that the lane separation may not be crossed from this side. Example: lane_group=l#,#s where crossing the lane separator is not allowed from either side.

Lane Specific Properties

Further properties such as lane specific maxspeed or maxwidth restrictions can be accomodated by additional tags like this: 

lane_group:maxspeed=*,*,70,70

This defines that the two right-most lanes have a 70 km/h speed limit while a default speed limit if any applies to the two left-most lanes (indicated by the "*" character). The number of lane values including the empty ones must match that of the lane_group tag.

Most established tags usable together with highway=* can be applied to individual lanes in a similar fashion. 

lane_group:(osm-key)=(osm-value),(osm-value),..   (undefined values should be indicated by "*")

Examples are restrictions, surface, name (?) and ref tags. Notable exceptions are lanes and oneway tags as they would conflict with the lane_group tagging.

In rare cases the comma character is used within tag values, e.g. in opening_hours=*. To prevent conflicts with the separator comma such values should be put within round brackets "(" and ")" if they comprise commas.

Connectivity and Lane Matching

The navigation software must solve two sub-problems when using lane information.

Lane Guidance

Software must determine which lane(s) a driver should select in order to follow the planned route ("lane assist" function). It must detect all ways forming legal turn opportunities departing from the joining node (but ignoring any oneway ways leading to this node). When there are any straight-through lanes there must be exactly one corresponding way for the through direction when all turns have been accounted for.

  1. If the ways leading away at 'reasonable' angles correspond exactly to the left_turn, through and right-turn lanes the problem is easily solved. For motorways and other ways having exit ramps the presence of highway=*_link on the departing way can be used to distinguish the through way from the exit ramp even if the ways separate at a shallow angle.
  2. If no legal turn is possible corresponding to a turn-lane then look for a continuation of that turn lane (e.g. in an intersection of two dual-carriage highways only the second way left is a legal turn). If found the problem is solved. Otherwise do some graceful recovery (this is probably a mapping error)
  3. If soft-turn lanes have been tagged together with hard turn lanes two situations may apply. 1) Two ways departs at the joining node to the same side at different angles. The lesser turn then corresponds to the soft-turn lane. 2) Otherwise there may be another turn shortly after. This should be evident from detecting the soft-turn lane turning into a normal turn lane in the following through way segment. The soft-turn variants should be used when there is a possibility of confusion with a hard turn, not just because there is a turn at a shallow angle.

'3D' View

For advanced "3D" display ("junction view" in Garmin terminology) the lanes of successive highway segments must "line up" correctly to render a seemless layout of the lanes. The following assumptions can be made for the continuing 'through' way.

  1. If the number of straight-through or normal lanes is the same for the two way segments these lanes form the reference for alignment. Any new lanes are created left or right according to their turn values.
  2. If straight-through or normal lanes disappear but a corresponding number of turn-lanes is created then it should also be clear how the lanes are matching. In other words the total number of lanes doesn't change.
  3. Otherwise it may be necessary to use a "lane matching" tag to assist in the lane-to-lane mapping.

Lane Matching Tag

This tag describes what happens to a lane ahead at the end node, i.e. how it connects to lanes in the straight-through highway ahead (if any). 

lane_group:match=<match_value>,<match_value>,... 
lane_group:match:backward=<match_value>,<match_value>,...

The number of values must correspond to the number of values in the lane_group tag. For two-flow ways it may be necessary to define the matching in the backward direction as well using the backward variant (the match values for lanes in the forward direction should be left undefined using the "*" character). Possible values for match_value are:

  • +: This lane splits symmetrically into two lanes that continues in the through highway.
  • +l or +r: A new lane is created to the left or right of this lane (it may be lanes originating from a side street or from an on-ramp).
  • -: This lane disappears without connecting or merging with something else (should only be used in exceptional cases).
  • -l or -r: This lane disappears and merges with the lane to the left or to the right.
  • L: This lane connects to another highway to the left (it does not connect to the through highway).
  • R: This lane connects to another highway to the right (it does not connect to the through highway).
  • *: This lane continues as a single lane (it may change to something different, however) or this lane leads away from the joining node (for a highway not being oneway).

Match values may be combined, e.g. if two right-turn lanes are created this may be indicated as +r+r.

Examples

Example 1 (motorway and ramp with special lanes)

Lanes-rdam-A16-1a.jpg

Highway 1: Motorway with dedicated truck lane 

lane_group=n,n,hgv:n

Highway 2: Motorway ramp with bus lane. Drivers are not allowed to cross over bus lane (using xl, xr restrictions). 

lane_group=l,l#,bus:s,#s,r,r


Example 2 (cycle lane between other lanes)

Lanes-rdam-zuid-1.jpg

Interesting case with a left-turn cycle lane. 

lane_group=l,l,cycle_lane:l,s


Example 3 (two direction way with tram rails and double right turn lane)

Lanes-rdam-euromast.jpg

Case with two directions, tram rails (not easy to see) and cycle lane. The rigth turn lane leads to two different right-turns (double right arrow). The way is assumed drawn from left to right. The cycle track below the right-turn lane is assumed mapped as a separate way. 

lane_group=-cycle_lane:n,-tram:n#,#tram:s,rr


Example 4 (lane matching)

Lanes-harnasch1.jpg

Two through lanes (way segment 1) continues as right turn lanes in way segment 2. A new through lane is created left (because it leads to a minor road ahead).

  • segment 1: lane_group=n,n; lane_group:match=+l,*
  • segment 2: lane_group=s,r,r


Example 5 (ref and destination tags)

example image

Example showing the use of ref=* and destination=* on lanes (image from this proposal). 

lane_group=s,s,r
lane_group:ref=A43,A43,A43
lane_group:int_ref=E 712,E 712,E 70
lane_group:destination=Genève;Annecy;Chambéry,Genève;Annecy;Chambéry,Turin;Milan;Albertville

Existing Tags and Applications

This proposal does not deprecate any existing tags. In case of conflicting tags the lane_group tag should take precedence. In particular, the existing lanes=* tag may be used when there are only normal through lanes, e.g. lanes=2 corresponds to lane_group=n,n (which may then be omitted).

The lane_group tag is not intented to be used for route planning, only for "micro-routing" when guiding a driver. In particular, this proposal is not a replacement for turn restriction relations and the presence or absence of particular turn lanes should not be interpreted as a turn restriction. On the other hand this tagging scheme does not rely on the presence of turn restriction relations to solve ambiguities etc.

Editors like JOSM should be aware of this tag in order to warn users if they try to reverse the direction of a highway.

Change Log

  • 22-02-2012: Added 'L' and 'R' values to match tag
  • 16-02-2012: Added example 5
  • 15-02-2012: Replaced empty values by "*"
  • 09-02-2012: Added 'n' and 'hatched' lane values
  • 08-02-2012: Generalised the lane property tagging (not just for restrictions)
  • 02-02-2012: Changed layout, various linguistic improvements
  • 29-01-2012: Further refinements to Connectivity section. Introduced lane_group:match tag.
  • 24-01-2012: Implemented previously suggested changes: sign notation for flow direction, special lanes using colon ':' notation, lane crossing restrictions using '#'.
  • 24-01-2012: Added connectivity section (unfinished). Changed values for cycle lanes/tracks
  • 22-01-2012: Restrictions other than lane crossing restriction now using a separate tag, e.g. lane_group:maxspeed=,,70,70
  • 22-01-2012: Multiple turn directions for a lane are now tagged using the plus character, e.g. 'l+r' for a left-turn and through lane.
  • 22-01-2012: Added further turn directions: 'soft' turns 'zl', 'zr' to be used in complex situations with two turns at different angles to the same side; double turn lanes coded as 'll' and 'rr' when there are two turns shortly after each other (typically indicated by a double arrow symbol on the road surface).

Voting

Voting has been cancelled, the proposal has been returned to RFC status for possible amendment. The votes already cast have been moved to archive.

See Also

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Lane_group&oldid=2515232"