Support multiple shapes in trajectory
Describe the feature
In OpenSCENARIO 1.0 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. But a more complete improvement would be to allow for a multiple instances and a mix of the three shape types within one trajectory definition. Today a user need to define multiple trajectories which cause overhead both in description and execution.
Another, maybe even worse, problem is the challenge of calculating the longitudinal distance along multiple trajectories defined in separate events, with separate triggers. Just to determine whether they form a continuous path, in space and time, would require quite some analysis. Putting all shapes in one trajectory would greatly simplify the task.
Describe the solution you would like
A straight forward solution would be to allow multiple shapes (of any kind) within one single trajectory element. Something like:
name string 1..1 XSDattribute Name of the trajectory type. Required if used in catalog.
closed boolean 1..1 XSDattribute True if trajectory is closed.
parameterDeclarations ParameterDeclaration 0..* XSDwrapped Definition of additional parameters.
shape Shape 1..* The shape of a trajectory (Polyline, Clothoid or Nurbs)
The only thing changed is the cardinality of Shape, from 1..1 to 1..*.
Describe alternatives you have considered
Just allowing multiple clothoids within the same (clothoid) Shape. But that would bring only limited value since the trajectory can only include one type of shapes. Still there will be cases where the user need to concatenated trajectories of separate actions, actually events since they all need unique triggers. And the distance calculation challenge remains as well. So this alternative is not that attractive.
Describe the backwards compatibility
The proposed solution, allowing more than one shape in a trajectory, is fully backward compatible since it is still valid to have only one.
Additional context
A trajectory can have one or multiple shapes to form short or long well defined paths for entities to follow. The position and orientation of the complete trajectory is purely defined by the first shape. Each subsequent shape is, regardless of its definition, transformed in terms of translation and rotation to connect directly to the endpoint of the preceding shape. The subsequent shape is rotated to fulfil C1 (continuous derivative). In other words, starting position and orientation of subsequent shapes is resolved by the tool to achieve C1 connection between the shapes, disregarding that part of the Shape definition.
See below an example with three shapes of different types.
However, if the user want a non continuous derivative, that can be solved by adding a polyline shape with desired shift of heading, like in the image below.