The General Transit Feed Specification (GTFS) is an open specification for public transportation schedules and associated geographic information that allows for easy exchange of transit data between different systems. It originated in 2005 when TriMet in Portland, Oregon published their transit data in simple text file format for use in Google trip planning tools. GTFS has since been widely adopted for transit data sharing in the United States and parts of Europe due to its simplicity compared to larger XML specifications. The GTFS format continues to evolve through a collaborative review process to add only backward-compatible improvements that address real use cases.

1. The General Transit Feed Specification (GTFS)
A success story in spontaneous standardization
Andrew Byrd
Project Lead, OpenTripPlanner
(open source multi-modal trip planner)
Co-founder and Principal, Conveyal
(open data driven transportation consultancy)
email: abyrd@conveyal.com

2. What is GTFS?
- “The General Transit Feed Specification”
- Public transport data for journey planning
- Stop locations, routes, schedules, and transfers
- Recently extended for real-time vehicle delay and location
- An open, light-weight specification created entirely by industry

3. Where did GTFS come from?
- Origins in Portland, Oregon (US) in 2005
- TriMet regional transport agency wanted journey planning
- discovered a Google “20%” project with this goal and needed to
exchange data
- Simply exported their schedule database into structured text files
- GTFS has been extended but remains essentially the same

4. How does GTFS evolve?
- Collaborative review and modification process
- Only backward-compatible extensions are considered
- No “theoretical” improvements: only features which are actually
used by GTFS consumers

5. Why GTFS?
It is an alternative to heavyweight XML norms. TriMet considered:
- National Transportation Communications for Intelligent
Transportation System Protocol (TCIP, US FTA)
- New York's Schedule Data Profile (SDP)

6. TriMet practical findings on official norms:
1. Too many layers and types. Must traverse ten layers to reach stop
coordinates.

7. TriMet practical findings on official norms:
1. Too many layers and types. Must traverse ten layers to reach stop
coordinates.
2. Ambiguity. Several different element types can be used to represent
the same reality.
Conclusion:
We need “a smaller, flatter and narrowly focused set of elements.”
This can be exported from more detailed operational databases or
national/international data exchange norms.

8. “Agencies develop different requirements, policies and practices
over time, even while performing the same basic task.
A standard that encompasses such business logic is liable to fail as
it attempts to normalize the elements of the task. TCIP is so broad
in its definition, that we feel it’s almost unusable as a standard. The
size and ambiguity alone are real show-stoppers.
A more feasible approach would be to move away from … large
data / process / business rules standards, and in the direction of
simple, clean, compartmentalized sets of standards that define a
narrow set of data elements for a specific given task.”

9. GTFS : Simple schema, CSV tables (i.e. a zip of text files)
Used for almost all open public transport data in the United States
and France.
Data is not as rich as “heavy” XML standards like NeTEx (Europe)
or TCIP (US FTA), but much preferred by many developers and
agencies:
- Evolved directly from a specific use case (journey planning)
- Parsing / loading is straightforward
- A single way to express each concept (facilitates implementation)

10. GTFS Routes:

11. GTFS Stops:

12. GTFS Stop times:

13. Open public transport data availability in GTFS format
- United States: > 80% of passenger-km in PT covered
- In France: Rennes, Nantes, Bordeaux, SNCF Transilien, TER,
Intercités and the entire RATP (Métro, bus, tram, night buses)
- Netherlands: nearly 100% coverage by OpenOV, with the position
and delay of each vehicle updated 1 time per minute
- Conversion from more detailed European standards
straightforward (e.g. for Bouches du Rhône)

14. Growth in GTFS availability over time in US

19. Reuse of this operational data
- Passenger information (journey planners, bus arrival notices)
But also...
- Infrastructure and service planning, impact studies
- Town planning, communication, public consultations
- Social and economic research

25. Publishing open transport data in common open formats
allows immediate reuse with existing software.

26. Andrew Byrd
email: abyrd@conveyal.com
code: http://github.com/openplans/OpenTripPlanner
http://openplans.org/2012/08/the-openplans-guide-to-gtfs-data/