Closed pmai closed 5 months ago
It was unlcear which pivot point the Position definition represents in relation to the dimension and rotation. Added a comment, that it is the center of the BoundingBox.
For Type "TYPE_OTHER", there was no possibility to express the object more detailed. I introduced a string type to describe it.
This other_object_type offers the possibility to reduce the Type enum and split it up an an additional PR to update it later on. This type should not be in conflict to other current approaches harmonizing object type definition. Through the other_object_type filed, the overall SubBoundingBox approach is already usable.
@pmai Why did my DCO fail again? :.(
CCB 2024-01-29: Type enum should be reviewed (e.g. by @PhRosenberger, @thomassedlmayer, @pmai) esp. w.r.t. sensor modeling needs and a minimum list should be proposed. If no such list emerges, then having no enums, but also dropping the string fallback (as e.g. model_reference can already be used as a last effort fallback) would be the preferred way forward. Will be re-reviewed at next CCB.
CCB 2024-02-26: Small addition of examples for TYPE_DOOR in the context of vehicles to be added by @pmai, otherwise is ready for merge as-is.
This PR is a continuation of #695 (and #685) with fixed history. It proposes the addition of bounding box sub-sections to BaseMoving and BaseStationary objects, to help sub-divide and classify different parts of the overall object structure.