Support clothoid spline ("multi-clothoid") trajectories

Describe the feature

I would like to partially pick up Issue 274 again but suggest a less generic solution.

"In OpenSCENARIO 1.2 a trajectory contains ONE shape that can be one of three types:

Polyline (arbitrary number of straight line segments)
Clothoid (spiral)
Nurbs (a spline variant with arbitrary number of segments)

One problem is that one trajectory can only contain one clothoid. So an improvement would be to allow multiple clothoids in one trajectory shape."

In Issue 274 it was suggested to solve this problem by combining multiple shapes, which turned out to be complicated. Since it is still very much desired to have support for clothoid spline trajectories, which are often used by vehicle trajectory planners, I would like to suggest that OpenSCENARIO 1.3 should support them inside a SINGLE shape.

Also one of the suggested workaround of using NURBS is not always a good idea since the interpreting tool can not easily know if the NURBS is eseentially a clothoid or not. This "Metainformation" is simply lost during OpenSCENARIO export. Also reconstructing clothoid splines from NURBS is tricky and could be avoided altogether with an extension of the standard.

Describe the solution you would like

There are two possible solutions.

Extend the existing Clothoid to be not [0..1] but [0..*]
Introduce a new Shape "ClothoidSpline" which contains the connection points and the curvatures at each of the spline vertices.

Possible definition of ClothoidSpline:

Name	Type	Cardinality	AppliedStereotypes	Description
position	Position	1..1	XSDelement	Start position of the clothoid spline including orientation. If in the start position for an orientation dimension no value is provided, then a default of 0 is assumed.
connectionPoints	double	1..*	XSDattribute	Connection point(s) of the clothod spline.
curvatures	double	1..*	XSDattribute	Curvatures of clothoid spline at start and connection points. Unit: [1/m]. Range: ]-inf..inf[.
curvatureRates/curvaturePrimes	double	0..1	XSDattribute	Optional rates of change of the curvatures of the clothoid spline segments. Unit: [1/m²]. Range: ]-inf..inf[.
lengths	double	1..*	XSDattribute	Lengths of clothoid spline segments. Unit: [m]. Range: ]0..inf[.
times	double	0..*	XSDattribute	Optional time specification at the connection points of the clothoid spline. Unit: [s]. Range: [0..inf[.
speeds	double	0..*	XSDattribute	Optional speed specification at the connection points of the clothoid spline. Unit: [m/s]. Range: ]0..inf[.

Note: Alternatively it could be possible to store the vertices of the so called "control polyline" instead of the connection points. This would result in one extra point and additional calculations at the reader side though.

Describe alternatives you have considered

Alternatives consist of "horrible" workarounds such as "tunneling" a clothoid spline through a polyline shape (using the polyline vertices as the clothoid spline connection points) and reconstructing the clothoid spline segments at the receiver by assuming certain constraints to arrive at a unique solution. This obviously violates the standard since no tool can interpret this without knowing the constraints and knowing that the polyline should not be interpreted as a polyline.

Describe the backwards compatibility

This should be mostly backwards compatible since either

When we use the first approach exporting to 1.2 and below we just write a single clothoid
When we use the second approach we just have a new Shape which can only be read by the new tools/parsers

Additional context

The first approach might be problematic since it implies that each clothoid segment has its own local coordinate system. In case of a RoadPosition it could then be very tricky to put the segments together, this problem does not exist for the ClothoidSpline approach which would assume one joint coordinate system for all clothoid segments.

Edited Aug 02, 2022 by Johannes SCHMITZ (CARIAD)