Add new message for BoundingBox sub-sections

[ndunningbmw]

Reference to a related issue in the repository

Add a reference to a related issue in the repository.

Add a description

This PR 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.

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?
How has it been tested?

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the message documentation and the fields and enums documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

If you can’t check all of them, please explain why.
If all boxes are checked or commented and you have achieved at least one positive review, you can assign the label ReadyForCCBReview!

[ndunningbmw]

Suggested change

	// \note The bounding box sections can include side mirrors for vehicles.
	// \note The bounding box sections can include side mirrors, doors, etc. for vehicles.

[ThomasNaderBMW]

Hi @tbleher , hi Jakob Peintner,

would you also like to give a review on this PR?

[thomassedlmayer]

Outcome WG Other Models (21th Nov): We want to handle the most significant cases for stationary objects here as well (e.g. tree trunk, tree crown, ...).

[ndunningbmw]

Proposal: Move the text for the "exceptional cases" to the enum field where they would be used from.

[ndunningbmw]

Proposal: Mention the data encoded in MovingObject/VehicleAttributes/WheelData and in which case this one should be used, and how the 2 fields are different

[tbleher]

Hi @tbleher , hi Jakob Peintner,

would you also like to give a review on this PR?

I think the initative is a good one :)
I can only really talk about bounding boxes of static objects (which is what I'm currently looking at for the OSIPedestrian model): it's very good for e.g. pedestrian models if tree trunk and tree arm can be separated (and similarly light pole and light arm). However, I have two main concerns with the proposal right now:

• How would this be filled in from OpenDRIVE? A static object in OpenDRIVE can have an arbitrary number of bounding boxes, so one would expect that a tree has two bounding boxes. But there is no labeling of the bounding boxes. So how would one know which one is which? (Of course, I can add a heuristic to the code, but most implementations will probably just make it TYPE_OTHER, since OpenDRIVE doesn't have these labels).
• I see no language in the proposal that the object is fully contained in the sub-bounding boxes. So AFAICS there is no assurance that if I have a tree with sub-bounding boxes, that the tree is only in that sub-area, and the pedestrian can walk freely in areas that are covered by the parent dimension, but is not filled by the specific bounding boxes. Without this guarantee, the sub-bounding boxes are useless for the purpose of pedestrian models.

So, speaking as someone creating agent models, it would be much more important to have the ability to segment an object such that one has the guarantee that some areas of the dimension are in fact free. For such use-cases, the exact type does not matter at all, and could be left out. Is there any user who cares about this (the type distinction) for static objects like trees and traffic lights? I can see how this is important for wheels vs mirrors and such, but not so much for crown vs trunk - I just want to have a better 3D approximation of the tree so the pedestrian can accurately walk around it.