Module 14 Part 1: Applying General Transit Feed Specification (GTFS) to Your Agency
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
Module 14 Part 1: Applying General Transit Feed Specification (GTFS) to Your Agency
Table of Contents
Module Description - 2
Introduction/Purpose - 2
Samples/Examples - 2
Case Studies - 8
Glossary - 9
References - 10
Study Questions - 10
Icon Guide - 11
1. Module Description
Module 14 Part 1 covers static GTFS data such as, schedule, bus stops, station and terminus information, and general fare policy data commonly utilized by transit agencies. Module 14-Part 1 provides an overview of GTFS and training about the structure and content of GTFS. Transit agency staff and their consultants will learn about how they can begin deploying the GTFS specification. The module will discuss the data content, data management, tools to implement the specification, and several case studies of agencies that generate and use the data specification. Additionally, the module will discuss how GTFS feeds can be used by third party developers, planners, and other users.
The General Transit Feed Specification (GTFS) defines a common format for public transportation schedules and associated geographic information that is "open," available, and widely adopted by transit agencies. GTFS "feeds" allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way. GTFS is also a key component of a Traveler Information System (TIS). Module 14-Part 1 covers static GTFS data: schedule, stop, station and terminus information, and general fare policy data commonly utilized by transit agencies. Module 14-Part 1 provides an overview of GFTS and training about the structure and content of GTFS.
3.1. Procurement Language
As a follow-up to the discussion of procurement language in Learning Objective #4, samples of procurement language are shown here. These are functional requirements, which would be developed as part of a systems engineering process. They are grouped into scenarios where they might be included. This is not an exhaustive list of all possible procurement language. In order to minimize conflict with the procurement policies and procedures of specific agencies, the procurement language examples shown are hypothetical and not taken from an actual procurement.
3.1.1. Scenario 1: Scheduling Software Export
These procurement requirements describe a scenario where an agency is seeking the ability to procure a scheduling system that has the capability of exporting GTFS feeds.
- The system shall export GTFS feeds which at minimum includes the following files: agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt, calendar.txt, calendar_dates.txt, shapes.txt, fare_attributes.txt, and fare_rules.txt.
- The system shall only export GTFS feeds which conform to the requirements of the GTFS specification.
- The system shall verify that the GTFS feed conforms to the requirements of the GTFS specification prior to finalizing export.
- The system shall only export GTFS feed which is accurate and matches the data contained in the scheduling software.
3.1.2. Scenario 2: Consultant Responsible for GTFS Production
This scenario describes the procurement of services where a consultant is responsible for producing GTFS for an agency.
- The consultant shall update the agency's GTFS quarterly as the agency's schedule changes.
- The consultant shall provide the following GTFS files: agency.txt, stops.txt, routes.txt, trips.txt, stop_times.txt, calendar.txt, calendar_dates.txt, shapes.txt, fare_attributes.txt, fare_rules.txt, and feed_info.txt
- The consultant shall perform quality control testing to ensure that 1) the GTFS feed conforms to the requirements of the GTFS specification and 2) the GTFS feed accurately shows the agency's schedule and other data.
- The consultant shall provide documentation of all testing performed.
- The consultant shall provide the GTFS feed within 2 weeks of being provided the agency's service schedule.
3.1.3. Scenario 3: Procuring Software to Create GTFS (not part of scheduling system)
This scenario describes the procurement of software to produce GTFS. This is not part of a scheduling system, and would require a user (presumably at the agency) to perform manual data entry to create GTFS.
- The software shall allow the user to select the locations of each stop and to enter optional fields required in stops.txt.
- The software shall allow the user to create patterns for each route.
- The software shall allow the user to create shapes for each pattern.
- The software shall allow the user to input stop times for each pattern in a timetable format.
- The software shall allow the user to specify the service calendar and exceptions to the service calendar.
- The software shall allow the user to input agency contact information.
- The software shall only export GTFS which meets the requirements of the GTFS specification.
- The software shall verify that the requirements of the GTFS specification are met prior to finalizing export.
- The software shall provide a mechanism for a user to verify the accuracy of data which has been manually input.
3.1.4. Scenario 4: Extensions
This scenario describes procurement of software that can produce an extension to GTFS. An example of this extension is shown in section 3.4 of the student supplement.
- The software shall collect parking information from an agency's parking lot database.
The software shall export a custom GTFS file called "parking.txt" which includes the following fields:
- Lot_id: required, identifier for the lot
- Stop_id: required, stop_id (from stops.txt) that the lot is closest to
- Open_time: optional, the time the lot opens
- Close_time: optional, the time the lot closes
- Parking_cost: optional, the cost to park in the lot
- Spaces_available: optional, the number of parking spaces the lot has available
- Lot_description: optional, Notes about the parking lot
- The software shall integrate parking.txt with the rest of the agency's GTFS files.
- The software shall only export a GTFS file that has been verified to conform to the requirements of the GTFS specification and the parking.txt extension
- The software shall include the ability to verify that the requirements of the GTFS specification and parking.txt are met.
3.2. GTFS FeedValidator Warnings and Errors
The official list of warnings and errors for GTFS can be found at: https://github.com/google/transitfeed/wiki/FeedValidatorErrorsAndWarnings
3.3. Google's Open source Tools for GTFS
- FeedValidator (includes instructions): https://github.com/google/transitfeed/wiki/FeedValidator
- Schedule_Viewer (includes instructions): https://github.com/google/transitfeed/wiki/ScheduleViewer
3.4. Example of Extending the GTFS specification
The following is an example of an extension to the GTFS specification. This file is parking.txt which describes non real time parking information for the transit stops described in a GTFS feed. The meanings of the field are described in the sample procurement language in Section 3.1.4 of this student supplement.
lot_id,stop_id,open_time,close_time,parking_cost,spaces_available,lot_description 1,232,05:00:00,21:00:00,6.00,172,"Parking from 5AM until 11 PM at Main St. Stop" 2,142,,,9.00,530,"Parking 24/7"
3.5. Selected Graphics from the Presentation
Slide 11: Map of GTFS Coverage
This graphic shows which countries in the world have agencies with GTFS feeds. Note that countries with dark colors have GTFS feeds, whereas countries that are lightly colored do not have GTFS feeds. Note there may be transit operators within a shaded country that do not have GTFS feeds.
(Extended Text Description: This figure contains a graphic showing a map of the world. A portion of countries are shaded dark, indicating the existence of GTFS feeds within them. A portion of countries are shaded lightly, indicating the absences of GTFS feeds within them. The following countries are shaded dark and visibly labeled: Canada, United States, Mexico, Venezuela, Peru, Brazil, Chile, Argentina, United Kingdom, Norway, Sweden, Finland, Spain, France, Germany, Poland, Ukraine, Algeria, Turkey, Egypt, Kenya, Nigeria, South Africa, Russia, China, India, Japan, Indonesia, and Australia. Additional countries are shaded dark but unlabeled. The following countries are shaded lightly and visibly labeled: Bolivia, Iceland, Mali, Niger, Libya, Chad, Sudan, Ethiopia, DR Congo, Tanzania, Angola, Namibia, Botswana, Madagascar, Iraq, Iran, Afghanistan, Pakistan, Saudi Arabia, Kazakhstan, Mongolia, Thailand, South Korea, and Papua New Guinea.)
Source: Google Maps
Slide 50: GTFS Shape on a Satellite Map
This graphic shows a shape derived from the shapes.txt GTFS file transposed onto a satellite view of a region.
Source: Ulster County Area Transit /Google Earth
Slide 58: National Rural Transit Assistance Program (RTAP) GTFS Builder
This graphic shows a screenshot of the Excel-based National RTAP GTFS Builder tool.
(Extended Text Description: This figure shows a screenshot of the National RTAP GTFS Builder tool. The screen shown contains a spreadsheet. Five columns are visible. The table contains the following data:
|Shelton to Olympia|
|Wallace Kneeland||Civic Center||Red apple - Cascade & Olympic Hwy So||Cole Road P & R @ Hwy 3||Kamilche Transit Center|
|5:45 AM||5:50 AM||5:55 AM||6:00 AM||6:10 AM|
|6:15 AM||6:20 AM||6:25 AM||6:30 AM||6:40 AM|
|8:10 AM||8:15 AM||8:20 AM||6:30 AM|
|10:35 AM||10:40 AM||10:45 AM||10:55 AM|
|12:00 PM||12:05 PM||12:10 PM||12:20 PM|
|2:40 PM||2:45 PM||2:50 PM||3:00 PM|
|3:40 PM||3:45 PM||3:50 PM||4:00 PM|
|4:40 PM||4:45 PM||4:50 PM||5:00 PM|
|5:40 PM||5:45 PM||5:50 PM||6:00 PM|
|6:45 PM||6:50 PM||6:55 PM||7:05 PM|
Source: National RTAP Center / U.S. DOT
Slide 68: Google GTFS Feed Validator Errors
This graphic shows Google's GTFS Feed Validator tool, which is displaying a sample errors found in a feed.
(Extended Text Description: This slide contains a graphic which is a screenshot of the Google GTFS Feed Validator Tool. Much of the graphic is text. The top line says Errors:. Below that is a bolded line that says Invalid Value. Below that is a bullet with text that reads Invalid value 17:38:00 in field departure time. The next line reads, The departure time at this stop (17:38:00) is before the arrival time (21:38:00). The next line reads This is often caused by problems in the feed exporter's time conversion. The next line reads in line 128 of stop_times.txt. Below the text is a series of ten boxes. All boxes are yellow with black text except for the third box which is red with white text. Text in each box reads from left to right: trip_id 9157, arrival_time 21:39:00, departure_time 17:38:00, stop_id 92688, stop_sequence 2, stop_headsign None, pickup_type None, drop_off_type None, shape_dist_traveled None, timepoint None.)
Source: Google GTFS Feed Validator
Slide 69: Google GTFS Feed Validator Warnings
This graphic shows Google's GTFS Feed Validator tool, which is displaying a warning found in a feed.
(Extended Text Description: This slide contains a graphic showing a screenshot warning produced by the GTFS Feed Validator Tool. The screenshot is entirely text based. There is a bullet with test that reads High speed travel detected in trip [@1.0.196144@][1418156335479/5__7D&E-3_(WD,_SAT,_SUM): Madison Street to Madison Street. 2158 meters in 0 seconds.)
Source: Google GTFS Feed Validator
Slide 70: GTFS Schedule Viewer Tool
This graphic shows the Google GTFS Schedule Viewer tool, which is used to view GTFS feeds in a graphical form and is a tool to help verify the accuracy of feeds.
(Extended Text Description: This slide contains a graphic which is a screenshot of the GTFS Schedule Viewer Tool. At the very top of the screen is a bar which states CDTA towards the left. The central part of the screenshot consists of a map of the Albany, NY region. We see a black line traveling along a series of roadways representing a transit trip. For the duration of this line are a series of yellow place markers with labels to the right, representing each stop on the trip and the associated times. To the left of the map is an interactive menu that allows users of the tool to select the trip. There is a form field for time, with 8:00 filled in. Below that is a blank form field for date and a button that a user can press to see a pop up calendar. Below that is a blank form field with a label Find Station and a search button below it. Below that is a blank form field with a label Find Trip ID and a search button below it. Below that is a list of routes on the system. The first route, 1 Central Avenue is selected and highlighted in blue. A menu is expanded blow that with a light blue background. The top of the menu has a label ALBANY BUS TERMINAL TO WOLF RD & COLONIE CENTER. 32 stops. 215 trips. Below that is a list of start times for three trips all reading 8:05, 8:05, and 8:0) respectively. The first 8:05 trip is selected and therefore highlighted in a dark blue background. Below this pattern is a second pattern with a label WOLF RD & COLONIE CENTER TO MADISON AVE & GREEN ST. 39 stops. 220 trips. Times for trips are listed as 8:00, 8:00, and 8:15. None of them are highlighted. Below this is a list of remaining routes contained within the GTFS feed. Below the menu and map is a bar with two lines of text providing information about the selected trip. The first line reads trips.txt route_id=1-155 direction_id=1 trip_headsign=West shape_id=10278 service_id=JAN16-Albany-Weekday-01 trip_id=3552625- JAN16-Albany-Weekday-01. The second line reads routes.txt route_long_name=Central Avenue route_type=3 route_text_color=FFFFFF route_color=123573 agency_id=1 route_id=1-155 route_url=http://www.cdta.org/. Below the label is a graph with time represented by the horizontal access and distance from the origin represented along the vertical access. A series of green lines shows the progression of each trip on the selected pattern throughout the day.)
Source: Google GTFS Schedule Viewer
4. Case Studies
4.1. Additional Case Study- NYSDOT
The New York State Department of Transportation, also known as NYSDOT, maintains a statewide transit trip planner. The state has approximately 100 transit agencies. For more than five years, electronic transit schedules, in both GTFS and a custom format developed by the state, have been collected and used in the 511NY Transit Trip Planner. For many years, NYSDOT has also maintained a software system that allows the manual entry of transit schedules to be included in the transit trip planner.
In 2014, NYSDOT procured a new software system which explicitly allows transit agencies to produce GTFS that can be loaded into their transit trip planner. This opens the door for agencies that do not have the resources to purchase a tool to export GTFS to still be able to provide it. The open source tool procured is GTFS Editor.
In 2015, NYSDOT sought the services of a consultant to create GTFS for transit agencies that do not have the staff resources to create their own GTFS. Approximately 60 agencies fall into this category.
The consultant is responsible for collecting schedules and other data from all of these agencies and manually entering it into the 511NY system.
As this effort has gotten underway, some challenges have appeared. One is that the information provided by agencies is not consistent. For example, while some agencies have detailed stop locations, others may refer to a local business, that must be researched to find the location. Often these businesses have closed. A second challenge is that timetables are often inconsistently formatted. This requires that a judgment to be made by the analyst inputting the data on how to represent a trip. Finally, detailed shapes are not typically available, so the analyst must make a judgment on the path that the trip shapes.
Lessons learned from this effort are: 1) ensure that all data is available, 2) ensure data is up to date, and 3) have a rigorous quality control plan in place to ensure that all data entered is correct.
|Agency Specification||A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.|
|Compliance||A condition that exists when an item meets all of the requirements of an agency specification.|
|Concept of Operations||A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.|
|Conformance||A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.|
|Comma Separated Value (CSV)||Data files that separate fields using commas.|
|De Facto Standard||A specification that has not undergone a formal balloting process but implanted and used as if it were a standard.|
|Downstream||Describes users and tools that use data after it has been produced|
|Feed||Combined set of information being sent or received.|
|General Transit Feed Specification (GTFS)||This is a specification for creating static schedule data.|
|Metadata||Data which describes the feed but does not contain information being described by the feed.|
|Pattern||The sequencing of stops used by a transit vehicle on a trip. Is often repeated over many trips. Often includes times as well.|
|Rural Transit Assistance Program (RTAP)||Program sponsored by the Federal Transit Administration to fund rural transit operations.|
|Service Calendar||Defines the days that a trip or a set of trips operate. May describe days of the week, specific dates. Also defines exceptions to normal service, such as for holidays.|
|Static information||Describes data which is consistent on a day to day basis, although it may change at a defined frequently. Refers to transit schedules.|
|Text File||Files that can be edit in a text editor.|
GTFS Best Practices https://maps.google.com/help/maps/mapcontent/transit/bestpractices.html
GTFS Developers Forum: https://groups.google.com/forum/#!forum/gtfs-changes
GTFS Specification Reference: https://developers.google.com/transit/gtfs/reference
National RTAP GTFS Builder: http://nationalrtap.org/supportcenter/Builder-Apps/GTFS-Builder
National Transit Map: http://www.rita.dot.gov/bts/press releases/dot021 16
7. Study Questions
To include the quiz/poll questions and answer choices as presented in the PowerPoint slide to allow students to either follow along with the recording or refer to the quiz at a later date in the supplement.
1. Which of the following choices best describes the process for updates to the GTFS specification?
- Formal balloting process by committee
- Discussion in an online forum
- Voting by every transit agency
- There is no process
2. Which of the following areas is NOT described by the GTFS specification?
- Stop locations
- Transit trip stop times
- Fare information
- Historical Ridership Data
3. Which of the following is NOT a tool that can be used to produce GTFS feeds?
- a) Pencil and paper
- Scheduling software add-ons
- National RTAP GTFS Editor
- Open source software
4. Why is it important to test GTFS feeds?
- Ensure data is accurate and conforms to the specification
- Ensure customers use trip planners
- So agencies can change schedules on the fly
- Because testing requires no effort
5. How should GTFS feeds be made available to downstream users?
- GTFS should not be made public
- Written on a CD and mailed
- Printed on paper
- Fixed location on the web
8. Icon Guide
The following icons are used throughout the module to visually indicate the corresponding learning concept listed out below, and/or to highlight a specific point in the training material.
1) Background information: General knowledge that is available elsewhere and is outside the module being presented. This will be used primarily in the beginning of slide set when reviewing information readers are expected to already know.
Example: Information on the standard.
2) Tools/Applications: An industry-specific item a person would use to accomplish a specific task, and applying that tool to fit your need.
Example: Systems engineering, specifications, test documentation, etc. A systems engineering approach to developing an ATC procurement specification.
3) Refer to Student Supplement: Items or information that are further explained/detailed in the Student Supplement.
Example: Additional information on a standard, additional case studies or examples that don't fit into the PowerPoint itself, external resources, etc.
4) Example: Can be real-world (case study), hypothetical, a sample of a table, etc.
5) Checklist: Use to indicate a process that is being laid out sequentially. Example: Process to write test plans to verify standard requirements.