The GTFS specification is not set in stone. Instead, it is an open specification developed and maintained by the community of transit agencies, developers, and other stakeholders who use GTFS. It is expected that this community of producers and consumers of GTFS data will have proposals for extending the spec to enable new capabilities. To help manage that process, the following procedures and guidelines have been established.
The Change Process
The general outline for changing the spec has a couple of steps:
- Propose a change on the GTFS-changes discussion list.
- Receive comments and feedback from the GTFS community and iterate on the proposed change.
- Find at least one GTFS producer and one consumer to implement and test the proposed change.
- Submit a final request-for-comments on the proposed change to the discussion list. If no outstanding issues are identified after one week’s time, the proposal will be officially adopted.
The discussion group will serve as the primary place for suggesting changes to the spec, such that users of GTFS can learn about and offer feedback on proposed changes. If the community generally agrees that the proposal is worthwhile and follows the GTFS guiding principles outlined below, it will be officially added to the spec. We also require that any proposed change be implemented by at least one GTFS producer and one consumer, in order to verify the feasibility of that change in practice.
In addition to the discussion group, note that the GTFS Changes Site will be used to document exiting GTFS change proposals in support of of the discussion group.
In order to preserve the original vision of GTFS, a number of guiding principles have been established to take into consideration when extending the spec:
Feeds should be easy to create and edit.
We chose CSV as the basis for the specification because it's easy to view and edit using spreadsheet programs and text editors, which is helpful for smaller agencies. It's also straightforward to generate from most programming languages and databases, which is good for publishers of larger feeds.
Feeds should be easy to parse.
Feed readers should be able to extract the information they're looking for with as little work as possible. Changes and additions to the feed should be as broadly useful as possible, to minimize the number of code paths that readers of the feed need to implement. (However, making creation easier should be given precedence, since there will ultimately be more feed publishers than feed readers.)
Changes to the spec should be backwards-compatible.
When adding features to the specification, we want to avoid making changes that will make existing feeds invalid. We don't want to create more work for existing feed publishers until they want to add capabilities to their feeds. Also, whenever possible, we want existing parsers to be able to continue to read the older parts of newer feeds.
Speculative features are discouraged.
Every new feature adds complexity to the creation and reading of feeds. Therefore, we want to take care to only add features that we know to be useful. Ideally, any proposal will have been tested by generating data for a real transit system that uses the new feature and writing software to read and display it. Note that the GTFS readily allows for extensions to the format through the addition of extra columns and files that are ignored by the official parsers & validators, so proposals can be easily prototyped and tested on existing feeds.
February 17, 2014
- Added trips.txt 'bikes_allowed' proposal to spec: discussion
October 15, 2012
- Added trips.txt 'wheelchair_accessible' proposal to spec: discussion
June 20, 2012
- Added 'wheelchair_boarding' proposal to spec: discussion
February 2, 2012
- Added 'stop_timezone' proposal to spec: discussion
January 18, 2012
September 26, 2011
- Added 'feed_info' proposal to spec: discussion
September 6, 2011
- Added 'agency_fare_url' proposal to spec: discussion
- Added 'exact_times' proposal to spec: discussion
March 30, 2009
- A new section on making a transit feed publicly available. This wasn't previously discussed on the group, because it wasn't strictly a change to how the data is interpreted or written. However, some of the folks at Google thought that it would be informative to include discussion of non-Google uses of GTFS, since there are an increasing number of applications that can make use of GTFS-formatted data.
- CSV format clarifications: discussion.
- Additional guidance on how to pick contrasting colors in the descriptions of the route_color and route_text_color fields.
- trip_short_name, as proposed and tested in these threads: a and b.
- A fix for a minor error in the sample data included at the end of the document (giving stop S7 the parent_station S8).
- Added "agency_lang" information to the sample data at the end of the document, as suggested by Marcy during the comment period: discussion.
- Updated the link to OCTA's GTFS feed in the sidebar
- See orignial summary.
February 26, 2009
- Removed most of the Google-specific feed submission instructions, since there are many other applications that consume GTFS data at this point.
- Fixed a broken link in the sidebar to Orange County OCTA's public feed.
August 7, 2008
- Restored the stop_url field, which was accidentally omitted in the August 6 version
- Added agency_phone to sample data
- Added a mention of the data use agreement when submitting a feed to Google
August 6, 2008
- Added transfers.txt file, allowing the feed publishers to provide hints on preferred transfer behavior (original proposal)
- Added location_type and parent_station fields to stops.txt, allowing stop points to be grouped into stations (original proposal)
- Added agency_phone field for providing voice telephone number for an agency (original proposal)
- Added "Testing Your Feeds" section mentioning open-source testing tools
- Added clarifications about CSV format, agency_timezone, agency_lang, route_color, route_text_color, arrival_time, departure_time, calendar.txt vs. calendar_dates.txt, fare tables, and frequencies.txt
- Added link to feed history document, and corrected some public feed links
- Updated example images to depict the current Google Maps UI
- Updated/fixed sample data in document
February 29, 2008
- Added the stop_code field in stops.txt to allow for the specification of rider-facing stop codes (original proposal)
- Clarified the descriptions of route_short_name and route_long_name in routes.txt
- Clarified the descriptions of arrival_time and departure_time in stop_times.txt
- Fixed typos in the Sample Data section
November 20, 2007
- Clarified block_id description
- Changed language to de-emphasize Google Transit (since non-Google applications are using GTFS, and transit routing is now an integrated feature of Google Maps), and to fix assorted typos
- Updated example screenshots to reflect the presentation of GTFS fields in the current Google Maps UI
- Updated the Google contact email address for transit data providers
- Updated formatting
October 5, 2007
- Changed stop_sequence and shape_pt_sequence to allow for any increasing non-negative integers
- Clarified descriptions and fixed typos
May 31, 2007
- Updated page style, made HTML cleaner and more accessible
- Added links to public feed examples and other useful sites
- Removed examples from individual field descriptions
April 9, 2007
- Added section on submitting a feed.
- Added the Example Demo Transit Agency feed.
- Added note that calendar.txt can be omitted if all the service dates are defined in calendar_dates.txt.
- Made the agency_id field optional in feeds containing only one agency. This allows existing feeds without agency_id to remain valid.
- Added fuller specification of agency_url, stop_url, and route_url, and additional example values for those fields.
- Added 6 (Gondola) and 7 (Funicular) as valid route_type values.
March 8, 2007
- Minor edit to move the stop_url field from stop_times.txt, where it was incorrectly specified in the Feb. 28 update, to stops.txt, where it belongs.
March 5, 2007
- Minor edit to clarify the description of the route_long_name field.
February 28, 2007
- Addition of frequencies.txt for headway-based schedule support.
- Multiple agencies now allowed in the the same feed. Also added new agency_id field in both agencies.txt and routes.txt that lets you specify which route is operated by which agency.
- Addition of per-route and per-stop URLs.
- Addition of direction_id field in trips.txt.
- Support for mid-trip headsign changes with addition of stop_headsign field in stop_times.txt.
- Support for route colors with addition of optional route_color and route_text_color in routes.txt.
- Removed the ability to specify stops using street addresses. The previous version of the spec allowed you to give the location of a transit stop using a street address in the stop_street, stop_city, stop_region, stop_postcode, and stop_country fields. Now stop locations must be given using stop_lat for latitude and stop_lon for longitude, which are more useful for most applications.
- Addition of cable car vehicle type for route_type field in routes.txt.
- See the original Headway blog post summary of the changes.
November 29, 2006
- Added support for trip shape information via shapes.txt
- Clarified the definition of stop_sequence
- Marked pickup_type and drop_off_type optional
October 31, 2006
- Added support for fare information
- Removed dates from individual file names
- Changed the route_type value definitions
- Allowed for multiple feed files to be posted at the same time, as long as their service periods didn't overlap
- Fixed block_id in trips.txt so that it was correctly marked Optional
- Noted that column headers must be included
September 29, 2006
- Minor edit to fix a couple errors in the examples.
September 25, 2006
- Initial version.