Vehicle assignments #85
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -139,3 +139,47 @@ Because some events may overlap in time, it may not be possible to choose a sing | |
| - Events may have gaps between the end time of one event and the start time of the next. e.g. if an operator's layovers aren't represented by an event. | ||
| - `start_time` may equal `end_time` for an event that's a single point in time (such as a report time) without any duration. | ||
| - Recommended sort order: `service_id`, `run_id`, `event_sequence`. | ||
|
|
||
| ### `vehicle_assignments.txt` | ||
|
|
||
| Primary Key: `(date, block_id, service_id)` | ||
|
|
||
| | Field Name | Type | Required | Description | | ||
| |---|---|---|---| | ||
| | `date` | Date | Required | | | ||
| | `service_id` | ID referencing `calendar.service_id` or `calendar_dates.service_id` | Optional | Identifies a set of dates when the trip is scheduled to take place. Required if `block_id`s are repeated between different `service_id`s. | | ||
| | `block_id` | ID referencing `trips.block_id` | Required | Identifies the block. | | ||
| | `vehicle_id` | ID referencing `vehicles.vehicle_id` | Conditionally required | Refers to a specific vehicle in the transit fleet. Either `vehicle_id` or `vehicle_type_id` MUST be supplied. | | ||
| | `vehicle_type_id` | ID referencing `vehicle_types.vehicle_type_id` | Conditionally required | Refers to a type of vehicle in the transit fleet if there is no specific vehicle assignment. Either `vehicle_id` or `vehicle_type_id` MUST be supplied. If both are supplied, then the supplied `vehicle_type_id` must match the row referenced in `vehicles.txt`. | | ||
|
|
||
| Not every trip or block and date combo needs to have a vehicle specified. | ||
|
|
||
| ### `vehicle_types.txt` | ||
|
|
||
| Primary Key: `vehicle_type_id` | ||
|
|
||
| _Note:_ Fields to describe vehicle and vehicle type attributes are under discussion during this draft and will likely change significantly. | ||
|
|
||
|
|
||
| | Field Name | Type | Required | Description | | ||
| |---|---|---|---| | ||
| | `vehicle_type_id` | ID, primary key | Required | Defines an ID for a vehicle type. | | ||
| | `vehicle_type_name` | Text | Optional | Brief plain-language description of the vehicle. E.g. “MR73” in Montréal, “TGV Duplex” in France or “8-car Waratah Train” in Sydney. | | ||
| | `fuel_type` | Enum | Optional | 0 or empty - unknown propulsion <br />1 - Gasoline <br /> 2 - Diesel <br /> 3 - LPG auto <br /> 4 - Mixture <br /> 5 - Biodiesel <br /> 6 - Electricity <br /> 7 - Hybrid <br /> 8 - Natural Gas <br /> 9 - Other | | ||
| | `wheelchair_accessible` | Enum | Optional | Wheelchair accessible. <br />0 or empty - no <br />1 - yes | | ||
| | `seating_capacity` | Non-negative Integer | Optional | This number denotes the number of seats dedicated to riders, excluding folding seats. A seat is considered accommodating only one rider in a seated position. | | ||
| | `max_capacity` | Non-negative Integer | Optional | This number denotes the maximum number of riders that the vehicle can carry. | | ||
| | `wheelchair_capacity` | Non-negative Integer | Optional | This number denotes the maximum number of riders in a wheelchair that the vehicle can carry. | | ||
|
|
||
|
There was a problem hiding this comment. There are so many fields that could be included here. (Height clearance, platform height, wheel gauge, length, make, model, ...) What determines whether something should be included, vs something that should be looked up elsewhere based on There was a problem hiding this comment. At this point, I think we should implement only fields that will be consumed by some software either out-of-the-gate or soon. Any other fields discussed could be implemented when there is a use later. There was a problem hiding this comment. Is there a reason to exclude folding seats from the I know there are many agencies that almost exclusively use transverse folding seats, which could lead to artificially-lower |
||
| ### `vehicles.txt` | ||
|
There was a problem hiding this comment. How do consists of multiple cars work, both for trains made of all the same car, and trains made of multiple different cars? Would there be a type_id for each type of car, or for each unique way to assemble a train? And then a vehicle_id for each car, or a vehicle_id for the whole train? Is a 4-car train the same type as a 6-car train of the same cars? If a train reverses and now has its control car in front and locomotive in the back, is that the same vehicle_id? There was a problem hiding this comment. So, this is one of the reasons that I have proposed to build off GTFS-Vehicles. The draft spec has something called GTFS-VehicleCouplings that answers this. |
||
|
|
||
| Primary Key: `vehicle_id` | ||
|
|
||
| | Field Name | Type | Required | Description | | ||
| |---|---|---|---| | ||
| | `vehicle_id` | ID, primary key | Required | Defines an ID for a vehicle. | | ||
|
There was a problem hiding this comment. Is this the same ID as shows up in GTFS-RT? If so, that should probably be mentioned, though agencies might not have a consistent mapping of phsyical vehicle to GTFS-RT vehicle_id, which might make it impossible to use the same ID here. There was a problem hiding this comment. There is theoretical usefulness of a consistent |
||
| | `vehicle_type_id` | ID referencing `vehicle_types.vehicle_type_id` | Optional | | | ||
| | `vehicle_description` | Text | Optional | | | ||
|
There was a problem hiding this comment. I think the description should be on the type, instead of the individual. Individuals within each type shouldn't be unique enough to require their own description, but a description field could be useful on the type. Edit: I see the type is optional, so this could be useful to give details on a vehicle that doesn't have a type. But I feel like a better approach would be to add a type for the vehicle and describe it there. Denormalizing the data into the individual vehicles is only useful if agencies have many bespoke vehicles, which seems rare. There was a problem hiding this comment. Was assuming that descriptive text strings can end up being useful for edge cases we can't anticipate. There was a problem hiding this comment. I see this field being useful for vehicle-specific things, even more esoteric items like "Veterans-Wrapped Coach" or "Heritage Paint Scheme." |
||
| | `registration_date` | Date | Optional | | | ||
|
There was a problem hiding this comment. What should be the reasoning for which fields belong in TODS?
|
||
| | `license_plate` | Text | Optional | License number of the vehicle for identification, e.g. “E898656” | | ||
|
There was a problem hiding this comment. There may need to be a |
||
| | `owner` | Text | Optional | Registered owner, e.g “City of Arcata” | | ||
|
There was a problem hiding this comment. Perhaps There was a problem hiding this comment. @skyqrose Yes and no. In interstate rail, it's not uncommon for various identical pieces of equipment to be owned by different operators (e.g. 4/120 SEPTA SLV cars are owned by the State of Delaware, but are otherwise identical and interchangeable with the rest of the fleet; MNR's M8s are owned in a mix between MNR and ConnDOT, but the cars are likewise identical). From a planning perspective, we wouldn't necessarily care whose car was operated, just that one of those cars was operated along the trip. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does there need to be a distinction between battery buses that charge at a station, and trolley buses that charge under catenary? Does there need to be a Hydrogen category?
There are so many options here, I wonder if it'd be better to have an unrestricted string enum, or if the field should be removed and an agency should know (from some other non-TODS record) what fuel type each
vehicle_type_nameuses.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this list is messy -- properties are mixed up. "Hybrid" isn't a fuel type. For now, I favor removing or replacing with a text string if it's necessary for an immediate use case. (But imagining that the vehicle_category_name could make useful distinctions, e.g.
vehicle_category_name="40' LNG Bus".