Intro

The General Transit Feed Specification (GTFS) defines a common format for public transportation schedules and associated geographic information. GTFS "feeds" allow public transit agencies to publish their transit data and developers to write applications that consume that data in an interoperable way.

Originally developed in collaboration between several staff at the city of Portland, USA's public transit agency TriMet and Google in 2005, and called the "Google Transit Feed Specification", the Google has since been replaced by General.

The format is now in relatively wide use around the world, although particularly in the USA. The importance of a de-facto standard for public transit information has been its ability to spur an ecosystem of app developers and projects, both proprietary and Open Source, to make use of the data. This makes public transit more accessible and amenable, which should support it being a more competitive option to the private car for transport.

There is also an emerging set of tools that use GTFS to allow analysis and communication of the quality of a public transport network, such as Mapnificent and OpenTripPlanner.

About the format

GTFS data model diagram.PNG


The GTFS is a relatively simple flat-file format, specifying agencies, routes, stops, and schedules for public transit in a region. For a quick visual overview of the format, see the figure at right, reproduced with permission from Martin Davis, per this post on his blog.

There are tools to import the format into a relational database form such as [gtfsdb], and also either using this route or the JEQL query language, to export the relevant route information to GIS shapefiles (see here).

Possible Extensions/Alternatives to GTFS

GTFS has proved effective and useful for transit systems that follow well-defined routes and schedules in a region. But there are several aspects of possible improvements, additions, or alternatives to the standard that groups are working on:

  • Better support for fare information, to help people work out the costs of trips;
  • Better integration with long-distance transport systems (especially in Europe where international rail networks can work closely with city-based transport systems);
  • Either updates to GTFS, or developing alternatives, to better support information about less format paratransit, especially in developing countries. See the Google group 'Making GTFS work for the rest of the world';
  • Updating to a more web-services approach to allow real-time updates about vehicle locations, service frequencies etc - GTFS-realtime. This standard has been released since 2011 and is operating in some areas already, such as San Francisco's BART system.

For all of these possible extensions/alternatives, there is an important design issue to consider of simplicity of the standard vs flexibility.

Interwiki

See also

External Links

Mailing lists:

Cookies help us deliver our services. By using our services, you agree to our use of cookies.