Draft for discussion: Feature/add elements to lane boundary classification type

[FlorianMueller87]

Reference to a related issue in the repository

#642

Add a description

ASAM OSI and ISO 23150 or AUTOSAR ADI have a common history. Unfortunately, the inner structure, the naming and the definitions of the standards are differentiated from each other. This makes the work of developers unnecessary complicated for mostly no technical reasons. All sides should strive to reduce inequality.

ASAM OSI need the entries for osi_lane – LaneBoundary – Classification - Type to be compatible with AUTOSAR ADI RoadBoundaryType.?

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• [x] My suggestion follows the style and contributors guidelines.
• [x] I have taken care about the documentation.
• [x] I have done the DCO signoff.
• [x] My changes generate no errors when passing CI tests.
• [ ] I have successfully implemented and tested my fix/feature locally.
• [ ] Appropriate reviewer(s) are assigned.

Describe alternatives you have considered

No alternative was considered.

Describe the backwards compatibility

The adding of the elements will not lead to backward compatibility issues. Additional context

ISO23150:2021 A.2.102 Road boundary type

[jdsika]

@FlorianMueller87 Our discussion in WG Harmonization: For what are we doing this classification? Do we need a fence due to its property of being made of a specific material, having a certain height, or acting as a barrier preventing cars from driving off the lane? (the latter maybe not?) We need an answer what the comsumer of the signal want it to be:

• What is needed from a sensor model perspective -> the focus might be on the material and the possibility to detect and classify it
• What is needed from an AD function perspective -> the focus might be on the question if a car can drive though it for e.g. an evasive maneuver