Enabling separation of trips and runs via trip_service_ids

[jeffkessler-keolis]

In This Change

Per #76, this change:

• Allows producers to build multiple sets of runs that map to the same trips.
• Allows producers to define sets of trips under a new service_id, which was not possible beforehand.
• Allows producers to modify calendar assignments as a byproduct of defining and assigning new service_ids per the above.

Modifications

• This change is a non-breaking change for producers, who can continue to publish TODS as-is with it remaining valid.
• Consumers loading TODS data published without a defined trip_service_id would be able to do so without modification.
• Producers wishing to include separate sets of runs in distinct service_ids would be able to do so without needing to modify the underlying public-facing GTFS (as previously required, in contravention of the TODS maxim of not requiring changes to the underlying GTFS).
• Consumers reading this data would need to update their applications to support handling an additional field (trip_service_id) in the primary key fields of run_events.txt.

Benefits

• Several producers are blocked from producing run_events.txt in the current design, as it is impossible to modify underlying runs without also modifying the public GTFS, as is not always possible.
• This change adds flexibility in the handling of run data across multiple days of the week.
• This change enables future rostering development with a clearly-defined process for defining runs.

---

Multiple examples are included herein. For more details, see #76.

[github-actions]

Preview url: https://operational-data-standard-80--cal-itp-previews.netlify.app

[safrazier17]

Note from working group conversation:

1. trips.txt is keyed by trips.trip_id, which means it is not possible to have a single trip_id on two different services. This obviates the need for run_events.trip_service_id because TODS does not need to identify the service on which a trip takes place.
2. Under proposal, a given service_id can relate to a trip_id or a run_id or to both.
3. There is some concern about validating service_ids and making sure that we do not negatively impact existing validation of trips.
4. There may be a fuzzy boundary between when to represent schedule elements as run events vs. roster changes.

[skyqrose]

I have a bunch of comments, but they're just about details and examples. As a whole, I like the proposal, especially after the idea from the working group about removing the trip_service_id column.