Intro[edit | edit source]

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[edit | edit source]

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.

Availability of GTFS feeds around the world[edit | edit source]

Many cities in the developing world now have GTFS feeds available online - usually curated by the region's public transit agencies.

A website keeping track of the global database of such agencies and feeds is the GTFS data exchange.

Some cities don't yet have such feeds available. Sometimes they have the capability to do so, and it might require citizen advocacy in order to put in place the capabilities and processes to regularly release the data. See the papers by Aaron Antrim and collaborators below with some discussion and analysis of benefits of releasing GTFS data, and how to address potential concerns, that may be helpful in convincing agencies to change their approach.

However in other cases, particularly in the developing world where there is much more 'para-transit' that runs to a far less regular schedule - there are difficulties with representing the cities' transit in the GTFS specification. See the "possible extensions / alternatives to GTFS" section below.

Software tools for working with GTFS feeds, and converting to other formats, such as Geodatabases or GIS shapefiles[edit | edit source]

One reasonably nice Open Source Python-based library for working with GTFS feeds - either creating them, or extracting information from existing feeds - is Google's transitfeed library. It also includes tools for converting from the 'TransXChange' format to GTFS. Commercial GTFS tools such as AddTransit are also available.

There are tools to import the format into a relational database form such as [1], 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[edit | edit source]

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. See the Google Group GTFS Fares - New Request For Comment for the 2013 proposal;
  • 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 versus flexibility.

Interwiki[edit | edit source]

See also[edit | edit source]

Pages tagged in the GTFS category:

External Links[edit | edit source]

Mailing lists:

Discussion[View | Edit]

GTFS for the developing world[edit source]

This resource might be useful, as it is interested in GTFS in an international/developing world context: Google Group - Making GTFS work for the rest of the world --Aaron 17:51, 19 July 2013 (PDT)

  • Thanks Aaron - this is an important point given Appropedia's global scope v. much including developing countries. I will add the link, and also make a note about the fact that GTFS doesn't work ideally for all systems yet, and that additions are under consideration. --PatSunter 18:38, 19 July 2013 (PDT)

GTFS vs alternative standards[edit source]

Paraphrasing a comment by colleauge Carl Fredlund: GTFS isn't the only standard for transport timetable information, and has some limitations other than those commented upon with this page. Perhaps we should remain open to different approaches for different applications, e.g. long-distance bus travel?

Make this a category page?[edit source]

There are so many GTFS applications, technologies, and practices out there, and no easy & collective way to track them all. Would it make sense to make this a category page? Then we could arrange various articles in that category? I'd really like to bring something back like Joe Hughes's Headway wiki (now-defunct): --Aaron (talk) 27 January 2014

  • Hi Aaron - a GTFS category sounds good. I'm not too sure about 'best practice' on Appro for creating category pages, I've seen several cases where there is a longer normal 'page' and then the Category page has a short blurb on the topic then refers to the normal page. I'll chase up a few more examples. --PatSunter (talk) 13:58, 27 January 2014 (PST)
I lean towards having content on regular pages, with categories mainly for navigation – there are a few exceptions to this on Appropedia, but those are mainly for classes.
Note that it's possible to display the pages of a category anywhere you want using the CategoryTree tool. E.g. see Resources for aid and development workers. --Chriswaterguy (talk) 15:27, 30 January 2014 (PST)
Thanks Chris! The CategoryTree tool looks like a good option and may well fit the bill of I think what Aaron was getting at - that the main GTFS page as well as introductory info would also be a meta-page with automatic links to pages with more specific detail. It looks like a key thing then is to think up an appropriate simple sub-category hierarchy then for classifying the sub-pages. Maybe Aaron you could propose a few of these based off the Headway Wiki? --PatSunter (talk) 16:02, 30 January 2014 (PST)

Judging by a quick look at Headway wiki this would include:

  • GTFS consumers
  • GTFS-providing Agencies (although this probably now at least partly covered by City-go-round and the GTFS Data exchange site?)
  • GTFS software (a bit of overlap with the Open Source Transport Informatics tools pages I've set up, but I'm happy to refactor, and certainly I'm no zealot about only listing FOSS tools - see it as fine to add non-FOSS tools. I know a lot of content in your GTFS working papers would be suitable here)
Just more generally too :- I see some of your pages are more general than GTFS, perhaps this is relevant to the Transport informatics idea I've been thinking about a little and created a page for - I put a few links between relevant pages, feel free to add more detail there.
Cookies help us deliver our services. By using our services, you agree to our use of cookies.