Addition of vehicles.txt to GTFS schedule by doconnoronca · Pull Request #636 · google/transit

doconnoronca · 2026-05-11T01:26:54Z

Summary

Adds new file vehicles.txt to describe the capacity, accessibility, appearance and features of individual vehicles or vehicle ranges.

Describe the Problem

Based on issue 458. When combined with the vehicle label in GTFS real-time or other real-time APIs, this allows consumers to provide a variety of information about the approaching vehicle to riders.

Use Cases

Inform riders about the type of vehicle approaching and if it is the same as the scheduled type of vehicle, such as when streetcars are replaced by buses.
Inform riders of the size, color and appearance of the approaching vehicle.
Inform consumers about the capacity of vehicles so that a better passenger load estimate can be calculated.
Allow analysts to calculate the actual capacity of a route based on vehicle capacity.
Inform riders of the availability of features including bike storage, luggage space, restrooms, changing points, WiFi.
Provide disabled riders of the accessibility features of the approaching vehicles and how the use them.

Proposed Solution

The addition of a new table called vehicles.txt that describes the vehicles of a transit agency. Also, the addition of vehicle_class columns to routes.txt and trips.txt which allows routes and trips to include the vehicles that typically operate for that route or trips and allow vehicles.txt information to be used if real-time data isn't available.

Type of change

GTFS Schedule

Functional Change
Non-Functional Change
Documentation Maintenance

Additional Information

There is currently a vehicles file in TIDES as well as TODS. This proposal expands on TODS with additional details that are useful for riders.

The Proposal: Add cyclist position availability fields to VehiclePosition and CarriageDetails includes a total_cyclist_positions value, which wouldn't be needed if the data was available from vehicles.txt.

Some of the examples for the use of Proposal: Additional (Trip) Notices could be handled by vehicles.txt including the availability of WiFi, food and bicycle storage.

I have created a Google Sheet with vehicles data for Toronto TTC, Los Angeles Metro, New York Metro North rail and Toronto GO Train. These can be downloaded as Comma Separated Values to generate a vehicles.txt file. These have been loaded into TransSee.

Some transit enthusiasts who use TransSee have contributed files as well. Transit enthusiasts could crowd source data in places where transit agencies don't generate it on their own. There could be TODS like extensions to this structure that would include data that is important to them.

BusTimes.org provides some of the same information for bus fleets in the UK.

Proposed Discussion Period

As a large proposal, I suggest at least three months of discussion.

Testing Details

Consumer(s): TransSee
Producer(s): TransSee has produced some vehicles.txt file based on public data and some transit enthusiasts have contributed some. I would like to see a transit agencies start generating the file.
Estimated Testing Period: At least three months.

Proposal Update Tracker

Date	Update Description
2026-05-10	Create PR draft

Checklist

I have read and understood the GTFS Change process.
I have read and understood the GTFS Guiding Principles.
I understand the Role of Advocate and the Responsibilities attached to it.
I have signed the Contributor License Agreement (CLA).
I have ensured that this proposal is not covered by an existing Pull Request.

Additional rows

…ehicles

skinkie · 2026-05-11T07:29:31Z

You are actually introducing Transmodel like functionality with newly invented terms. My suggestion would be to fully align the attribute names with NeTEx.

doconnoronca · 2026-07-19T00:22:45Z

I like the idea of having more vehicle info in the standard feed. However, I think it would be more applicable to have a file for vehicle types / groups that define the information you need, instead of the individual vehicles themselves.

The TIDES version of vehicles.txt includes a vehicle_groups file that has most of the descriptions and a vehicles file that has records for individual vehicles and which group they belong to.

GTFS Schedule: Perhaps a vehicle_types.txt
GTFS RT VehiclePositions: Perhaps a field that ties the vehicle to a vehicle type.

I am hesitant to make it a requirement to change GTFS schedule and GTFS real-time to fully enabled this feature, as changing both makes implementation take much longer.

In the case of Transit fleets with busses, vans, and etc. What happens when a vehicle goes offline for unexpected maintenance and the agency swaps with a different vehicle and possibly type? Publish a new GTFS export?

Out of service vehicles could still be listed. If a different vehicle is swapped in it would show up in the real-time data.

Let's say you have a single vehicle type. You could end up with a vehicles file with 200 - 1000+ vehicles listed in it, which are duplicates of each other with the exception of a couple fields.

The fleet ranges can handle that for most cases or the table could be split into vehicle_groups and vehicles files.

I like the idea of having the GTFS RT feed being able to define the vehicle type, which would also handle the case of vehicles switching in real-time.

ttaylor-avail · 2026-07-20T21:26:44Z

When combining agencies into a single feed, we append the agency_id to the end of most entity ids in the feed. Route, Stop, Trip, Vehicle, and etc. "{vehicle_id}-a{agency_id}"

Doesn't that violate the requirement that those ids match the GTFS schedule values.

Seems like GTFS real-time could use an agency_id field at the FeedEntity level

**doconnoronca **

@doconnoronca we ran into an issue with the few feeds we have which require combining 2 or more agencies. It seemed the GTFS spec didn't account for the sharing of certain ids like Route and Stop between the agencies. Appending the agency_id to the various entity ids solved the problem, and made the MobilityData validator happy. Ideally, I would love to have the agency_id carried into the rest of the schedule files, and the RT feed.

lauriemerrell · 2026-07-21T18:00:36Z

A couple of comments, just from myself as an individual:

This seems like it would be the first time that direct references to FTA categories are introduced into the GTFS Schedule spec (for vehicle_type and fuel_type). I am not sure if that's appropriate? For other fields (e.g. route_type) GTFS uses its own categories.
I wonder about facility_name which seems to be more about operational considerations than rider-facing display. It seems to me that there could be a risk of false precision if this field is populated in GTFS schedule and then consumers display information to riders based on inferences related to this.

lauriemerrell · 2026-07-21T18:01:03Z

+|  `vehicle_label_high` | Text | Conditionally Required | If a range of vehicles is represented this is the high end of the range for the vehicle label. The number of characters must be the same as `vehicle_label` and the range covers values with the same number of charactors and are between `vehicle_label` and `vehicle_label_high` when using an ASCII string comparison. Required if both `vehicle_label` and `vehicle_id_high` are included. |
+|  `agency_id` | Foreign ID referencing `agency.agency_id` | Recommended | Agency for the specified vehicles. |
+|  `license_plate` | Text | Optional | The license plate or number plate of the vehicle. Does not apply if a range of vehicles is being used. |
+|  `vehicle_class` | ID | Recommended | Identifies a class of vehicle that usually runs on certain routes. Ment to link with vehicle_class fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. |


typo Ment --> Meant

gcamp · 2026-07-29T17:18:16Z

I didn't mention anything on this PR, but I generally approve of the approach. I have a hard time seeing a use for all the different fields proposed, but if there's a consumer/producer of data, all good for me.

Note that I just stared #650 which would potentially interact if both PRs get approved. I made sure they are compatible!

manfredbrandl · 2026-08-13T13:42:56Z

I think we should start with vehicle_types.txt because it should be enough to inform passengers of the utilities provided by the vehicle. Information about individual vehicles dont help passengers as long as we dont have realtime-info about utilities unusable on the individual vehicle.

doconnoronca · 2026-08-15T15:46:44Z

I think we should start with vehicle_types.txt because it should be enough to inform passengers of the utilities provided by the vehicle. Information about individual vehicles dont help passengers as long as we dont have realtime-info about utilities unusable on the individual vehicle.

Even without realtime information on what might not be working on an individual vehicle, it can be very useful to know if a vehicle that is supposed to have certain features is operating or not.

skinkie · 2026-08-15T16:26:44Z

I think we should start with vehicle_types.txt because it should be enough to inform passengers of the utilities provided by the vehicle. Information about individual vehicles dont help passengers as long as we dont have realtime-info about utilities unusable on the individual vehicle.

Even without realtime information on what might not be working on an individual vehicle, it can be very useful to know if a vehicle that is supposed to have certain features is operating or not.

An operator has hunderds of vehicles, typically all of the same type. Without knowing which exact vehicle a trip / block (which is not in GTFS) is going to execute it, it will be just bloat.

manfredbrandl · 2026-08-15T19:45:12Z

Even without realtime information on what might not be working on an individual vehicle, it can be very useful to know if a vehicle that is supposed to have certain features is operating or not.

I do not agree! Passengers are not intrested to know if vehicle x is operating today or not. Passengers are intrested if the vehicle which operates on their trip does have certain features. For that it is enough to know the vehicle type.

doconnoronca · 2026-08-17T01:36:30Z

So do @manfredbrandl and @skinkie prefer only to have vehicle descriptions by vehicle type and not provide fleet number or fleet number ranges to possibly connect to real time data?

manfredbrandl · 2026-08-17T06:09:37Z

@doconnoronca I would like to display the planned vehicle specifications to passengers for future journeys. However, only the planned vehicle type and its planned specifications are known in advance. The actual vehicle used, including its vehicle type and the features it actually possesses (and which are operational), is only known in the real-time data at the start of the service. The specific vehicle is not required in the planning data; similarly, in the real-time data, only the features that are actually present are required.

vikiawv · 2026-08-17T06:59:34Z

I think passengers could also benefit from also knowing the exact vehicle class or vehicle number.

For instance ÖBB (from Austria) has a gigantic fleet of so called "Cityjets". Problem beeing: Every Cityjet under number 4746 158 has no power socket for USB-A or USB-C
Without the vehicle number there is no way on telling beforehand if the train is equipped with such a socket or not.

Additionally any Unit below Number 4746 158 is not equipped according to the standards for blind people. They can only travel with train 4746 158 and upwards allone, else they need company by either a seeing-eye-dog or another person that can see.

If in this case for example the Provider wants to submit this data on which exact carriage is used, it would be very great to know for blind people basically.

I am neither for nor against adding the vehicle number. I just think it adds value to specific usecases.

doconnoronca · 2026-08-17T10:57:36Z

@doconnoronca I would like to display the planned vehicle specifications to passengers for future journeys. However, only the planned vehicle type and its planned specifications are known in advance. The actual vehicle used, including its vehicle type and the features it actually possesses (and which are operational), is only known in the real-time data at the start of the service. The specific vehicle is not required in the planning data; similarly, in the real-time data, only the features that are actually present are required.

The proposal includes vehicle_class field added to the trips, routes and vehicles tables allows the planned vehicle type and its features to be known in advance.

manfredbrandl · 2026-08-17T12:10:58Z

The proposal includes vehicle_class field added to the trips, routes and vehicles tables allows the planned vehicle type and its features to be known in advance.

This proposal assumes that all vehicles are exported along with the timetable data. This means that new timetable data must be generated and imported, even if the timetable service (including vehicle types and their properties) remains unchanged. In the timetable data, we only have the vehicle types, whilst the individual vehicles are only available in the real-time system. How can we use this proposal to make vehicle properties available in both the timetable data and the real-time data?

doconnoronca · 2026-08-18T00:50:20Z

This proposal assumes that all vehicles are exported along with the timetable data. This means that new timetable data must be generated and imported, even if the timetable service (including vehicle types and their properties) remains unchanged.

I'm not sure why you are saying new GTFS schedule data must be generated if the time table and vehicle data hasn't changed. When new vehicles enter service?

In the timetable data, we only have the vehicle types, whilst the individual vehicles are only available in the real-time system. How can we use this proposal to make vehicle properties available in both the timetable data and the real-time data?

The purpose of the vehicle ids and labels is to link the vehicles real-time to the vehicle properties in the schedule data.

The vehicle_class can be used when real-time data is unavailable.

If both are available consumers can highlight an unscheduled differences in the vehicle for users.

skinkie · 2026-08-18T09:38:17Z

This proposal assumes that all vehicles are exported along with the timetable data. This means that new timetable data must be generated and imported, even if the timetable service (including vehicle types and their properties) remains unchanged.

I'm not sure why you are saying new GTFS schedule data must be generated if the time table and vehicle data hasn't changed. When new vehicles enter service?

That is not how it works. You expect there is a scheduled relation to an exact instance of a vehicle_type. That is not the case.

In the timetable data, we only have the vehicle types, whilst the individual vehicles are only available in the real-time system. How can we use this proposal to make vehicle properties available in both the timetable data and the real-time data?

The purpose of the vehicle ids and labels is to link the vehicles real-time to the vehicle properties in the schedule data.

The vehicle_class can be used when real-time data is unavailable.

If both are available consumers can highlight an unscheduled differences in the vehicle for users.

Again, you invent new terms. Don't do that, this is a vehicle_type.

skinkie

Rename vehicle_class to vehicle_type. Incorporate typo fixes.

skinkie · 2026-08-18T09:39:15Z

 |  `continuous_drop_off` | Enum | **Conditionally Forbidden** | Indicates that the rider can alight from the transit vehicle at any point along the vehicle’s travel path as described by [shapes.txt](#shapestxt), on every trip of the route. Valid options are: <br><br>`0` - Continuous stopping drop off. <br>`1` or empty - No continuous stopping drop off. <br>`2` - Must phone agency to arrange continuous stopping drop off. <br>`3` - Must coordinate with driver to arrange continuous stopping drop off. <br><br>Values for `routes.continuous_drop_off` may be overridden by defining values in `stop_times.continuous_drop_off` for specific `stop_time`s along the route. <br><br>**Conditionally Forbidden**:<br>- Any value other than `1` or empty is **Forbidden** if `stop_times.start_pickup_drop_off_window` or `stop_times.end_pickup_drop_off_window` are defined for any trip of this route.<br> - Optional otherwise. |
 | `network_id` | ID | **Conditionally Forbidden** | Identifies a group of routes. Multiple rows in [routes.txt](#routestxt) may have the same `network_id`.<br><br>Conditionally Forbidden:<br>- **Forbidden** if the [route_networks.txt](#route_networkstxt) or [networks.txt](#networkstxt) file exists.<br>- Optional otherwise. 
 |  `cemv_support` | Enum | Optional | Indicates if riders can access a transit service (i.e., trip) associated with this route by using a contactless EMV (Europay, Mastercard, and Visa) card or mobile device as fare media at a fare validator (such as in pay-as-you-go or open-loop systems). This field does not indicate that cEMV can be used to purchase other fare products or to add value to another fare media. <br><br> Support for cEMVs should only be indicated if all services under this route are accessible with the use of cEMV cards or mobile devices as fare media. <br><br> Valid options are: <br><br>`0` or empty - No cEMV information for trips associated with this route. <br>`1` - Riders may use cEMVs as fare media for trips associated with this route. <br>`2` - cEMVs are not supported as fare media for trips associated with this route. <br><br> If both `agency.cemv_support` and `routes.cemv_support` are provided for the same service, the value in `routes.cemv_support` shall take precedence. <br><br> This field is independent of all other fare-related files and may be used separately.  If there is conflicting information between this field and any fare-related file (such as [fare_media.txt](#fare_mediatxt), [fare_products.txt](#fare_productstxt), or [fare_leg_rules.txt](#fare_leg_rulestxt)), the information in those files shall take precedence over `agency.cemv_support`.
+|  `vehicle_class` | ID | Optional | Matches the `vehicle_class` in vehicles.txt to identify the type of vehicle that usually operates on this route. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. If trips.txt has a `vehicle_class`, that value overrides the value in routes.txt. |


Suggested change

| `vehicle_class` | ID | Optional | Matches the `vehicle_class` in vehicles.txt to identify the type of vehicle that usually operates on this route. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. If trips.txt has a `vehicle_class`, that value overrides the value in routes.txt. |

| `vehicle_type` | ID | Optional | Matches the `vehicle_type` in vehicles.txt to identify the type of vehicle that usually operates on this route. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. If trips.txt has a `vehicle_type`, that value overrides the value in routes.txt. |

skinkie · 2026-08-18T09:39:45Z

 |  `cars_allowed` | Enum | Optional | Indicates whether cars are allowed. Valid options are:<br><br>`0` or empty - No car information for the trip.<br>`1` - Vehicle being used on this particular trip can accommodate at least one car.<br>`2` - No cars are allowed on this trip. |
 | `safe_duration_factor` | Float | **Optional** | Multiplier applied to travel time estimates calculated for on-demand trips.<br><br>See "Calculating on-demand trip time estimates with safe duration fields" section below for guidance on how to use this and the `safe_duration_offset` fields. |
 | `safe_duration_offset` | Float | **Optional** | Fixed offset value in seconds applied to travel time estimates calculated for on-demand trips.<br><br>See "Calculating on-demand trip time estimates with safe duration fields" section below for guidance on how to use this and the `safe_duration_factor` fields. |
+|  `vehicle_class` | ID | Optional | Matches the `vehicle_class` in vehicles.txt to identify the type of vehicle that usually operates on this trip. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. This value overrides the value in routes.txt. |


Suggested change

| `vehicle_class` | ID | Optional | Matches the `vehicle_class` in vehicles.txt to identify the type of vehicle that usually operates on this trip. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. This value overrides the value in routes.txt. |

| `vehicle_type` | ID | Optional | Matches the `vehicle_type` in vehicles.txt to identify the type of vehicle that usually operates on this trip. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. This value overrides the value in routes.txt. |

skinkie · 2026-08-18T09:40:11Z


 This calculation should only apply to the portion of a trip that is on-demand. If a service is a deviated-fixed service, or if a rider trip includes a transfer from an on-demand to a fixed-route service, the duration of the fixed-route portion of the trip should be calculated according to the `departure_time` and `arrival_time` fields.

-


Unrelated change.

skinkie · 2026-08-18T09:40:43Z

+|  `vehicle_label_high` | Text | Conditionally Required | If a range of vehicles is represented this is the high end of the range for the vehicle label. The number of characters must be the same as `vehicle_label` and the range covers values with the same number of charactors and are between `vehicle_label` and `vehicle_label_high` when using an ASCII string comparison. Required if both `vehicle_label` and `vehicle_id_high` are included. |
+|  `agency_id` | Foreign ID referencing `agency.agency_id` | Recommended | Agency for the specified vehicles. |
+|  `license_plate` | Text | Optional | The license plate or number plate of the vehicle. Does not apply if a range of vehicles is being used. |
+|  `vehicle_class` | ID | Recommended | Identifies a class of vehicle that usually runs on certain routes. Ment to link with vehicle_class fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. |


Suggested change

| `vehicle_class` | ID | Recommended | Identifies a class of vehicle that usually runs on certain routes. Ment to link with vehicle_class fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. |

| `vehicle_type` | ID | Recommended | Identifies a type of vehicle that usually runs on certain routes. Meant to link with vehicle_type fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. |

skinkie · 2026-08-18T09:44:58Z

Futhermore I am seeking for full alignment with attributes.

gcamp · 2026-08-19T14:04:07Z

+|  Field Name | Type | Presence | Description |
+|  ------ | ------ | ------ | ------ |
+|  `vehicle_id` | Text | **Required** | An id that is unique to the vehicle and corresponds to the value in the GTFS Realtime `id` value in the `VehicleDescriptor` or `CarriageDetails` or the vehicle identifier in other real-time data sources. If `vehicle_id_high` is provided then this value is the low end of the range. |
+|  `vehicle_id_high` | Text | Optional | If a range of vehicles is represented this is the high end of the range. The number of charactors must be the same as `vehicle_id` and the range covers values with the same number of characters and are between `vehicle_id` and `vehicle_id_high` when using an ASCII string comparison. Not all vehicles covered by the range need to actually exist. |


What is the expected behaviour when using UTF-8 strings?

I could remove the "ASCII" so just says "string comparison".

gcamp · 2026-08-19T14:05:13Z

+
+|  Field Name | Type | Presence | Description |
+|  ------ | ------ | ------ | ------ |
+|  `vehicle_id` | Text | **Required** | An id that is unique to the vehicle and corresponds to the value in the GTFS Realtime `id` value in the `VehicleDescriptor` or `CarriageDetails` or the vehicle identifier in other real-time data sources. If `vehicle_id_high` is provided then this value is the low end of the range. |


It's a bit unclear to me what is the goal with CarriageDetails here. There doesn't seem to be a way to specify in the static that a vehicle is going to have multiple carriage, but you can define it in real time?

Trying to see how we could potentially specify carriage label when a train has numbered/lettered carriage like google does here

Tthe GTFS real-time has id and label fields in the CarriageDetails structure and the id is supposed to "be unique per vehicle". That should allow you to find an associated vehicle description for that train car. If the GTFS real-time only has generic letters or numbers then it can't be used for this.

And there's no way to specify multiple carriage in the static GTFS?

You mean to be able to provide the expected vehicle_class/vehicle_type for the carriages where real time data is not available?

Yes, or even if real time is available, you might want to know in advance.

Information on schedule consists is something that could be added to GTFS, but that would beyond the scope of this pull request.

There is a structure for that in TIDES, which is subject to a proposal to significantly revise it.

That's fine that we add this capability later but I think we should make sure we design for it as a possible extension. Right now a vehicle_id can both mean a single carriage (via real time) or a train of multiple carriage which I don't like.

Co-authored-by: Stefan de Konink <stefan@konink.de>

Co-authored-by: Guillaume Campagna <guillaume.campagna@gmail.com>

doconnoronca · 2026-08-23T13:56:54Z

@skinkie vehicle_class is supposed to be more specific than vehicle_type. vehicle_type 3 is bus, but there are many different sizes and configurations of buses, including trolley buses, articulated buses, double decker buses, minibuses, etc. which significantly effect the capacity and features riders expect.

skinkie · 2026-08-23T15:08:30Z

@skinkie vehicle_class is supposed to be more specific than vehicle_type. vehicle_type 3 is bus, but there are many different sizes and configurations of buses, including trolley buses, articulated buses, double decker buses, minibuses, etc. which significantly effect the capacity and features riders expect.

No. route_type = 3 is bus.
vehicle_type is the generic form of an instance of a vehicle.

Again: don't invent terms.

doconnoronca · 2026-08-23T15:36:15Z

No. route_type = 3 is bus. vehicle_type is the generic form of an instance of a vehicle.

Again: don't invent terms.

I'm inventing terms to avoid confusion with existing terms.

skinkie · 2026-08-23T15:47:58Z

This is creating confusion. vehicle_type is the used term for it.

doconnoronca and others added 29 commits July 7, 2024 11:11

Start vehicles

3efa182

Update reference.md

4d4ffec

Update reference.md

411b2fc

Update reference.md

9f5d437

Additional rows

Update reference.md

c6d3306

Update reference.md

53ff269

Update reference.md

61e698a

Update reference.md

9cc2da8

Update reference.md

0ce1ebb

Update reference.md

f14f328

Update reference.md

5cf0039

Update reference.md

b8fdede

Update reference.md

5cd17fe

Merge branch 'master' of https://github.com/TransitApp/transit into v…

97b2b32

…ehicles

Update reference.md

3474dca

Update reference.md

198521d

Update reference.md

b854c87

Update reference.md

4f7a780

Update reference.md

c64ee65

Update reference.md

3e8e288

Update reference.md

75d552f

Update reference.md

0a51f71

Update reference.md

9c62d46

Update reference.md

8f09733

Update reference.md

7012986

Update reference.md

abf84bf

Update reference.md

59daa86

Change to match TIDES vehicles.txt

7725d96

Merge branch 'master' into vehicles

a42af9f

jlstpaul mentioned this pull request Jul 20, 2026

Update handling of vehicles and consists TIDES-transit/TIDES#272

Open

5 tasks

lauriemerrell reviewed Jul 21, 2026

View reviewed changes

gcamp mentioned this pull request Jul 25, 2026

GTFS Carriage Position TransitApp/transit#23

Closed

1 task

jlstpaul mentioned this pull request Jul 26, 2026

How to handle vehicle group attributes TIDES-transit/TIDES#273

Open

gcamp mentioned this pull request Jul 29, 2026

GTFS Carriage Position #650

Open

1 task

skinkie suggested changes Aug 18, 2026

View reviewed changes

gcamp reviewed Aug 19, 2026

View reviewed changes

doconnoronca and others added 2 commits August 23, 2026 09:23

Update gtfs/spec/en/reference.md

754fa32

Co-authored-by: Stefan de Konink <stefan@konink.de>

Update gtfs/spec/en/reference.md

2fce97e

Co-authored-by: Guillaume Campagna <guillaume.campagna@gmail.com>

cursor Bot mentioned this pull request Aug 28, 2026

[gtfs-schedule] Missing 2026 spec fields and incomplete Flex/timeframes fold-in sargunv/mobility-data-kt#70

Open

	\| `vehicle_class` \| ID \| Optional \| Matches the `vehicle_class` in vehicles.txt to identify the type of vehicle that usually operates on this trip. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. This value overrides the value in routes.txt. \|
	\| `vehicle_type` \| ID \| Optional \| Matches the `vehicle_type` in vehicles.txt to identify the type of vehicle that usually operates on this trip. Can be used for information on what type of vehicle to expect when real time data is not available and identify where the vehicle is not the expected type when real time data is available. This value overrides the value in routes.txt. \|


		This calculation should only apply to the portion of a trip that is on-demand. If a service is a deviated-fixed service, or if a rider trip includes a transfer from an on-demand to a fixed-route service, the duration of the fixed-route portion of the trip should be calculated according to the `departure_time` and `arrival_time` fields.

	\| `vehicle_class` \| ID \| Recommended \| Identifies a class of vehicle that usually runs on certain routes. Ment to link with vehicle_class fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. \|
	\| `vehicle_type` \| ID \| Recommended \| Identifies a type of vehicle that usually runs on certain routes. Meant to link with vehicle_type fields in routes.txt and trips.txt. Can be used to provide vehicle information when label isn't available or highlight when the vehicle doesn't match the expected class and what the major differences are. \|

Uh oh!

Conversation

doconnoronca commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Describe the Problem

Use Cases

Proposed Solution

Type of change

Additional Information

Proposed Discussion Period

Testing Details

Proposal Update Tracker

Checklist

Uh oh!

skinkie commented May 11, 2026

Uh oh!

doconnoronca commented Jul 19, 2026

Uh oh!

ttaylor-avail commented Jul 20, 2026

Uh oh!

lauriemerrell commented Jul 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gcamp commented Jul 29, 2026

Uh oh!

manfredbrandl commented Aug 13, 2026

Uh oh!

doconnoronca commented Aug 15, 2026

Uh oh!

skinkie commented Aug 15, 2026

Uh oh!

manfredbrandl commented Aug 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

doconnoronca commented Aug 17, 2026

Uh oh!

manfredbrandl commented Aug 17, 2026

Uh oh!

vikiawv commented Aug 17, 2026

Uh oh!

doconnoronca commented Aug 17, 2026

Uh oh!

manfredbrandl commented Aug 17, 2026

Uh oh!

doconnoronca commented Aug 18, 2026

Uh oh!

skinkie commented Aug 18, 2026

Uh oh!

skinkie left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

skinkie commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

doconnoronca commented May 11, 2026 •

edited

Loading

manfredbrandl commented Aug 15, 2026 •

edited

Loading

skinkie commented Aug 18, 2026 •

edited

Loading