OTM5 - Vehicle and Sensor (direct) association

[thomaskolmans]

I'd like to add something to the OTM 5 spec
I would like to request a relation between Sensor(s) and a Vehicle. That would be an additional field named sensors in the Vehicle definition that has an inline or referenced association to the Sensor object. It should be an array of associations.

Is your feature request related to a problem?
Yes, the problem is performance for gathering sensor data related to a Vehicle. Especially sensors that will never be moved and are inherently related to the vehicle. Examples: a temperature sensor, a speedometer, a odometer etc.

Currently these Sensors are "associated" through a AssociationCreatedEvent. This means we would have find all relations that have not yet been detached from a Vehicle of the type Sensor and then query the latest data that has been pushed. This has a tremendous impect on our performance.

Describe the solution you'd like
That would be an additional field named sensors in the Vehicle definition that has an inline or referenced association to the Sensor object. It should be an array of associations.

Describe alternatives you've considered
The alternative is already available, on our end we would have to extend the Vehicle object and map it as AssociationCreatedEvent too in order to both have performance and uphold the OTM5 model. This however is partially anti-pattern and would result in double code in order to gain performance.

Additional context
The topic was discussed here before

[bmeesters]

I think this is a logical enhancement. It would also be consistent with how Vehicle and Trip interact. It is backwards compatible with the current specification (if the sensors are optional), and can make it simpler for some use cases.

@thomaskolmans as you can see, this is the very first issue, so we are still in the progress of figuring this out. But since the change is small I think it can be part of OTM5.1 (if/when accepted). I will get back to you this week, or maybe the start of the next.

And thanks for your input, it is appreciated.

[bmeesters]

@thomaskolmans I have asked around and heard no complains about this addition. So you can consider it part of OTM5.1. I will update the documentation somwhere next week.

[thomaskolmans]

Very nice! Thank you.

[bmeesters]

@thomaskolmans I made a 'beta' version here: https://otm5-documentation-api-dev.redoc.ly/

On top it references the change. We will still need to discuss how to deal with new releases on top of OTM5.0. That said, I encourage you to treat the change as 'final' because I don't see anything in the way of it making it to the official specification. So you can implement the new behavior if you want.

[thomaskolmans]

Appreciate it! We've implemented it into our own API already and are making great use of it.

[bmeesters]

Its on the official page now as pre-otm5.1

[bmeesters]

Reopening it as OTM5.1 accepted until it is part of the official API documentation

[bmeesters]

Closing this as it is now official part of OTM5.1