Conversation
chrisyamas
added
restructuring
|
Documentation available at: |
|
Data Validation Report
|
|
Data Validation Report
|
This warning is because the frictionless validation check can't find the |
botanize
left a comment
botanize
left a comment
There was a problem hiding this comment.
I believe this meets the needs discussed in the issue. However, it looks like this PR accidentally removes trip_id_performed from the trips_performed table. I also suspect that trip_id_performed should be required if it's part of the primary key. Though to be fair, it doesn't strictly need to be, service_date, crew_id and start_time should be sufficient for the primary key. Including trip_id_performed just makes it easier to use.
- undo removal of
trips_performed.trip_id_performed
There was a problem hiding this comment.
It looks like you've accidentally removed trip_id_performed from trips_performed!
| "name": "trip_id_performed", | ||
| "type": "string", | ||
| "title": "ID referencing trips_performed.trip_id_performed", | ||
| "description": "Identifies the trip performed. Optional if crew assignment is at vehicle level only." |
There was a problem hiding this comment.
Shouldn't trip_id_performed be required if it's part of the primary key?
| - `stop_visits` - Summarized boarding, alighting, arrival, departure, and other events (kneel engaged, ramp deployed, etc.) by trip and stop for each service date. | ||
| - `stop_visits` - Summarized boarding, alighting, arrival, departure, and other events (kneel engaged, ramp deployed, etc.) by trip and stop for each service date. | ||
| - `trips_performed` - Trips performed for each service date. | ||
| - `station_activities` - Summarized transactions, entries, and exits by stop or station and time period for each service date (for events not associated with a trip). | ||
| - `station_activities` - Summarized transactions, entries, and exits by stop or station and time period for each service date (for events not associated with a trip). |
There was a problem hiding this comment.
Looks like there's some extra whitespace in these lines.
3 participants
Summary
Adds new
vehicle_crewtable to support multiple crew members per vehicle/trip, including mid-trip reliefs. This addresses the limitation wheretrips_performed.operator_idcould only reference a single operator.Resolves #220
Changes
spec/vehicle_crew.schema.json(new) defines thevehicle_crewtable with:[service_date, trip_id_performed, crew_id, start_time]service_date,vehicle_id,crew_id,start_timetrip_id_performed(for vehicle-level assignments),crew_role,end_timecrew_roleenum:operator,conductor,fare_inspector,other(uses snake_case consistent with 🐛📄 – Improve event_type naming convention in passenger_events #235)trips_performed,vehicles, andoperatorssamples/template/TIDES/vehicle_crew.csv(new) provides header-only templatespec/trips_performed.schema.jsonupdatedoperator_iddescription to clarify optional usage and reference tovehicle_crewtable for multi-operator scenariosspec/tides-datapackage-profile.jsonaddedvehicle_crewtotides-tableenumsamples/template/TIDES/datapackage.jsonaddedvehicle_crewresource entryCHANGELOG.mdadded entries under[Unreleased]for new table and description changeReason for this change
Rail systems commonly have multiple crew members (operators, conductors) on a single trip, and operator reliefs mid-trip are standard practice. The current
trips_performed.operator_idfield can only reference one operator, forcing agencies to either lose crew data or pick an arbitrary operator to record.The new
vehicle_crewtable allows agencies to capture complete crew assignment history while keeping the existingoperator_idfield for simple single-operator cases.- See related discussion in Issue #220 and Fall 2025 TIDES Issues Working Group notes from December 1 and December 10.
Review checklist
Per change management policy, the following must be met before feature branch changes can merge to
developbranch: