General Transit Feed Specification
The General Transit Feed Specification (GTFS) defines a common format for public transportation schedules and associated geographic information.
GTFS, first conceived by Bibiana McHugh, an IT Manager at the TriMet transit agency in the Portland metropolitan area (Oregon) was developed by Google and Portland TriMet, and originally known as the Google Transit Feed Specification.
A GTFS feed is a collection of CSV files (with extension .txt) contained within a .zip file. Together, the related CSV tables describe a transit system's scheduled operations. The specification is designed to be sufficient to provide trip planning functionality, but is also useful for other applications such as analysis of service levels and some general performance measures. GTFS only includes scheduled operations, and does not include real-time information. However real-time information can be related to GTFS schedules according to the related GTFS-realtime specification.
Following are descriptions of the tables required for a valid GTFS data feed. Each table is literally a text CSV file whose filename is the name of the table, suffixed by '.txt'. So for the 'agency' table below, a CSV file called 'agency.txt' would be included in a valid GTFS feed.
The agency table provides information about the transit agency as such, including name, website and contact information.
The routes table identifies distinct routes. This is to be distinguished from distinct routings, several of which may belong to a single route.
- route_id (primary key)
- trip_id (primary key)
- route_id (foreign key)
- service_id (foreign key)
- block_id - The block ID indicates the schedule block to which a trip belongs.
- stop_id (primary key)
- trip_id (foreign key)
Note that dwell time may be modelled by the difference between the arrival and departure times. However, many agencies do not seem to model dwell time for most stops.
The stops table defines the geographic locations of each and every actual stop or station in the transit system as well as, and optionally, some of the amenities associated with those stops.
- stop_id (primary key)
The calendar table defines service patterns that operate recurrently such as, for example, every weekday. Service patterns that don't repeat such as for a one-time special event will be defined in the calendar_dates table.
- service_id (primary key)
|This World Wide Web–related article is a stub. You can help Wikipedia by expanding it.|