search

opentripmodel / otm5-change-requests

Tracking and reporting bugs and change requests of the OTM5 specification.
5 stars 1 forks source link

OTM5 - Vehicle and Sensor (direct) association #2

Closed thomaskolmans closed 3 years ago

thomaskolmans commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Very nice! Thank you.

bmeesters commented 3 years ago

@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 commented 3 years ago

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

bmeesters commented 3 years ago

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

bmeesters commented 3 years ago

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

bmeesters commented 3 years ago

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