A logical lane in the road network. More...

Collaboration diagram for osi3::LogicalLane:

[legend]

Classes
struct	LaneConnection
	Connection to another lane (predecessor or successor) More...

struct	LaneRelation
	Relation of this lane to another logical lane. More...

struct	PhysicalLaneReference
	Reference to a physical lane. More...

struct	TrafficRule
	Describes traffic rules on a lane. More...

Public Types
enum	Type { TYPE_UNKNOWN = 0 , TYPE_OTHER = 1 , TYPE_NORMAL = 2 , TYPE_BIKING = 3 , TYPE_SIDEWALK = 4 , TYPE_PARKING = 5 , TYPE_STOP = 6 , TYPE_RESTRICTED = 7 , TYPE_BORDER = 8 , TYPE_SHOULDER = 9 , TYPE_EXIT = 10 , TYPE_ENTRY = 11 , TYPE_ONRAMP = 12 , TYPE_OFFRAMP = 13 , TYPE_CONNECTINGRAMP = 14 , TYPE_MEDIAN = 15 , TYPE_CURB = 16 , TYPE_RAIL = 17 , TYPE_TRAM = 18 }
	Definition of available lane types. More...

enum	MoveDirection { MOVE_DIRECTION_UNKNOWN = 0 , MOVE_DIRECTION_OTHER = 1 , MOVE_DIRECTION_INCREASING_S = 2 , MOVE_DIRECTION_DECREASING_S = 3 , MOVE_DIRECTION_BOTH_ALLOWED = 4 }
	Describes in which direction moving objects may typically move along a lane. More...

Public Attributes
optional Identifier	id = 1
	The ID of the logical lane. More...

optional Type	type = 2
	The type of the logical lane. More...

repeated ExternalReference	source_reference = 3
	Optional external reference to the lane source. More...

repeated PhysicalLaneReference	physical_lane_reference = 4
	Reference to the physical lanes this logical lane belongs to. More...

optional Identifier	reference_line_id = 5
	The reference line for this logical lane. More...

optional double	start_s = 6
	Start S position of the lane. More...

optional double	end_s = 7
	End S position of the lane. More...

optional MoveDirection	move_direction = 8
	Definition of the intended driving direction. More...

repeated LaneRelation	right_adjacent_lane = 9
	Lanes that are directly right of this lane, without gap or overlap. More...

repeated LaneRelation	left_adjacent_lane = 10
	Lanes that are directly left of this lane, without gap or overlap. More...

repeated LaneRelation	overlapping_lane = 11
	Lanes that partially or completely overlap this lane. More...

repeated Identifier	right_boundary_id = 12
	Right boundary of this lane. More...

repeated Identifier	left_boundary_id = 13
	Left boundary of this lane. More...

repeated LaneConnection	predecessor_lane = 14
	Lanes that directly are connected to this lane at the beginning. More...

repeated LaneConnection	successor_lane = 15
	Lanes that directly are connected to this lane at the end. More...

optional string	street_name = 16
	Name of the street this lane belongs to. More...

repeated TrafficRule	traffic_rule = 17
	A list of traffic rules on the lane. More...

Detailed Description

A logical lane in the road network.

A logical lane is part of a road. Compared to a physical lane (OSI type Lane), its existence doesn't hinge on the existence of road markings. So e.g. a road with two driving directions but no road markings in-between would be presented as two LogicalLanes, but only one Lane. So one Lane can consist of multiple LogicalLanes. E.g. on intersections, each driving path is one LogicalLane, but the whole area is one Lane of type TYPE_INTERSECTION .

Outside of intersections, logical lanes are constructed such that each point on the road belongs to at least one (typically: exactly one) logical lane. So there are no gaps between logical lanes, and no areas that don't belong to a logical lane.

If OSI is generated from OpenDRIVE, then LogicalLanes map directly to OpenDRIVE lanes. However, it is allowed to merge multiple consecutive (in S direction) OpenDRIVE lanes with the same type into one OSI LogicalLane: if an OpenDRIVE lane has a single successor, which has the same lane type, and this successor has only one predecessor (so no lane merging or splitting) then the two lanes may be presented as one continuous LogicalLane. This may be done recursively.

The reference line pointed to by reference_line_id defines an ST coordinate system for the lane. This ST coordinate system is used to describe positions on the lane.

Example

The example below shows two logical lanes on an intersection, with a focus on the left-turn lane (l1):

Two logical lanes on an intersection

Assumptions not shown in the image:

This is right-hand traffic (and thus vehicles on l1 drive from the bottom to the left, vehicles on l2 drive from right to left).
The yellow line is a ReferenceLine, defined starting at the bottom, and going to the left.

Some features shown in the image relative to l1:

The yellow line is the ReferenceLine of l1 . The ReferenceLine can be shared with other lanes. Because the ReferenceLine has the same direction as the driving direction of l1 in this example, move_direction == MOVE_DIRECTION_INCREASING_S.
The red line marks the area where l2 is left of l1 - this info is recorded in left_adjacent_lane of l1.
The red area is the area where l2 overlaps l1. This is recorded in overlapping_lane of l1.

The image below shows the same two lanes, but from the perspective of l2:

Two logical lanes on an intersection

Assumptions not shown in the image:

The yellow line is a ReferenceLine, defined starting at the right, going to the left.

Some features shown in the image relative to l2:

The yellow line is the ReferenceLine of l2 . The ReferenceLine can be shared with other lanes. Because the ReferenceLine has the same direction as the driving direction of l2 in this example, move_direction == MOVE_DIRECTION_INCREASING_S.
The green line marks the area where l1 is right of l2 - this info is recorded in right_adjacent_lane of l2.
The red area is the area where l1 overlaps l2. This is recorded in overlapping_lane of l1.

As can be seen in the images, the two highlighted lanes are neighbors for part of their length, but it makes no sense for them to have the same reference line, since they diverge significantly.

Note: all the relations shown above are also defined outside of intersections.

Member Enumeration Documentation

◆ Type

enum osi3::LogicalLane::Type

Definition of available lane types.

This is mostly aligned with OpenDRIVE, except that lane types modeling access restrictions (e.g. "taxi") are not made available here. These are already deprecated in OpenDRIVE. To support this, access restrictions should be added later, in alignment with OpenDRIVE.

Enumerator
TYPE_UNKNOWN	Lane of unknown type. Do not use in ground truth.
TYPE_OTHER	Any other type of lane.
TYPE_NORMAL	A normal driving lane. Example: Lanes with IDs l1, l2, l3 and l4 in image HighwayExit. This matches the OpenDRIVE type "driving". Note: a lane with OpenDRIVE type "bidirectional" will have an OSI type of TYPE_NORMAL, with `move_direction == MOVE_DIRECTION_BOTH_ALLOWED`.
TYPE_BIKING	A lane that is designated for bicycles Note that biking lanes that cross the road (e.g. on an intersection) are also labeled with this type.
TYPE_SIDEWALK	A lane that is designated for pedestrians (sidewalk). Note that pedestrian lanes that cross the road (e.g. on an intersection) are also labeled with this type.
TYPE_PARKING	A lane with parking spaces.
TYPE_STOP	A hard shoulder on motorways for emergency stops. Example: Lane l5 in image HighwayExit.
TYPE_RESTRICTED	A lane on which cars should not drive.
TYPE_BORDER	A hard border on the edge of a road.
TYPE_SHOULDER	A soft border on the edge of a road.
TYPE_EXIT	A deceleration lane in parallel to the main road. Example: Lane l6 in image HighwayExit.
TYPE_ENTRY	An acceleration lane in parallel to the main road.
TYPE_ONRAMP	A ramp from rural or urban roads joining a motorway.
TYPE_OFFRAMP	A ramp leading off a motorway onto rural or urban roads.
TYPE_CONNECTINGRAMP	A ramp that connect two motorways.
TYPE_MEDIAN	A lane that sits between driving lanes that lead in opposite directions. It is typically used to separate traffic in towns on large roads.
TYPE_CURB	Curb stones. Curb stones have a different height than the adjacent drivable lanes.
TYPE_RAIL	A rail lane. This lane covers the area a train needs to drive along its rails. overlapping_lane then describes where a train crosses other lanes.
TYPE_TRAM	A tram lane. This lane covers the area a tram needs to drive along its rails. overlapping_lane then describes where a tram crosses other lanes.

◆ MoveDirection

enum osi3::LogicalLane::MoveDirection

Describes in which direction moving objects may typically move along a lane.

This describes the allowed typical driving direction on a lane, or (in the case of pedestrian) the allowed walking direction.

Note: Allowed overtaking (e.g. on country roads) does not automatically make a lane bidirectional, since vehicles may normally only drive in the other direction during the overtake maneuver, not for longer periods of time.

Enumerator
MOVE_DIRECTION_UNKNOWN	Move direction is unknown. Do not use in ground truth.
MOVE_DIRECTION_OTHER	Move direction fits neither of the other categories. Example: a lane where cars may only drive in one direction, but bikes may drive in both.
MOVE_DIRECTION_INCREASING_S	Objects may move in increasing S direction. This means they move in the same direction as the reference line.
MOVE_DIRECTION_DECREASING_S	Objects may move in decreasing S direction. This means they move in the opposite direction as the reference line.
MOVE_DIRECTION_BOTH_ALLOWED	Objects may move in both directions.

Member Data Documentation

◆ id

optional Identifier osi3::LogicalLane::id = 1

The ID of the logical lane.

Note: Note ID is global unique.

Rules\n\code{.unparsed}: is_globally_unique

◆ type

optional Type osi3::LogicalLane::type = 2

The type of the logical lane.

◆ source_reference

repeated ExternalReference osi3::LogicalLane::source_reference = 3

Optional external reference to the lane source.

The external reference points to the source of the lane, if it is derived from one or more objects or external references.

For example, to reference a lane defined in an OpenDRIVE map the items should be set as follows:

reference = URI to map, can remain empty if identical with definition in GroundTruth::map_reference
type = "net.asam.opendrive"
identifier[0] = id of t_road
identifier[1] = s of t_road_lanes_laneSection
identifier[2] = id of t_road_lanes_laneSection_left_lane, t_road_lanes_laneSection_right_lane

Note: For non-ASAM Standards, it is implementation-specific how source_reference is resolved.; The value has to be repeated, because one lane segment may be derived from more than one origin segment. Multiple sources may be added as reference as well, for example, a map and sensors.

◆ physical_lane_reference

repeated PhysicalLaneReference osi3::LogicalLane::physical_lane_reference = 4

Reference to the physical lanes this logical lane belongs to.

This makes it possible to get detailed information on the physical lane properties, e.g. the visual colors of the boundaries, the road condition, etc..

Note: a logical lane may consist of several physical lanes (in a row). At any one S position, a logical lane should only reference one physical lane. Several logical lanes may reference the same physical lane (see drawing below).

Logical lanes should not extend beyond intersections. All logical lanes on intersections should end at the latest at the border of the intersection.

Example:

---------------------------------
 l1                       l2
----------    l3        ---------
 l4                       l5
---------------------------------

In this case, we have five physical lanes: l1, l2, l4 and l5 where a lane marking is present. And l3 is one lane covering the whole road (because no road marking is present).

This would typically be presented as two logical lanes:

One encompassing l1, part of l3, and l2
The other encompassing l4, part of l3 and l5

In this example, both logical lanes would reference l3. Their shared LogicalLaneBoundary would cut through the middle of l3.

physical_lane_reference does not give any information how much of the area of a physical lane is covered by a logical lane.

For LogicalLanes without a correspondence to a Lane.Classification.Subtype (i.e. TYPE_MEDIAN, TYPE_CURB, TYPE_TRAM, TYPE_RAIL) this field has no value.

Rules\n\code{.unparsed}: refers_to: Lane

◆ reference_line_id

optional Identifier osi3::LogicalLane::reference_line_id = 5

The reference line for this logical lane.

The reference line is used as a coordinate system on this lane.

The reference line should roughly have the same shape as the lane, so that S coordinates continually increase/decrease along the lane. It is not required that the reference line has the same direction as the driving direction of the lane.

Neighboring lanes (i.e. lanes that are neighbors and whose directions do not diverge significantly) are strongly encouraged to reference the same ReferenceLine, so that vehicles that are next to each other on neighboring lanes have comparable S positions.

The S coordinate of the reference line makes it easy to find e.g. which object is next on a lane, using the LogicalLaneAssignment of the objects.

The reference trajectory must be sampled such that there are no two positions on the lane more than 5cm apart with the same ST coordinate.

Rules\n\code{.unparsed}: refers_to: ReferenceLine

◆ start_s

optional double osi3::LogicalLane::start_s = 6

Start S position of the lane.

Must be in range [sStart,sEnd] of the reference line.

◆ end_s

optional double osi3::LogicalLane::end_s = 7

End S position of the lane.

Must be in range [sStart,sEnd] of the reference line.

Requirement: end_s > start_s

◆ move_direction

optional MoveDirection osi3::LogicalLane::move_direction = 8

Definition of the intended driving direction.

◆ right_adjacent_lane

repeated LaneRelation osi3::LogicalLane::right_adjacent_lane = 9

Lanes that are directly right of this lane, without gap or overlap.

"Right" is in definition direction (not driving direction), so right lanes have smaller T coordinates. Entries must be ordered: first by start_s, then by end_s.

The XY positions of the polyline generated by the LogicalLaneBoundaries of adjacent lanes must match up to a small error (5cm). Typically adjacent lanes will share a LogicalLaneBoundary, but this will not always be true. Examples: on intersections, it might be hard to generate data such that lanes that are adjacent for a short length share a LogicalLaneBoundary for this length; also different LogicalLaneBoundaries are needed if the lanes have different heights at their boundaries (e.g. road adjacent to a sidewalk).

◆ left_adjacent_lane

repeated LaneRelation osi3::LogicalLane::left_adjacent_lane = 10

Lanes that are directly left of this lane, without gap or overlap.

"Left" is in definition direction (not driving direction), so left lanes have larger T coordinates. Entries must be ordered: first by start_s, then by end_s.

The XY positions of the polyline generated by the LogicalLaneBoundaries of adjacent lanes must match up to a small error (5cm). Typically adjacent lanes will share a LogicalLaneBoundary, but this will not always be true. Examples: on intersections, it might be hard to generate data such that lanes that are adjacent for a short length share a LogicalLaneBoundary for this length; also different LogicalLaneBoundaries are needed if the lanes have different heights at their boundaries (e.g. road adjacent to a sidewalk).

◆ overlapping_lane

repeated LaneRelation osi3::LogicalLane::overlapping_lane = 11

Lanes that partially or completely overlap this lane.

Only overlaps laterally larger than 5cm are considered overlaps for the purpose of this relation.

This will typically contain a lot of entries on intersections, but might also be used outside of intersections (e.g. if a TYPE_BIKING lane overlaps a TYPE_NORMAL lane).

Entries must be ordered: first by start_s, then by end_s.

◆ right_boundary_id

repeated Identifier osi3::LogicalLane::right_boundary_id = 12

Right boundary of this lane.

References to LogicalLaneBoundary elements. All LogicalLaneBoundary elements referenced here must refer to the same ReferenceLine as this lane. The boundaries together must cover the whole length of the lane (the range [start_s,end_s]) without gap or overlap. The boundaries must be stored in ascending order, starting with the smallest S position. Consecutive boundaries must share a point: the last point of the previous boundary must be identical to the first point of the next boundary.

Note: the referenced boundaries may have points outside of [start_s,end_s] (e.g. a boundary may extend beyond the end of a lane).

Note: A curb is a type of LogicalLane and of LaneBoundary. If LogicalLane.Type == TYPE_CURB, by convention this field references the respective LaneBoundary of TYPE_CURB identically to the left_boundary_id of this LogicalLane.

Rules\n\code{.unparsed}: refers_to: LogicalLaneBoundary

◆ left_boundary_id

repeated Identifier osi3::LogicalLane::left_boundary_id = 13

Left boundary of this lane.

References to LogicalLaneBoundary elements. All LogicalLaneBoundary elements referenced here must refer to the same ReferenceLine as this lane. The boundaries together must cover the whole length of the lane (the range [start_s,end_s]) without gap or overlap. The boundaries must be stored in ascending order, starting with the smallest S position. Consecutive boundaries must share a point: the last point of the previous boundary must be identical to the first point of the next boundary.

Note: the referenced boundaries may have points outside of [start_s,end_s] (e.g. a boundary may extend beyond the end of a lane).

Note: A curb is a type of LogicalLane and of LaneBoundary. If LogicalLane.Type == TYPE_CURB, by convention this field references the respective LaneBoundary of TYPE_CURB. identically to the right_boundary_id of this LogicalLane.

Rules\n\code{.unparsed}: refers_to: LogicalLaneBoundary

◆ predecessor_lane

repeated LaneConnection osi3::LogicalLane::predecessor_lane = 14

Lanes that directly are connected to this lane at the beginning.

"Beginning" is relative to the reference line, so connections at start_s.

Lane predecessors and successors shall only be used to connect lanes if a physical connection at the beginning or end of both lanes exist. Both lanes have a non-zero width at the connection point and they are semantically connected.

A lane may have several predecessors e.g. on intersections, or if a wide lane splits into two, or two merge into one.

◆ successor_lane

repeated LaneConnection osi3::LogicalLane::successor_lane = 15

Lanes that directly are connected to this lane at the end.

"End" is relative to the reference line, so connections at end_s.

Lane predecessors and successors shall only be used to connect lanes if a physical connection at the beginning or end of both lanes exist. Both lanes have a non-zero width at the connection point and they are semantically connected.

A lane may have several successors e.g. on intersections, or if a wide lane splits into two, or two merge into one.

◆ street_name

optional string osi3::LogicalLane::street_name = 16

Name of the street this lane belongs to.

◆ traffic_rule

repeated TrafficRule osi3::LogicalLane::traffic_rule = 17

A list of traffic rules on the lane.

The documentation for this struct was generated from the following file:

osi_logicallane.proto

Classes

Public Types

Public Attributes