Extension osi lane

[0815-code]

Reference to a related issue in the repository

Add a reference to a related issue in the repository.

Add a description

A polyline model was added to the osi_lane.proto to describe the lane boundaries with a polyline up to 3rd order.

Some questions to ask:
What is this change?
What does it fix?
Is this a bug fix or a feature? Does it break any existing functionality or force me to update to a new version?
It is a feature.

How has it been tested?

Mention a member

@PhRosenberger @ThomasNaderBMW @jdsika

Check the checklist

• My code and comments follow the style guidelines and contributors guidelines of this project.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests / travis ci pass locally with my changes.

[clemenshabedank]

Hello @ThomasSchloemicherAVL let's discuss at your next meeting if this is postponed for major release or introduced in V3.3. I think there is nothing in it that would break backwards compatibility (besides that you can't just switch the enumeration values). But we should discuss if it might be a useful and reasonable field within SensorView/GroundTruth or if we only want to introduce it in osi_detectedlane.proto. The way you implemented it doesn't really make clear which or if both models (boundary points + BoundaryPolyLineModel) should be used.

My opinion would be: Definitely useful for detected lane boundaries, especially with the harmonization with ISO 23150 aspect. For lane boundaries in GroundTruth I am sceptical because it is actually already processed data. But on the other hand it could make calculations easier for Traffic Participants... But I would then tend to take this model as a center line extension because the centerline is already "imaginative data" and is used for guiding traffic participants.