The Transit Operational Data Standard is an open standard for representing the transit schedules used by drivers, dispatchers, and planners to carry out transit operations.
It's a backwards in-compatible change to add required fields and make a required field optional. It's not totally necessary because you could work around these fields by querying through runs.txt or maybe runs_pieces.txt, but it will be more convenient and consistent, and allow representing some new edge cases.
Currently:
run_events.txt has a requiredpiece_id field. It does not have service_id or run_id.
deadheads.txt has a required service_id field and a requiredblock_id field. It does not have run_id or piece_id.
Proposed:
run_events.txt
Field name
Type
Required
Description
Change
service_id
ID referencing calendar.service_id
Required
Identifies a set of dates when the event is scheduled to take place.
New
run_id
ID referencing runs.run_id
Required
Identifies the run during which the event takes place.
New
piece_id
ID referencing runs.piece_id
Optional
Identifies the piece during which the event takes place. May be left null for events that take place outside of a piece, such as a break.
Optional
deadheads.txt
Field name
Type
Required
Description
service_id
ID referencing calendar.service_id
Required
Identifies a set of dates when the deadhead is scheduled to take place.
Unchanged
run_id
ID referencing runs.run_id
Optional
Identifies the run during which the deadhead takes place.
New
piece_id
ID referencing runs.piece_id
Optional
Identifies the piece during which the deadhead takes place.
New
block_id
ID
Optional
Identifies the block to which the deadhead belongs.
Optional
Benefits:
Can query run_events by date/service_id without going through runs.txt/runs_pieces.txt.
Deadheads can be used by agencies that don't otherwise publish run_ids or block_ids, or can represent deadheads that are not associated with a run or block. (This is just hypothetical to me, but it seems like the restriction isn't necessary.)
trips.block_id is optional, so deadheads.block_id should be too.
Makes querying run_events.txt, deadheads.txt, and trips.txt very similar, which is nice since they're the three types of things that can be in a run.
skyqrose
commented
6 months ago
This propsal makes the
service_id,run_id,piece_id, andblock_idfields more consistent.It's based on the
runs.txtproposal, but could be done independently of it.It's a backwards in-compatible change to add required fields and make a required field optional. It's not totally necessary because you could work around these fields by querying through
runs.txtor mayberuns_pieces.txt, but it will be more convenient and consistent, and allow representing some new edge cases.Currently:
run_events.txthas a requiredpiece_idfield. It does not haveservice_idorrun_id.deadheads.txthas a requiredservice_idfield and a requiredblock_idfield. It does not haverun_idorpiece_id.Proposed:
run_events.txt
service_idcalendar.service_idrun_idruns.run_idpiece_idruns.piece_iddeadheads.txt
service_idcalendar.service_idrun_idruns.run_idpiece_idruns.piece_idblock_idBenefits:
Can query
run_eventsby date/service_idwithout going throughruns.txt/runs_pieces.txt.Can represent run events that are on a run but not a piece, e.g. a break.
Deadheads can be used by agencies that don't otherwise publish
run_ids orblock_ids, or can represent deadheads that are not associated with a run or block. (This is just hypothetical to me, but it seems like the restriction isn't necessary.)trips.block_idis optional, sodeadheads.block_idshould be too.Makes querying
run_events.txt,deadheads.txt, andtrips.txtvery similar, which is nice since they're the three types of things that can be in a run.