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[1].

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

• Google Transit

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