osi3::LogicalLaneBoundary Struct Reference

Passing rule of the LogicalLaneBoundary.

This describes how vehicles are legally allowed to move across the LogicalLaneBoundary. The PassingRule is determined solely based on the semantics of (physical) lane boundaries, not on any signs (i.e. it may be overridden by signs).

The ID of the lane boundary.

Rules

is_globally_unique

Points making up the lane boundary.

The boundary must be defined in the same direction as the reference line. So S positions should increase along the line. Note that S positions will not always increase strictly monotonically. Example:

               |---------\
               |          \
 /---boundary--|           \------------
/
---------- reference line --------------

At the place where the boundary suddenly increases, two points will have the same S coordinate.

If the boundary approximates a curve (e.g. a cubic function in OpenDRIVE), the points must be chosen in a way that the lateral distance to the ideal line does not exceed 5cm. As shown in the following image:

Approximation error green line.

The Z error (difference in Z height between boundary_line and the "real" line) must not exceed 2cm. This is a stricter requirement than for errors in the XY plane, because Z differences between lanes influence driving very much.

Note: if two lanes have different Z heights (e.g. a driving lane is beside a sidewalk, where the sidewalk is 10cm higher than the road), then these lanes cannot share a boundary, since their boundaries have different Z heights.

The reference line for this boundary.

The reference line is used as a coordinate system for this boundary. All points of this LogicalLaneBoundary must have S coordinates in the range [sStart,sEnd].

The reference line should roughly have the same shape as the boundary (so roughly parallel to the lane middle), so that S coordinates continually increase along the boundary.

Rules

refers_to: ReferenceLine

Reference to the physical lane boundary or boundaries that make up this logical boundary.

Rules and notes:

• This list is empty if there are no physical lane boundaries to delimit a lane.
• In the common case, this will contain one physical boundary.
• This list contains several lane boundaries if there are several physical lane boundaries at one S position (e.g. both a broken and a solid line).
• If there are several lane boundaries, they must be listed in increasing T order (i.e. from right to left in reference line direction). Rationale: this makes it easier to determine e.g. rules on lane changes, which depend on the T order of the lanes.
• Whenever physical lane boundaries begin or end, or switch their T position (if there are multiple physical lane boundaries), a new LogicalLaneBoundary must be created.
• The referenced LaneBoundary objects may be longer than the LogicalLaneBoundary which references them, but must never be shorter.

Example:

      Lane 1
 --------a------------------ - - - -c- - - -           ---->
 - - - -b- - - -
      Lane -1

This shows the boundary between lane 1 and lane -1, with the reference line going from left to right. First there is a solid-broken line (a and b), then there is only a solid line (a), then there is a broken line (c). There would be three LogicalLaneBoundary objects between Lane1 and Lane2: the first would reference first b and then a, the second would reference only a, and the third would reference c.

Rules

refers_to: LaneBoundary

The passing rules, insomuch as they can be determined just from road markings.

Optional external reference to the lane boundary source.

Note

For OpenDRIVE, there is no direct possibility to reference the RoadMark, as there is no unique identifier in this sub-object.

For non-ASAM Standards, it is implementation-specific how source_reference is resolved.

The value has to be repeated because one object may be derived from more than one origin source, for example, from a scenario file and from sensors.