Difference between revisions of "Best practices for creating GTFS"
Jump to navigation
Jump to search
(Split out official from unofficial Best Practices) |
|||
Line 16: | Line 16: | ||
[[Category:General Transit Feed Specification]] | [[Category:General Transit Feed Specification]] | ||
− |
Revision as of 23:43, 21 August 2017
The General Transit Feed Specification allows for transit features to be described using a variety of approaches. In some cases, particular approaches will result in better results in GTFS-consuming applications. Various pages on the web offer advice on best practices for creating GTFS.
Official:
- GTFS.org Industry-Standard Best Practices - These Best Practices are agreed to and published by 17 industry partners. These are the most broadly-accepted and complete GTFS Best Practices.
Unofficial:
- The Transit App developers page provides "Open Data Guidelines" which includes recommendations on how to form GTFS for best results in the application.
- Google Maps has a GTFS Best Practices Guide
- An open Google Doc has captured some best practices from members of the GTFS community.
- RideSchedules provides GTFS Publisher Best Practices for creating and hosting GTFS.
- Kurt Raschke provides recommendations for how to host GTFS data on a server to ensure update availability in consuming applications.
- Quentin Zervaas's Book The Definitive Guide to GTFS offers some discussion of GTFS best practices and style choices.
- FeedValidator's errors and warnings reference provides an inventory of some common GTFS defects to avoid. feedvalidator.py software can automatically identify these potential issues.
- Best practices and application-behavior context for specifying headsigns in GTFS from Trillium.
- The Center for Urban Transportation Research at the University of South Florida has identified some best practices as part of their experience with GTFS-realtime feeds.