General Transit Feed Specification

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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


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.

Required fields:

  • agency_name
  • agency_url
  • agency_timezone


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


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.


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.


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


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[edit]

External links[edit]


  1. ^ proposal: remove "Google" from the name of GTFS