Add MovingObject::VehicleAttributes to DetectedMovingObject class

[0815-code]

Describe the feature

Adding MovingObject::VehicleAttributes to the DetectedMovingObject class.

Describe the solution you would like

A clear and concise description of what you want to happen.

Describe alternatives you have considered

A clear and concise description of any alternative solutions or features you have considered.

Describe the backwards compatibility

How does the feature impact the backwards compatibility of the current major version of OSI?
If the suggested feature would be implemented would there be an issue with the previous versions of OSI? What part of OSI would break or improve by this feature?

Additional context

Add any other context or screenshots about the feature request here.

[0815-code]

@kmeids should we open a new pull request or deal with this issue in PR #368?

[pmai]

I'm a bit confused here: The content of VehicleAttributes is not intended to contain stuff that a sensor detects directly (e.g. driver id, etc.). All that data is intended to be in VehicleClassification (that is the reason that VehicleAttributes is/was split from VehicleClassification in the first place). So adding VehicleAttributes seems like the wrong approach to whatever is being discussed here... Maybe some attributes are missing in VehicleClassification, or some might have to be moved from Attributes to Classification?

[0815-code]

@pmai we have discussed it in WP13 and agreed to open up a ticket. I have to admit driver_id is an extreme case to measure but the rest might be mensurable one day

[pmai]

Even in the case of data that a sensor might detect, this would have potentially different semantics and should either be added as new fields to VehicleClassification or to DetectedMovingObject directly (in the case where something can be directly measured and does not require classification in the sense of OSI). In classification belong all data that might vary for each candidate object, whereas in DetectedMovingObject directly belong data that is assumed to not vary based on candidate.

Practically speaking I'm unsure which fields of VehicleAttributes would make sense in the near term to add though...