osi3::LogicalLane Struct Reference

Definition of available lane types.

This is mostly aligned with OpenDRIVE, except that lane types modelling 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.

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.

The ID of the logical lane.

Note

Note ID is global unique.

Rules

is_globally_unique

The type of the logical lane.

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 definiton 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.

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

refers_to: Lane

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.

Neighbouring lanes (i.e. lanes that are neighbours 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 neighbouring 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

refers_to: ReferenceLine

Start S position of the lane.

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

End S position of the lane.

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

Requirement: end_s > start_s

Definition of the intended driving direction.

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).

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).

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 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

refers_to: LogicalLaneBoundary

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

refers_to: LogicalLaneBoundary

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.

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.