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.[1]
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.
Structure
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.
agency
The agency table provides information about the transit agency as such, including name, website and contact information.
Required fields:
- agency_name
- agency_url
- agency_timezone
routes
The routes table identifies distinct routes. This is to be distinguished from distinct routings, several of which may belong to a single route.
Required fields:
- route_id (primary key)
- route_short_name
- route_long_name
- route_type
trips
Required fields:
- trip_id (primary key)
- route_id (foreign key)
- service_id (foreign key)
Optional fields:
- block_id - The block ID indicates the schedule block to which a trip belongs.
stop_times
Required fields:
- stop_id (primary key)
- trip_id (foreign key)
- arrival_time
- departure_time
- stop_sequence
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.
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.
Required fields:
- stop_id (primary key)
- stop_name
- stop_lon
- stop_lat
calendar
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.
Required fields:
- service_id (primary key)
- monday
- tuesday
- wednesday
- thursday
- friday
- saturday
- sunday
- start_date
- end_date
Optional tables:
- calendar_dates.txt
- fare_attributes.txt
- fare_rules.txt
- shapes.txt
- frequencies.txt
- transfers.txt
- feed_info.txt
See also
External links
- GTFS Specification
- History of GTFS
- GTFS Tools
- General Transit Feed Specification article on TransitWiki, with history, uses and applications, production methods, and best practices