GTFS, which stands for General Transit Feed Specification or (originally) Google Transit Feed Specification, defines a common format for public transportation schedules and associated geographic information.[1] GTFS contains only static or scheduled information about public transport services, and is sometimes known as GTFS Static or GTFS Schedule to distinguish it from the GTFS Realtime extension, which defines how information on the realtime status of services can be shared.[1][2]
 | |
| Filename extension |
.zip |
|---|---|
| Developed by | |
| Initial release | 27 September 2006 |
| Type of format | Transit schedule format |
| Extended from | CSV |
| Standard | De facto standard |
| Open format? | Yes, CC BY 3.0 |
| Website | gtfs |
History edit
What was to become GTFS started out as a side project of Google employee Chris Harrelson in 2005, who "monkeyed around with ways to incorporate transit data into Google Maps when he heard from Tim and Bibiana McHugh, married IT managers at TriMet, the transit agency for Portland, Oregon".[3] McHugh is cited with being frustrated about finding transit directions in unfamiliar cities, while popular mapping services were already offering easy-to-use driving directions at the time.[4]
Bibiana and Tim McHugh eventually got into contact with Google and provided the company with CSV exports of TriMet's schedule data. In December 2005, Portland became the first city to be featured in the first version of Google's "Transit Trip Planner".[5] In September 2006, five more US cities were added to the Google Transit Trip Planner, and the data format released as the Google Transit Feed Specification.[6]
In the United States, there had not been any standard for public transit timetables prior to the advent of GTFS, not even a de facto standard. According to long-time BART website manager Timothy Moore, before the advent of GTFS, BART had to provide different data consumers with different formats, making a standardized transit format very desirable.[3] The publicly and freely available format specification, as well as the availability of GTFS schedules, quickly made developers base their transit-related software on the format. This resulted in "hundreds of useful and popular transit applications"[4] as well as catalogues listing available GTFS feeds. Due to the common data format those applications adhere to, solutions do not need to be custom-tailored to one transit operator, but can easily be extended to any region where a GTFS feed is available.
Due to the wide use of the format, the "Google" part of the original name was seen as a misnomer "that makes some potential users shy away from adopting GTFS". As a consequence, it was proposed to change the name of the specification to General Transit Feed Specification in 2009.[7]
Applications edit
Journey planning edit
GTFS is typically used to supply data on public transit for use in multi-modal journey planner applications. In most cases, GTFS is combined with a detailed representation of the street/pedestrian network to allow routing to take place from point to point rather than just between stops. This data is often extended using GTFS-Realtime to factor delays, cancellations, and modified trips into realtime journey planning queries. OpenTripPlanner is open-source software that can do journey planning with a combination of GTFS and OpenStreetMap data.[8] Other general purpose applications exist such as the ArcMap Network Analyst extension which can incorporate GTFS for transit routing.[9]
GTFS was originally designed for use in Google Transit, an online multi-modal journey planning application.
Accessibility research edit
GTFS is often used in research on transit accessibility where it is typically used to estimate travel times by transit from one point to many other points at different times of day.[10][11] Studies however have called such applications into question due to their reliance on schedules alone without accounting for reliability issues and regular schedule non-adherence.[12]
Comparing service levels edit
GTFS has been used to measure changes in accessibility due to changes in transit service provision, either actual[13] or proposed.[14] Analysis of changes in service over time can be accomplished by simply comparing published GTFS data for the same agency from different time periods. For comparison of existing service with proposed infrastructure or service changes, a future GTFS must often be constructed by hand based on proposed service characteristics.[14]
Feed registries edit
Public GTFS feeds have been aggregated in a variety of feed registries:
- TransitFeeds / OpenMobilityData maintains a directory of GTFS and GTFS Realtime feeds and an interactive website for browsing feed contents.
- GTFS Data Exchange (2008–2016) allowed public transit agencies of all sizes to upload copies of their GTFS feeds. The website is no longer active but still allows browsing and download of historical data.
- Transitland (2014 - present) maintains a directory of GTFS and GTFS Realtime feeds in 55+ countries and provides both an interactive website and APIs for querying feed contents. Transitland was originally created by Mapzen and is now maintained by Interline Technologies.
Structure edit
A GTFS feed is a collection of at least six, and up to 13 CSV files (with extension .txt) contained within a .zip file. Preferred character encoding is UTF-8. Together, the related CSV tables describe a transit system's scheduled operations as visible to riders. The specification is designed to be sufficient to provide trip planning functionality, but is also useful for other applications such as analysis of service levels and some general performance measures. In contrast to European transit industry exchange standards such as Transmodel or VDV-45X, GTFS only includes scheduled operations that are meant to be distributed to riders. It is also limited to scheduled information and does not include real-time information. However, real-time information can be related to GTFS schedules according to the related GTFS Realtime specification.[1][2]
Following are descriptions of the tables required for a valid GTFS data feed. Each table is literally a text CSV file whose filename is the name of the table, suffixed by '.txt'. So for the 'agency' table below, a CSV file called 'agency.txt' would be included in a valid GTFS feed.
Mandatory tables edit
agency edit
The agency table provides information about the transit agency as such, including name, website and contact information.
Required fields:
- agency_name
- agency_url
- agency_timezone
routes edit
The routes table identifies distinct routes. This is to be distinguished from distinct routings (or paths), several of which may belong to a single route.
Required fields:
- route_id (primary key)
- route_short_name
- route_long_name
- route_type
- background_color
- foreground_color
trips edit
Required fields:
- trip_id (primary key)
- route_id (foreign key)
- service_id (foreign key)
Optional fields:
- block_id - The block ID indicates the schedule block to which a trip belongs.
stop_times edit
Required fields:
- stop_id (primary key)
- trip_id (foreign key)
- arrival_time
- departure_time
- stop_sequence
Note that dwell time may be modelled by the difference between the arrival and departure times. However, many agencies do not seem to model dwell time for most stops.
stops edit
The stops table defines the geographic locations of each and every actual stop or station in the transit system as well as, and optionally, some of the amenities associated with those stops.
Required fields:
- stop_id (primary key)
- stop_name
- stop_lon
- stop_lat
calendar edit
The calendar table defines service patterns that operate recurrently such as, for example, every weekday. Service patterns that don't repeat such as for a one-time special event will be defined in the calendar_dates table.
Required fields:
- service_id (primary key)
- Monday
- Tuesday
- Wednesday
- Thursday
- Friday
- Saturday
- Sunday
- start_date
- end_date
Optional tables edit
calendar_dates edit
Calendar dates is an optional table which adds exceptions to the calendar.txt file. This can be adding additional days or removing days, such as for holiday service. The file only contains three columns, the service id, date, and exception type (either added or removed). A service id does not have to be inside the calendar.txt file to be added to this table.
fare_attributes edit
fare_rules edit
shapes edit
Rules for drawing lines on a map to represent a transit organization's routes.
frequencies edit
This table specifies headway (time between trips) for routes with variable frequency of service.
transfers edit
Rules for making connections at transfer points between routes.
feed_info edit
An optional feed start date and optional feed expiration date can be set. Agencies may publish feeds that are several days into the future. Thus, journey planning software applications keep multiple feed versions and the correct feed for a particular day or time.
translations
The translations table consists of the columns table_name, field_name, field_value,record_id,record_sub_id,language,translation. Translations are broken down into their respective tables, and any text field or URL may be translated. Translations in GTFS use two types of keys in the key-value table. Record_id uses ID for the field like stop_id or trip_id, while field_value is a matching value to the field_name's original contents. Tables using a two value tuple, such as stop_times, use record_id and record_sub_id to represent the tuple. The translation column is the output.
See also edit
References edit
- ^ a b c "GTFS Static Overview". GoogleDevelopers. Archived from the original on 29 September 2022. Retrieved 29 September 2022.
- ^ a b "GTFS Realtime Overview". GoogleDevelopers. Archived from the original on 29 September 2022. Retrieved 29 September 2022.
- ^ a b Roush, Wade (2012). "Welcome to Google transit: How (and why) the search giant is remapping public transportation" (PDF). Community Transportation: 3. Retrieved 14 March 2016.
- ^ a b Dyson, Lauren; Goldstein, Brett; Nemani, Abhi (2013). Beyond Transparency. Code for America Press. pp. 125–135. CiteSeerX 10.1.1.674.6114.
- ^ Garg, Avichal. "Public Transit via Google". Official Google Blog. Archived from the original on 24 March 2016. Retrieved 14 March 2016.
- ^ Harrelson, Chris. "Happy Trails with Google Transit". Official Google Blog. Archived from the original on 24 March 2016. Retrieved 14 March 2016.
- ^ Hughes, Joe. "proposal: remove "Google" from the name of GTFS". General Transit Feed Spec Changes. Google Groups. Archived from the original on 29 September 2022. Retrieved 14 March 2016.
- ^ "Home | OpenTripPlanner". www.opentripplanner.org. Archived from the original on 8 May 2017. Retrieved 12 May 2017.
- ^ "Yay, transit! - Using GTFS Data in ArcGIS Network Analyst". transit.melindamorang.com. Archived from the original on 19 May 2017. Retrieved 12 May 2017.
- ^ Farber, Steven; Morang, Melinda Z.; Widener, Michael J. (1 September 2014). "Temporal variability in transit-based accessibility to supermarkets". Applied Geography. 53: 149–159. doi:10.1016/j.apgeog.2014.06.012.
- ^ Fransen, Koos; Neutens, Tijs; Farber, Steven; De Maeyer, Philippe; Deruyter, Greet; Witlox, Frank (1 October 2015). "Identifying public transport gaps using time-dependent accessibility levels". Journal of Transport Geography. 48: 176–187. doi:10.1016/j.jtrangeo.2015.09.008. hdl:1854/LU-6956461.
- ^ Wessel, Nate; Allen, Jeff; Farber, Steven (1 June 2017). "Constructing a routable retrospective transit timetable from a real-time vehicle location feed and GTFS". Journal of Transport Geography. 62: 92–97. doi:10.1016/j.jtrangeo.2017.04.012. ISSN 0966-6923.
- ^ Farber, Steven; Fu, Liwei (1 March 2017). "Dynamic public transit accessibility using travel time cubes: Comparing the effects of infrastructure (dis)investments over time". Computers, Environment and Urban Systems. 62: 30–40. doi:10.1016/j.compenvurbsys.2016.10.005.
- ^ a b Farber, Steven; Grandez, Maria (2017). "Transit Accessibility, Land Development and Socioeconomic Priority: A Typology of Planned Station Catchment Areas in the Greater Toronto and Hamilton Area" (PDF). Journal of Transport and Land Use. 10 (1). doi:10.5198/jtlu.2017.980. (note: forthcoming edition).
This article contains excerpts from "Opening Public Transit Data in Germany" by Stefan Kaufmann, which is available under a Creative Commons Attribution 3.0 unported license.
External links edit
- Google documentation on GTFS Specification
- History of GTFS
- GTFS Tools
- GTFS resource center managed by MobilityData
- General Transit Feed Specification article on TransitWiki, with history, uses and applications, production methods, and best practices