National Academies Press: OpenBook

Improving Access and Management of Public Transit ITS Data (2022)

Chapter: Chapter 4 - Data Structure

« Previous: Chapter 3 - Roadmap
Page 18
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 18
Page 19
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 19
Page 20
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 20
Page 21
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 21
Page 22
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 22
Page 23
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 23
Page 24
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 24
Page 25
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 25
Page 26
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 26
Page 27
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 27
Page 28
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 28
Page 29
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 29
Page 30
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 30
Page 31
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 31
Page 32
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 32
Page 33
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 33
Page 34
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 34
Page 35
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 35
Page 36
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 36
Page 37
Suggested Citation:"Chapter 4 - Data Structure." National Academies of Sciences, Engineering, and Medicine. 2022. Improving Access and Management of Public Transit ITS Data. Washington, DC: The National Academies Press. doi: 10.17226/26674.
×
Page 37

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

18 C H A P T E R 4 Table 3 lists and describes the proposed data files and indicates whether they are required. The required files are those that are needed to estimate the high-priority KPIs defined in Sec- tion 2.3.1. In addition, if an agency desires to use the Event Data Files to store data on vehicle locations, passenger events, and fare transactions, they would use these files to populate the required files. Therefore, they are designated as conditionally required. If utilizing these Event Data Files, the Devices file is also required. The Station_activities file is listed as conditionally required, as not all transit agencies have stations (or stops) in which ITS data is collected when passengers enter or exit the station, rather than on board a vehicle. Agencies looking to estimate some but not all of the high-priority KPIs may opt to use a smaller subset of the files. Section 5.5 lists the specific files and fields required to estimate each KPI. 4.1 Relationships Between Files Figure 4 shows how these files relate to one another and to the agency’s existing GTFS files. The proposed data structure is relational, with key identifiers that allow users to join data across files. As noted, some transit agencies may opt against using the Event Data Files. In that case, they require only the files shown in Figure 5. The Devices, Train_cars and Vehicle_train_cars files are excluded, as these files are not required to populate the Summary Data Files. Chapter 3 “Roadmaps” described how agencies can choose to develop files containing data aggregated at the stop, visit, and individual train car level, representing an intermediary level of aggregation between the Event Data Files and Summary Data Files. This practice is described in more detail in Chapter 6 on Best Practices. As an agency may use some Event Data Files while not using others, a diagram representing the agency’s own implementation of the data structure may be comprised of elements from both figures. The Event Data Files (green) include one file that corresponds to each input data type (AFC, AVL, APC); however, data may be gathered from different combinations of systems and may require consolidating multiple Vendor Outputs. For example, transit agencies may receive sepa- rate bus and rail AVL outputs or may have multiple APC systems on their buses. The data structure combines data across modes, reducing the number of files, and allowing for easier multi- modal analysis. Section 6.2 outlines best practices for combining data from multiple systems. The Supporting Files (beige) are not core to the data structure because their focus is not on the data that come out of ITS systems. However, they provide supporting information that is useful for analyses. Most agencies already document this information. Agencies or vendors can generate these files following the proposed structure to ensure that they contain the proper identifiers needed to link the files to the data structure. Other groups have proposed various data struc- tures for these kinds of data either as extensions to GTFS (such as the proposed GTFS-Vehicles Data Structure

Data Structure 19   Table 3. Files in data structure. Filename Required Description File Type Vehicle_locations Conditionally required Timestamped vehicle locations and speeds. Event Passenger_events Conditionally required Timestamped passenger-related events, including boardings and alightings. Event Fare_transactions Conditionally required Timestamped fare transaction, associated with devices. Event Stop_visits Required Summarized boarding, alighting, arrival, departure, and other events (kneel engaged, ramp deployed, etc.) by trip and stop for each service date. Summary Trips_performed Required Trips performed for each service date. Summary Station_activities Conditionally required Summarized transactions, entries, and exits by stop or station and time period for each service date (for events not associated with a trip). Summary Devices Conditionally required Measurement devices, such as AVL, APC, and AFC devices, associated with vehicles or stops or stations. Supporting Train_cars Optional Assets that comprise vehicles, such as train cars, with descriptive information. Supporting Vehicle_train_cars Optional Relationships between assets and vehicles. Supporting Vehicles Required Vehicles, including buses and train consists, with descriptive information. Supporting Operators Optional Personnel who operate vehicles. Supporting Figure 4. Data structure and relationships with the event files.

20 Improving Access and Management of Public Transit ITS Data extension) or as independent standards. If an agency prefers, it could use other data formats instead of the proposed Supporting Files to manage the relevant supporting information. In that case, equivalent files would provide the relevant information on vehicles and assets, devices and operators and could be joined to the Event Data Files and Summary Data Files matched on the device_id, vehicle_id, train_car_id, and operator_id fields. 4.2 Files and Fields Table 4 through Table 14 correspond to each of the proposed files and list the field names, data types, field descriptions, and external references (where applicable) for each file. They also indicate whether fields are required. Unique identifiers for each file are in bold. Other required fields are used to link the files or as a basis for aggregation. It is not necessary for the tables to be ordered on their keys or in any other manner. Fields that are equivalent to fields in GTFS are defined as specified in GTFS. When referencing other files, the convention Filename.fieldname is used. 4.2.1 Vehicle_locations File This file contains timestamped vehicle location data at and between stops (Table 4). Each row represents an individual timestamped location ping. 4.2.2 Passenger_events File This file (Table 5) contains each timestamped passenger-related event, including boardings and alightings, ramp deployments, bike rack usage, and kneel engagement. Figure 5. Data structure files and relationships excluding Event Data Files.

Data Structure 21   Field Name Type Required Description External Reference date Date Required Service date. GTFS timestamp POSIX time Required Recorded event time. location_ping_id ID Required Identifies the recorded vehicle location event. trip_id_performed ID referencing Trips_performed.trip_id_performed Required Identifies the trip performed. stop_sequence Positive integer referencing Stop_times.stop_sequence Required Ordered stop the vehicle is approaching or serving on a particular trip. GTFS vehicle_id ID referencing Vehicles.vehicle_id Required Identifies a vehicle. device_id ID references Devices.device_id Conditionally required Identifies the device that recorded the vehicle location. May be null if only a single device is reporting vehicle location and the device_id is not distinct from vehicle_id. stop_id ID referencing Stops.stop_id Optional Identifies the stop the vehicle is approaching or serving currently. GTFS current_status Enum Optional Indicates the status of the vehicle in reference to a stop. Valid options are: 0 - Incoming at. 1 - Stopped at. 2 - In transit to. GTFS-Realtime latitude Float Optional Degrees North, in the WGS-84 coordinate system. GTFS-Realtime longitude Float Optional Degrees East, in the WGS-84 coordinate system. GTFS-Realtime gps_quality Enum Optional Indicates the quality of data and communication provided by the GPS. Valid options are: 0 - Excellent. 1 - Good. 2 - Poor. Table 4. Vehicle_locations file. (continued on next page)

22 Improving Access and Management of Public Transit ITS Data Field Name Type Required Description External Reference bearing Float Optional Bearing, in degrees, clockwise from true north, e.g., 0 would mean north and 90 would mean east. This can be the compass bearing, or the direction towards the next stop or intermediate location. This should not be deduced from the sequence of previous positions, which clients can compute from previous data. GTFS-Realtime speed Float Optional Momentary speed measured by the vehicle, in meters per second. GTFS-Realtime odometer Integer Optional Odometer value, in meters. GTFS-Realtime schedule_deviation Integer Optional Indicates schedule adherence in seconds. A negative value represents an early vehicle. (An unscheduled trip would not have a scheduled deviation.) headway_deviation Integer Optional Indicates headway adherence in seconds. A negative value represents a shorter than scheduled headway. Table 4. (Continued).

Data Structure 23   Field Name Type Required Description External Reference in_service Enum Optional Indicates status of travel regarding service. Valid options are: 0 - The vehicle is in passenger service. 1 - The vehicle is en route to service. 2 - The vehicle is traveling from a service trip. 3 - The vehicle is on a layover. 4 - The vehicle is returning to a garage due to a suspension or breakdown. 5 - Travel for on- route replacement of breakdown. 6 - Other not in service schedule_relationship Enum Optional Indicates the status of the stop. Valid options are: 0 - Scheduled. 1 - Skipped. 2 -Unscheduled. 3 - Canceled. 4 - Duplicated. 5 - Schedule modified. Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Float, short for floating point, is a data type that allows non-integer values. Table 4. (Continued).

24 Improving Access and Management of Public Transit ITS Data Field Name Type Required Description External Reference date Date Required Service date. GTFS timestamp POSIX time Required Recorded event time. passenger_event_id ID Required Identifies the recorded passenger event. trip_id_performed ID referencing Trips_performed.trip_id_performed Required Identifies the trip performed. stop_sequence Positive integer referencing Stop_times.stop_sequence Required Ordered stop the vehicle is serving on a particular trip. GTFS event_type Enum Required Indicates the type of event recorded. Options are: 0 - Vehicle arrived at stop. 1 - Vehicle departed stop. 2 - Door opened. 3 - Door closed. 4 - Passenger boarded. 5 - Passenger alighted. 6 - Kneel was engaged. 7 - Kneel was disengaged. 8 - Ramp was deployed. 9 - Ramp was raised. 10 - Ramp deployment failed. 11 - Lift was deployed. 12 - Lift was raised. 13 - Individual bike boarded. 14 - Individual bike alighted. 15 - Bike rack deployed. vehicle_id ID referencing Vehicles.vehicle_id Required Identifies a vehicle. device_id ID referencing Devices.device_id Conditionally required Identifies the device that recorded the event. May be null if only a single device is reporting passenger events on a vehicle/train car and the device_id is not distinct from vehicle_id/train_car_id. train_car_id ID referencing Train_car.train_car_id Optional Identifies the train car. stop_id ID referencing Stops.stop_id Optional Identifies the stop the vehicle is serving. GTFS Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Table 5. Passenger_events file. 4.2.3 Fare_transactions File This file contains timestamped fare transactions with relevant fare media and amount infor- mation (Table 6). It includes transactions on board vehicles as well as transactions at stops, at stations, and through mobile systems. More information on how to record off-board and mobile payments is included in Best Practices (Section 6.8.3). Records in this file include passengers paying fares, as well as adding value to their fare media or purchasing a pass. Each of these actions constitutes a separate record in the Fare_transactions file. The Fare_transactions file includes several fields to describe the fare category or group, which transit agencies may customize to define categories that are appropriate for their agency. More information on these categories is provided in Best Practices (Section 6.7.2).

Field Name Type Required Description External Reference date Date Required Service date. GTFS timestamp POSIX time Required Recorded event time, including for transactions that may be aggregated values associated with a trip or vehicle. transaction_id ID Required Identifies the fare transaction. amount Currency Required Value of the transaction. currency_type Currency code Required Currency used for the transaction. GTFS fare_action Enum Required Indicates the type of action performed. Valid options are: 0 - Unknown action type. 1 - Purchase. 2 - Enter (enter fare-controlled area or vehicle). 3 - Exit (exit fare-controlled area or vehicle). 4 - Transfer entrance. 5 - Transfer exit. 6 - Add (add stored value). 7 - Activate (activate a fare pass). 8 - Adjust (adjustment initiated by system or customer support). 9 - Other. trip_id_performed ID referencing Trips_performed.trip_id_performed Conditionally required Identifies the trip performed. May be null if the fare collection device is NOT located on a vehicle. May be null if on a vehicle but trip-level data is unavailable, in which case the data would be associated with the vehicle. stop_sequence Positive integer referencing Stop_times.stop_sequence Conditionally required Ordered stop the vehicle is serving on a particular trip. May be null if the fare collection device is NOT located on a vehicle. May be null if on a vehicle but stop-level data is unavailable, in which case the data would be associated with the vehicle and/or trip. GTFS vehicle_id ID referencing Vehicles.vehicle_id Conditionally required Identifies the vehicle. May be null if collection device is NOT located on a vehicle. May be null if on a vehicle but vehicle data is unavailable, in which case the data would be associated with a trip and/or stop. device_id ID referencing Devices.device_id Conditionally required Identifies the ITS device on which the fare transaction was performed. May be null if only a single device is reporting fare transactions on a vehicle and vehicle_id is provided. May be null if only a single device is reporting fare transactions at a stop and stop_id is provided. fare_id ID referencing Fare_attributes.fare_id Optional Identifies a fare class, as included in the GTFS Fare_attributes file. GTFS stop_id ID referencing Stops.stop_id Optional Identifies the stop. GTFS group_size Positive integer Optional The number of customers included in the transaction. Table 6. Fare_transactions file. (continued on next page)

Field Name Type Required Description External Reference media_type Enum Optional Indicates the fare medium that was used for the transaction. Valid options are: 0 - Cash or coins. 1 - Smart card or ticket. 2 - Magnetic-stripe card or ticket. 3 - Bank card (credit or debit card). 4 - Mobile NFC (smartphone tap, etc.). 5 - Optical scan (of mobile app screen or paper ticket). 6 - Button pressed by driver or operator to indicate a boarding or alighting passenger. 7 - Other type. rider_category Text Optional Indicates rider category (categories defined by transit agency). For example: • Adult. • Youth. • Student. • Senior. • Other reduced. fare_product Text Optional Indicates the fare group (fare groups defined by transit agency). For example: • Single ride. • Pass. • Employer sponsored. • Other pass. fare_period Text Optional Indicates the fare period (fare periods defined by transit agency). For example: • All day. • Peak. • Off-peak. • Summer. • Other. fare_capped Enum Optional Indicates if fare capping is in effect (fare capping options defined by transit agency). Valid options are: 0 - Fare is not capped. 1 - Fare is capped. fare_media_id ID Optional Identifies the individual fare medium used for the transaction. For example, the fare card ID. fare_media_id_purcha sed ID Optional Identifies the individual fare medium purchased in the transaction. For example, the fare card ID. balance Float Optional Stored value remaining on an account after the transaction is made. Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Float, short for floating point, is a data type that allows non-integer values. Table 6. (Continued).

Data Structure 27   4.2.4 Stop_visits File This file contains a record for each stop for each trip and service date. It includes all the data needed to generate the KPIs at a stop visit level. This is distinct from the Station_activities file, as each record in this file is associated with a stop and trip, whereas the stop, or “station,” activities in the Station_activities file are not associated with a trip. This file is linked to the Event Data Files through the stop_sequence, trip_id_performed, and vehicle_id fields. There are two optional sets of fields that represent transaction revenue and transaction counts by fare medium. In Table 7, transaction_revenue_x and transaction_count_x, each represent eight distinct fields recording transaction revenue and transaction counts for eight potential types of fare media. 4.2.5 Station_activities File This file contains data that is associated with a specific stop or station grouped by time period for each service date. These time periods should be defined by each transit agency and may overlap. Notably, some agencies may choose to allocate data from the Station_activities file to trips using in-house or third-party inference tools. Inferred data could then be added to the Stop_visits file. Data is included in this file when it is collected by a fare device that is located at the entrance to a stop or station (e.g., subway station) that provides access to multiple platforms making it unclear which trip the data is associated with. The Station_activities file is linked directly to the Fare_transactions data file through the stop_id field. Like Stop_visits, the Station_activities file includes two optional sets of fields that represent transaction revenue and transaction counts by fare medium. In Table 8, transaction_revenue_x and transaction_count_x, each represents eight distinct fields recording transaction revenue and transaction counts for eight potential types of fare media. 4.2.6 Trips_performed File This file contains a record for each trip for each service date, including both scheduled and unscheduled trips as well as in service and not in service trips. This file contains data required to generate KPIs at the trip level (Table 9). It is linked to the Stop_visits file through the trip_ id_performed field, linked to the Vehicles file through the vehicle_id field, and linked to the Operators file through the operator_id field. 4.2.7 Devices File This file contains information pertaining to the AVL, APC, and AFC devices. Each device has a unique device_id (Table 10). On-board devices are associated with a vehicle_id and stationary devices are associated with a stop_id. This file is linked to the Event Data Files, which records individual timestamped records that are obtained by individual devices. If only Summary Data Files are used, the Devices file is not required. 4.2.8 Vehicles File This file contains information on vehicles, which are associated with trips through the vehicle_id field in the Trips_performed file (Table 11). Since vehicles that consist of multiple train cars may change over time, each vehicle_id is associated with a start time and an end time, if applicable.

Field Name Type Required Description External Reference date Date Required Service date. GTFS trip_id_performed ID referencing Trips_performed.trip_id_performed Required Identifies the trip performed. stop_sequence Positive integer referencing Stop_times.stop_sequence Required Ordered stop the vehicle is serving on a particular trip. GTFS vehicle_id ID referencing Vehicles.vehicle_id Required Identifies the vehicle. dwell Integer Optional Indicates the amount of time a vehicle spent stopped at a stop in seconds. stop_id ID referencing Stops.stop_id Optional Identifies the stop. GTFS checkpoint Enum Optional Indicates of the stop should be used for evaluating schedule adherence, on-time performance, and other KPIs. This could be populated to match the GTFS “timepoint” field. Valid options are: 0 - Stop is not used in evaluating KPIs. 1 or empty - Stop is used in evaluating KPIs. schedule_arrival_time POSIX time Optional Scheduled time at which the vehicle arrives at a stop. GTFS schedule_departure_time POSIX time Optional Scheduled time at which the vehicle departs from a stop. GTFS actual_arrival_time POSIX time Optional Time at which the vehicle arrives at a stop. actual_departure_time POSIX time Optional Time at which the vehicle departs from a stop. distance Integer Optional Observed distance in meters from the previous stop traveled by the vehicle. boarding_1 Integer Optional Number of riders that entered the front-most or right-most door of the vehicle. alighting_1 Integer Optional Number of riders that exited the front-most or right-most door of the vehicle. boarding_2 Integer Optional Number of riders that entered the rest of the vehicle’s doors. alighting_2 Integer Optional Number of riders that exited the rest of the vehicle’s doors. load Integer Optional Number of riders on the vehicle when departing the stop. door_open POSIX time Optional Time at which the doors opened. door_close POSIX time Optional Time at which the doors closed. door_status Text Optional Indicates actions of the doors during the stop visit. For example: • Doors did not open. • Front door opened and back doors remain closed. • Back doors opened and front door remained closed. • All doors opened. • Other configuration. ramp_deployed_time Float Optional Duration of time a ramp is deployed, in seconds. ramp_failure Enum Optional Indicates if the ramp deployment failed at a stop. Valid options are: 0 - Ramp deployment successful. 1 - Ramp deployment failed. kneel_deployed_time Float Optional Duration of time a kneel is deployed in seconds. lift_deployed_time Float Optional Duration of time in seconds of time a lift is deployed. Table 7. Stop_visits file.

bike_rack_deployed Enum Optional Indicates if the bike rack was deployed at a stop. Valid options are: 0 - Bike rack was not deployed. 1 - Bike rack was deployed. bike_load Integer Optional Number of bikes on the vehicle when departing the stop. revenue Currency Optional Amount of revenue collected at the stop. number_of_transactions Non-negative integer Optional Number of fare transactions that occurred at a stop. transaction_revenue_x Currency Optional Indicates the revenue from a specified fare medium. For example, cash revenue would be represented by the field name transaction_revenue_0. Valid values for x are: 0 - Cash or coins. 1 - Smart card or ticket. 2 - Magnetic-stripe card or ticket. 3 - Bank card (credit or debit card). 4 - Mobile NFC (smartphone tap, etc.). 5 - Optical scan (of mobile app screen or paper ticket). 6 - Button pressed by driver or operator to indicate a boarding or alighting passenger. 7 - Other type. transaction_count_x Non-negative integer Optional Number of fare transactions made by a specified fare medium. For example, the count of cash transactions would be represented by the field name transaction_count_0. Valid values for x are: 0 - Cash or coins. 1 - Smart card or ticket. 2 - Magnetic-stripe card or ticket. 3 - Bank card (credit or debit card). 4 - Mobile NFC (smartphone tap, etc.). 5 - Optical scan (of mobile app screen or paper ticket). 6 - Button pressed by driver or operator to indicate a boarding or alighting passenger. 7 - Other type. schedule_relationship Enum Optional Indicates the status of stop’s service on the trip. Valid options are: 0 - Scheduled. 1 - Skipped. 2 - Missing data. 3 - Unscheduled. 4 - Canceled. 5 - Duplicated. 6 - Schedule modified. (Note: schedule_arrival_time and schedule_departure_time may differ from GTFS in this case.) Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Float, short for floating point, is a data type that allows non-integer values.

Field Name Type Required Description External Reference date Date Required Service date stop_id ID referencing Stops.stop_id Required Identifies stop. GTFS time_period_start POSIX time Required Aggregation period start time. time_period_end POSIX time Required Aggregation period end time. time_period_category Text Optional Indicates a standard time period to aid further aggregation. For example: • All day • Peak • Off-peak • Summer • Other total_entries Non-negative integer Optional Number of events at the stop considered entries, such as boardings or fare transactions. total_exits Non-negative integer Optional Number of events at the stop considered exits, such as alightings. number_of_transactions Non-negative integer Optional Number of fare transactions that occurred at a stop. transaction_revenue_x Currency Optional Indicates the revenue from a specified fare medium. For example, cash revenue would be represented by the field name transaction_revenue_0. Valid values for x are: 0 - Cash or coins. 1 - Smart card or ticket. 2 - Magnetic-stripe card or ticket. 3 - Bank card (credit or debit card). 4 - Mobile NFC (smartphone tap, etc.). 5 - Optical scan (of mobile app screen or paper ticket). 6 - Button pressed by driver or operator to indicate a boarding or alighting passenger. 7 - Other type. Number of fare transactions made by a distinct fare_media_type. Valid values for x are: 0 - Cash or coins. 1 - Smart card or ticket. 2 - Magnetic-stripe card or ticket. 3 - 4 - Mobile NFC (smartphone tap, etc.). 5 - Optical scan (of mobile app screen or paper ticket). 6 - Button pressed by driver or operator to indicate a boarding or alighting passenger. 7 - Other type. bike_entries Non-negative integer Optional Number of bikes that entered the stop. bike_exits Non-negative integer Optional Number of bikes that exited the stop. ramp_entries Non-negative integer Optional Number of entries that used a ramp or accessible entrance. ramp_exits Non-negative integer Optional Number of exits that used a ramp or accessible exit. Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). transaction_count_x Non-negative integer Optional Bank card (credit or debit card). Table 8. Station_activities file.

Field Name Type Required Description External Reference date Date Required Service date. GTFS trip_id_performed ID Required Identifies the trip performed. vehicle_id ID referencing Vehicles.vehicle_id Required Identifies the vehicle. trip_id_scheduled ID referencing Trips.trip_id in GTFS Optional Identifies the scheduled trip associated with the trip performed. One scheduled trip may be associated with multiple operated trips, or an operated trip may not be associated with a scheduled trip. GTFS route_id ID referencing Routes.route_id Optional Identifies the route. GTFS route_type Enum Optional Indicates the type of transportation used on a route. Valid options are: 0 - Tram, Streetcar, Light rail. Any light rail or street-level system within a metropolitan area. 1 - Subway, Metro. Any underground rail system within a metropolitan area. 2 - Rail. Used for intercity or long-distance travel. 3 - Bus. Used for short- and long-distance bus routes. 4 - Ferry. Used for short- and long-distance boat service. 5 - Cable tram. Used for street-level rail cars where the cable runs beneath the vehicle, e.g., cable car in San Francisco. 6 - Aerial lift, suspended cable car (e.g., gondola lift, aerial tramway). Cable transport where cabins, cars, gondolas, or open chairs are suspended by means of one or more cables. 7 - Funicular. Any rail system designed for steep inclines.* 11 - Trolleybus. Electric buses that draw power from overhead wires using poles. GTFS 12 - Monorail. Railway in which the track consists of a single rail or a beam. pattern_id ID referencing proposed Trips.pattern_id in GTFS Optional Identifies the exact service and path on the route. GTFS shape_id ID referencing Shapes.shape_id Optional Identifies a geospatial shape that describes the vehicle travel path for a trip. GTFS direction_id Enum Optional Indicates the direction of travel for a trip. Valid options are: 0 - Travel in one direction (e.g., outbound travel). 1 - Travel in the opposite direction (e.g., inbound travel). GTFS Table 9. Trips_performed file. (continued on next page)

Field Name Type Required Description External Reference operator_id ID referencing Operators.operator_id Optional Identifies the vehicle’s operator. block_id ID Optional Identifies the block to which the trip belongs. A block consists of a single trip, or many sequential trips made using the same vehicle, defined by shared service days and block_id. A block_id can have trips with different service days, making distinct blocks. See example in GTFS documentation. GTFS trip_start_stop_id ID referencing Stops.stop_id Optional Origin stop_id. trip_end_stop_id ID referencing Stops.stop_id Optional Destination stop_id. schedule_trip_start POSIX time Optional Scheduled departure time from the trip’s origin. schedule_trip_end POSIX time optional Scheduled end time at the trip’s destination. actual_trip_start POSIX time optional Time at which the vehicle departed its origin. actual_trip_end POSIX time optional Time at which the vehicle arrived at its destination. in_service Enum Optional Indicates status of travel with regard to service. Valid options are: 0 - The vehicle is in passenger service. 1 - The vehicle is en route to service. 2 - The vehicle is traveling from a service trip. 3 - The vehicle is on a layover. 4 - The vehicle is returning to a garage due to a suspension or breakdown. 5 - Travel for on-route replacement of breakdown. 6 - Other not in service. schedule_relationship Enum Optional Indicates the status of the trip. Valid options are: 0 - Scheduled. 1 - Skipped. 2 - Missing data. 3 - Unscheduled. 4 - Canceled. 5 - Duplicated. 6 - Schedule modified. Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. *Values 8 through 10 are deliberately omitted from this definition, as these mode-value definitions are from the existing GTFS standard, which omits values 8 through 10. Table 9. (Continued).

Field Name Type Required Description External Reference device_id ID Required Identifies a device. If possible, this should match other internal agency device IDs. stop_id ID referencing Stops.stop_id Conditionally required Identifies the stop at which the device is located. May be null if the device is on a vehicle. GTFS vehicle_id ID referencing Vehicles.vehicle_id Conditionally required Identifies the vehicle on which the device is located. May be null if the device is at a stop or station. train_car_id ID referencing Train_car.train_car_id Conditionally required Identifies the train car or asset on which the device is located. May be null if the device is at a stop or station or if the Train_cars file is not used. device_type Enum Optional Indicates the type of device. Valid options are: 0 - APC. 1 - AFC. 2 - AVL. 3 - Other. device_vendor Text Optional Vendor of the device. device_model Text Optional Model of the device as specified by the vendor. location Text Optional Indicates the location of a device on the vehicle or at a station. For example: • Front door. • Back door. • Entrance (not located on a vehicle). • Exit (not located on a vehicle). • Entrance/exit (not located on a vehicle). Other. Note: Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Table 10. Devices file.

Field Name Type Required Description External Reference vehicle_id ID Required Identifies a vehicle, such as a bus or a train consist. If possible, this should match other internal agency vehicle IDs and the GTFS- Realtime vehicle_start POSIX time Conditionally required The time at which the vehicle or train consist is first in operation (i.e., when the consist has been created). Required if Train_car is used. vehicle_end POSIX time Optional The time at which the vehicle or train consist no longer exists (i.e., the consist is separated or modified). Only used if Train_car is used. model_name Text Optional Describes the vehicle’s model. vehicle descriptor. facility_name Text Optional Name or internal agency ID for the facility where the vehicle is generally held. capacity_seated Non-negative integer Optional Number of seats on the vehicle. Used if Train_car is not used. wheelchair_capacity Non-negative integer Optional Number of wheelchair spaces on the vehicle. Used if Train_car is not used. capacity_bike Non-negative integer Optional Number of bike spaces on the vehicle. Used if Train_car is not used. bike_rack Enum Optional Indicates if the vehicle has a useable bike rack. Used if Train_car is not used. Valid options are: 0 - Vehicle has a useable bike rack. 1 - Vehicle does not have a useable bike rack. capacity_standing non-negative integer optional Standing capacity of the vehicle set by the manufacturer. Used if Train_car is not used. Note: POSIX time is the number of seconds since January 1st, 1970 at 00:00:00 Coordinated Universal Time (UTC). Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Table 11. Vehicles file.

Data Structure 35   4.2.9 Train_cars File This optional file contains information pertaining to individual assets within a vehicle, such as an individual subway car within a train consist (Table 12). It is used only when an agency uses vehicles that are comprised of multiple assets. Agencies that use only single-asset vehicles (most typically buses) should not use this file. 4.2.10 Vehicle_train_cars File This optional file contains information to match individual assets (train cars) to vehicles (train consists). This file should only be used by agencies that operate multi-asset vehicles (typi- cally multi-car trains) and are using the Train_car file. Each row in this file represents a train car and multiple train cars are expected to be associated with a single vehicle (Table 13). A single train_car_id may be associated with multiple vehicle_ids, even with overlapping start and end times in the Vehicles file. This could happen in cases where vehicles frequently enter and leave service (i.e., two vehicle_ids are used to represent different directions of travel for a subway train with a specified car order). 4.2.11 Operators File This optional file contains a list of agency staff or contractors that operate vehicles that may be used when generating operator-specific KPIs. It can be linked to the Trips_performed file using the operator_id field. Agencies may add other relevant fields they use to generate KPIs (Table 14).

Field Name Type Required Description External Reference train_car_id ID Required Identifies a train car or asset. If possible, this should match other internal agency asset IDs. model_name Text Optional Describes the train car or asset’s model. facility_name Text Optional Name or internal agency ID for the facility where the train car or asset is generally held. capacity_seated Non-negative integer Optional Number of seats on the train car or asset. wheelchair_capacity Non-negative integer Optional Number of wheelchair spaces on the train car or asset. bike_capacity Non-negative integer Optional Number of bike spaces on the train car or asset. bike_rack Enum Optional Indicates if the train car or asset has a useable bike rack. Valid options are: 0 - Asset has a useable bike rack. 1 - Asset does not have a useable bike rack. capacity_standing Non-negative integer Optional Standing capacity of the train car or asset set by the manufacturer. train_car_type Enum Optional Indicates the type of train car or asset. Valid options are: 0 - Train car. 1 - Trolley. 2 - Other. Note: Enum, short for enumerated, is a specific data type that allows for a variable set to predetermined constants. Table 12. Train_cars file.

Field Name Type Required Description External Reference vehicle_id ID referencing Vehicles.vehicle_id Required Identifies a vehicle, such as a train consist. If possible, this should match other internal agency vehicle IDs. train_car_id ID referencing Train_car.train_car_id Required Identifies a train car or an asset that is a component of the vehicle. order Non-negative integer Optional The assigned order of the train car or asset within the vehicle. Table 13. Vehicle_train_cars file. Field Name Type Required Description External Reference operator_id ID Required Identifies an operator. If possible, this should match other internal agency operator IDs. Table 14. Operators.

Next: Chapter 5 - Tool Requirements »
Improving Access and Management of Public Transit ITS Data Get This Book
×
 Improving Access and Management of Public Transit ITS Data
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

With the proliferation of automatic vehicle location, automatic passenger counters, and automatic fare collection, transit agencies are collecting increasingly granular data on service performance, ridership, customer behavior, and financial recovery.

The TRB Transit Cooperative Research Program's TCRP Research Report 235: Improving Access and Management of Public Transit ITS Data proposes a data structure for storing data from bus and rail intelligent transportation systems (ITS).

Supplemental to the report are an Overview Presentation, a “How To” Presentation, and an Executive 2-pager on the benefits of the proposed data structure.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!