Date post: | 15-Jan-2015 |
Category: |
Technology |
Upload: | la-fing |
View: | 810 times |
Download: | 0 times |
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: [email protected]
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
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
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
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)
TriMet practical findings on official norms:
1. Too many layers and types. Must traverse ten layers to reach stop coordinates.
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.
“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.”
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)
GTFS Routes:
GTFS Stops:
GTFS Stop times:
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)
Growth in GTFS availability over time in US
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
Publishing open transport data in common open formats allows immediate reuse with existing software.
Andrew Byrd
email: [email protected]
code: http://github.com/openplans/OpenTripPlanner
http://openplans.org/2012/08/the-openplans-guide-to-gtfs-data/