Addition of vehicles.txt to GTFS static

[doconnoronca]

Describe the problem

Real time prediction tools could use additional information to describe what type of vehicle is approaching and its capacity and accessibility features.

Use cases

Real-time data usually includes the vehicle number which could be used to look up more details about the vehicle then it would be practical to include with the real-time data feed. Capacity would be used to indicate how busy a vehicle is if the real-time passenger load is provided. The vehicle type would be useful to indicate when a rail vehicle has been replaced by a bus.

This could also be used for reporting fleet information in a standard format for analyses by other levels of government and the public.

Proposed solution

A new vehicles.txt file in the GTFS static file to describe the capacity, accessibility and features of individual vehicles or vehicle ranges. It would apply to buses, LRT, subway cars, rail cars and even ferries.

Fields could include:

• Id: Corresponds to the id in the VehicleDescriptor in the real-time data. Required and unique
• High_Id: If the vehicle description covers a range of identical vehicles the Id is the lower end of the range and High_Id is the high end. Only the numbers can increment. Any non-numeric characters must not change. Leading zero in the Id are maintained.
• Label: Corresponds to the label in the VehicleDescriptor in the real-time data.
• High_Label: If the vehicle description covers a range of identical vehicles the Label is the lower end of the range and High_Label is the high end. Only the numbers can increment. Any non-numeric characters must not change. Leading zero in the Label are maintained. The range must be the same size as the range covered by the Id and High_Id.
• Vehicle_Type: Could match the values of Route_Type
• Manufacturer
• Model
• Year: Year ordered
• Length_Feet
• Length_Meters
• Articulations
• Number_of_Levels
• Seated_Capacity
• Standing_Capacity
• Wheelchair_Capacity
• Interior_Bicycle_Capacity
• Exterior_Bicycle_Capacity
• Bicycle_Notes: A text description of how bicycles are stored and any limitations that may apply, such as times when they are disallowed. Translatable
• Luggage: Has space for luggage that is larger than carry-on luggage. 1- Luggage rank in the passenger area; 2- Luggage storage under or behind the passenger area (such as a coach bus).
• Luggage_Notes: A text description of how luggage is stored and any limitations that may apply. Translatable
• Restrooms: Number of restrooms in the vehicle
• AirConditioned: 1- Has functioning Air Conditioning
• AC_Plugs: Number of AC power plug that follow the local standard available to passengers
• USB_Plugs: Number of USB type-A ports available for device charging
• WiFi: 1- Internet access through WiFi with no login required; 2- Internet access with free login required; 3- Internet Access with payment or paid membership
• WiFi_Notes: Description of how the access the Internet through WiFi and any limitation it has. Translatable
• Number_of_Doors: If the vehicle has doors on both sides, use the number of doors per side.
• Boarding_Level: 1 - High platform level boarding; 2 - Low platform level boarding; 3- Steps to board; 4- Boarding varies by station
• Boarding_Steps: Number of steps to board
• Accessible_Boarding: If there are steps to board, this shows the vehicle may be accessibly boarder. 0-Not accessible; 1-Level boarding; 2- Ramp can be deployed; 3- Lift can be deployed
• Accessible_Door: Door number at supports accessible boarding, where 1 is the first door in the direction of travel
• Accessibility_Notes: Text information about how to board with a mobility device and any limitations. Translatable
• Next_Stop_Announcement: 1- Audible next stop announcements are made in this vehicle for the vision impaired
• Next_Stop_Display: 1- There are interior displays showing the name of the next stop for the hearing impaired
• Special_Decoration: A brief description of a special wrap or modification of the vehicle either seasonal or long term. Translatable
• Propulsion: 1- Unpowered, moved by another unit; 2- Overhead wire; 3- Third rail electric; 4- Battery electric; 5- Hydrogen; 6- ICE-battery hybrid; 7- Internal combustion engine; 8- Cable pulled; 9- Stream engine!?!?!

Additional information

No response

[gcamp]

Related : #200

[doconnoronca]

I reviewed the GTFS-Vehicles proposal. I added a few things inspired by that. My proposal is close to what @mgilligan and @botanize suggested.

This is a much simpler. It just has a list of vehicles and describes them. I have suggested one row per vehicle. The largest agencies would have thousands of rows, which isn't a lot these days, but I would be open to having ranges of Ids and Labels instead.

It does not add vehicle_category_id, to routes.txt or trips.txt because it is dependant on the real time data to provide the vehicle label. I addition to GTFS real-time, other real time formats like the BusTime and NextBus (Umo) API, also provide the vehicle number. I would be open to a feature so the that an expected vehicle class could be added to routes or trips, for systems that do not support real time data.

[met]

Hi, I like this approach. Will there be any discussion about parameters included in vehicles.txt?

In Prague we would like to have there also:

• boolean property airConditioned (if the vehicle is airconditioned - it is being very impotant in Summer months) and
• boolean property usbChargers (if the vehicle contains USB charges for passengers).

[skinkie]

@met then include regular wall outlets too...

[doconnoronca]

I have added AirConditioned, AC_Plugs and USB_Plugs to the proposal. Is it too soon to add USB type-C plugs.

[doconnoronca]

I have added the ability to have ranges for the id and label (which will make is easier to include before GTFS generators support this), note fields for text description of different features, WiFi information, next stop announcements and displays and special decoration fields to indicate vehicles seasonal wraps, like Pride or Christmas buses.

[e-lo]

vehicle_type being redundant of route_type doesn't make sense to me. I'd want more detail, like at least at the level provided to NTD and used in transit asset management.

[e-lo]

Sometimes instead of year manufactured, you want to know the general quality of the vehicle: is it falling apart and scary (likely in some places) or pristine. The TERM scale used by BTS could be a useful here:

[e-lo]

The APTA Vehicle Inventory DB might also be useful for standardizing some attributes around. For example, there are some useful attributes like "wifi available" and there are a lot more fuel types:

[doconnoronca]

@e-lo The new version I've been working on used the Vehicle Type and Fuel Type from the National Transit Database. I could add the TERM scale, if agencies where willing to publicize it.

[miklcct]

Is fare depending on the vehicle currently supported in GTFS? For example, the fare for a bus route is higher if it is an air conditioned bus.

[miklcct]

vehicle_type being redundant of route_type doesn't make sense to me. I'd want more detail, like at least at the level provided to NTD and used in transit asset management.

Also it can be used to support the case of a bus vehicle used on a tram route as well, like the following when I visited Stockholm in the past: