The introduction of #123 lead to some of my minimal OSI traces not running anymore. These traces contained the most minimal set of OSI messages that is required to visualize a moving object following a trajectory. E.g. for such visualization, velocity or acceleration values are not necessary. Also, it does not require orientation rates, light states, or other vehicle attributes etc. to be set.
Should we define such minimal OSI set and a corresponding test case to check whether the asam-osi-converter is still able to run it without issues? Otherwise new features might break things again and again as it was demonstrated by #123.
To my thinking only the following moving object's fields are essential for a basic visualization:
- id
- base
- dimension
- position
- orientation
- type (vehicle/pedestrian/animal)
Every additional field can add more details to the visualization but is not essential in terms of the basic geometric order of events.
This is strongly related to #126.
The introduction of #123 lead to some of my minimal OSI traces not running anymore. These traces contained the most minimal set of OSI messages that is required to visualize a moving object following a trajectory. E.g. for such visualization, velocity or acceleration values are not necessary. Also, it does not require orientation rates, light states, or other vehicle attributes etc. to be set.
Should we define such minimal OSI set and a corresponding test case to check whether the asam-osi-converter is still able to run it without issues? Otherwise new features might break things again and again as it was demonstrated by #123.
To my thinking only the following moving object's fields are essential for a basic visualization:
Every additional field can add more details to the visualization but is not essential in terms of the basic geometric order of events.
This is strongly related to #126.