Add service_start and service_end to Vehicle object in Provider and Agency APIs

[Mu-yi-Zhou]

Explain pull request

In response to Issue #899, adding a required field service_start and required if available field service_end to Vehicle endpoint of Provider API.

• No, not breaking

Impacted Spec

• provider

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ schnuerle
❌ Mu-yi-Zhou
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[schnuerle]

What about calling these fields lifecycle_start and lifecycle_end to more accurately describe their use, as described here?

[schnuerle]

At the public working group meeting, we discussed this at length. Here are some of the key takeaways. See notes for full details and recording.

Key Points

• MDS Vehicles is a real time status of vehicles, not a history
• Vehicle property change: when part of a vehicle is changed: accessibility, batter, tires, IoT device, license plate, color, etc (custom for each Mode). Useful for knowing use and rides with certain equipment. This is really what SFMTA wants to see (going to rename Issue/PR). Is this history a new data structure in MDS? Or a new event type in Events with descriptive text?
  • Vehicle lifecycle: when a vehicle was added to service, then finally retired. Useful for carbon footprint discussions, lifetime operations, green goals, etc. MDS Events already has decommissioned state for when its removed from service.
  • Vehicle maintenance: When vehicles have maintenance done on or off street - already covered in MDS with vehicle states in Events. Last inspection date is in Vehicles now. Some public agencies get this in monthly reports, but MDS should be able to handle this instead.
• Need to hear more from operators, vendors, data aggregators. Comment on GitHub now with challenges or issues.