· 6 years ago · Dec 03, 2019, 12:18 PM
1Reference
2
3This document defines the format and structure of the files that comprise a GTFS dataset.
4Table of Contents
5
6 Term Definitions
7 Field Types
8 Dataset Files
9 File Requirements
10 Field Definitions
11 agency.txt
12 stops.txt
13 routes.txt
14 trips.txt
15 stop_times.txt
16 calendar.txt
17 calendar_dates.txt
18 fare_attributes.txt
19 fare_rules.txt
20 shapes.txt
21 frequencies.txt
22 transfers.txt
23 pathways.txt
24 levels.txt
25 feed_info.txt
26
27Term Definitions
28
29This section defines terms that are used throughout this document.
30
31 Dataset - A complete set of files defined by this specification reference. Altering the dataset creates a new version of the dataset. Datasets should be published at a public, permanent URL, including the zip file name. (e.g., https://www.agency.org/gtfs/gtfs.zip).
32 Record - A basic data structure comprised of a number of different field values describing a single entity (e.g. transit agency, stop, route, etc.). Represented, in a table, as a row.
33 Field - A property of an object or entity. Represented, in a table, as a column.
34 Field Value - An individual entry in a field. Represented, in a table, as a single cell.
35 Required - The field must be included in the dataset, and a value must be provided in that field for each record. Some required fields permit an empty string as a value (denoted in this specification as empty). To enter an empty string, just omit any text between the commas for that field.
36 Optional - The field may be omitted from the dataset. If an optional column is included, some of the entries in that field may be empty strings. To enter an empty string, just omit any text between the commas for that field. Note that an omitted field is equivalent to a field that is entirely empty.
37 Conditionally required - The field or file is required under certain conditions, which are outlined in the field or file description. Outside of these conditions, this field or file is optional.
38 Service day - A service day is a time period used to indicate route scheduling. The exact definition of service day varies from agency to agency but service days often do not correspond with calendar days. A service day may exceed 24:00:00 if service begins on one day and ends on a following day. For example, service that runs from 08:00:00 on Friday to 02:00:00 on Saturday, could be denoted as running from 08:00:00 to 26:00:00 on a single service day.
39
40Field Types
41
42 Color - A color encoded as a six-digit hexadecimal number. Refer to https://htmlcolorcodes.com to generate a valid value (the leading "#" is not included).
43 Example: FFFFFF for white, 000000 for black or 0039A6 for the A,C,E lines in NYMTA.
44 Currency Code - An ISO 4217 alphabetical currency code. For the list of current currency, refer to https://en.wikipedia.org/wiki/ISO_4217#Active_codes.
45 Example: CAD for Canadian dollars, EUR for euros or JPY for Japanese yen.
46 Date - Service day in the YYYYMMDD format. Since time within a service day can be above 24:00:00, a service day often contains information for the subsequent day(s).
47 Example: 20180913 for September 13th, 2018.
48 Email - An email address.
49 Example: example@example.com
50 Enum - An option from a set of predefined constants defined in the "Description" column.
51 Example: The route_type field contains a 0 for tram, a 1 for subway...
52 ID - An ID field value is an internal ID, not intended to be shown to riders, and is a sequence of any UTF-8 characters. Using only printable ASCII characters is recommended. IDs defined in one .txt file are often referenced in another .txt file.
53 Example: The stop_id field in stops.txt is a ID. The stop_id field in stop_times.txt is an ID referencing stops.stop_id.
54 Language Code - An IETF BCP 47 language code. For an introduction to IETF BCP 47, refer to http://www.rfc-editor.org/rfc/bcp/bcp47.txt and http://www.w3.org/International/articles/language-tags/.
55 Example: en for English, en-US for American English or de for German.
56 Latitude - WGS84 latitude in decimal degrees. The value must be greater than or equal to -90.0 and less than or equal to 90.0.
57 Example: 41.890169 for the Colosseum in Rome.
58 Longitude - WGS84 longitude in decimal degrees. The value must be greater than or equal to -180.0 and less than or equal to 180.0.
59 Example: 12.492269 for the Colosseum in Rome.
60 Non-negative Float - A floating point number greater than or equal to 0.
61 Non-negative Integer - A integer greater than or equal to 0.
62 Phone number - A phone number.
63 Time - Time in the HH:MM:SS format (H:MM:SS is also accepted). The time is measured from "noon minus 12h" of the service day (effectively midnight except for days on which daylight savings time changes occur. For more information, see the guidelines article). For times occurring after midnight, enter the time as a value greater than 24:00:00 in HH:MM:SS local time for the day on which the trip schedule begins.
64 Example: 14:30:00 for 2:30PM or 25:35:00 for 1:35AM on the next day.
65 Text - A string of UTF-8 characters, which is aimed to be displayed and which must therefore be human readable.
66 Timezone - TZ timezone from the https://www.iana.org/time-zones. Timezone names never contain the space character but may contain an underscore. Refer to http://en.wikipedia.org/wiki/List_of_tz_zones for a list of valid values.
67 Example: Asia/Tokyo, America/Los_Angeles or Africa/Cairo.
68 URL - A fully qualified URL that includes http:// or https://, and any special characters in the URL must be correctly escaped. See the following http://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a description of how to create fully qualified URL values.
69
70Dataset Files
71
72This specification defines the following files:
73Filename Required Defines
74agency.txt Required Transit agencies with service represented in this dataset.
75stops.txt Required Stops where vehicles pick up or drop off riders. Also defines stations and station entrances.
76routes.txt Required Transit routes. A route is a group of trips that are displayed to riders as a single service.
77trips.txt Required Trips for each route. A trip is a sequence of two or more stops that occur during a specific time period.
78stop_times.txt Required Times that a vehicle arrives at and departs from stops for each trip.
79calendar.txt Conditionally required Service dates specified using a weekly schedule with start and end dates. This file is required unless all dates of service are defined in calendar_dates.txt.
80calendar_dates.txt Conditionally required Exceptions for the services defined in the calendar.txt. If calendar.txt is omitted, then calendar_dates.txt is required and must contain all dates of service.
81fare_attributes.txt Optional Fare information for a transit agency's routes.
82fare_rules.txt Optional Rules to apply fares for itineraries.
83shapes.txt Optional Rules for mapping vehicle travel paths, sometimes referred to as route alignments.
84frequencies.txt Optional Headway (time between trips) for headway-based service or a compressed representation of fixed-schedule service.
85transfers.txt Optional Rules for making connections at transfer points between routes.
86pathways.txt Optional Pathways linking together locations within stations.
87levels.txt Optional Levels within stations.
88feed_info.txt Optional Dataset metadata, including publisher, version, and expiration information.
89File Requirements
90
91The following requirements apply to the format and contents of the dataset files:
92
93 All files must be saved as comma-delimited text.
94 The first line of each file must contain field names. Each subsection of the Field Definitions section corresponds to one of the files in a GTFS dataset and lists the field names that may be used in that file.
95 All field names are case-sensitive.
96 Field values may not contain tabs, carriage returns or new lines.
97 Field values that contain quotation marks or commas must be enclosed within quotation marks. In addition, each quotation mark in the field value must be preceded with a quotation mark. This is consistent with the manner in which Microsoft Excel outputs comma-delimited (CSV) files. For more information on the CSV file format, see http://tools.ietf.org/html/rfc4180. The following example demonstrates how a field value would appear in a comma-delimited file:
98 Original field value: Contains "quotes", commas and text
99 Field value in CSV file: "Contains ""quotes"", commas and text"
100 Field values must not contain HTML tags, comments or escape sequences.
101 Remove any extra spaces between fields or field names. Many parsers consider the spaces to be part of the value, which may cause errors.
102 Each line must end with a CRLF or LF linebreak character.
103 Files should be encoded in UTF-8 to support all Unicode characters. Files that include the Unicode byte-order mark (BOM) character are acceptable. See http://unicode.org/faq/utf_bom.html#BOM for more information on the BOM character and UTF-8.
104 All dataset files must be zipped together.
105
106Field Definitions
107agency.txt
108
109File: Required
110Field Name Type Required Description
111agency_id ID Conditionally Required Identifies a transit brand which is often synonymous with a transit agency. Note that in some cases, such as when a single agency operates multiple separate services, agencies and brands are distinct. This document uses the term "agency" in place of "brand". A dataset may contain data from multiple agencies. This field is required when the dataset contains data for multiple transit agencies, otherwise it is optional.
112agency_name Text Required Full name of the transit agency.
113agency_url URL Required URL of the transit agency.
114agency_timezone Timezone Required Timezone where the transit agency is located. If multiple agencies are specified in the dataset, each must have the same agency_timezone.
115agency_lang Language code Optional Primary language used by this transit agency. This field helps GTFS consumers choose capitalization rules and other language-specific settings for the dataset.
116agency_phone Phone number Optional A voice telephone number for the specified agency. This field is a string value that presents the telephone number as typical for the agency's service area. It can and should contain punctuation marks to group the digits of the number. Dialable text (for example, TriMet's "503-238-RIDE") is permitted, but the field must not contain any other descriptive text.
117agency_fare_url URL Optional URL of a web page that allows a rider to purchase tickets or other fare instruments for that agency online.
118agency_email Email Optional Email address actively monitored by the agency’s customer service department. This email address should be a direct contact point where transit riders can reach a customer service representative at the agency.
119stops.txt
120
121File: Required
122Field Name Type Required Description
123stop_id ID Required Identifies a stop, station, or station entrance.
124
125The term "station entrance" refers to both station entrances and station exits. Stops, stations or station entrances are collectively referred to as locations. Multiple routes may use the same stop.
126stop_code Text Optional Short text or a number that identifies the location for riders. These codes are often used in phone-based transit information systems or printed on signage to make it easier for riders to get information for a particular location. The stop_code can be the same as stop_id if it is public facing. This field should be left empty for locations without a code presented to riders.
127stop_name Text Conditionally Required Name of the location. Use a name that people will understand in the local and tourist vernacular.
128
129When the location is a boarding area (location_type=4), the stop_name should contains the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).
130
131Conditionally Required:
132• Required for locations which are stops (location_type=0), stations (location_type=1) or entrances/exits (location_type=2).
133• Optional for locations which are generic nodes (location_type=3) or boarding areas (location_type=4).
134stop_desc Text Optional Description of the location that provides useful, quality information. Do not simply duplicate the name of the location.
135stop_lat Latitude Conditionally Required Latitude of the location.
136
137Conditionally Required:
138• Required for locations which are stops (location_type=0), stations (location_type=1) or entrances/exits (location_type=2).
139• Optional for locations which are generic nodes (location_type=3) or boarding areas (location_type=4).
140stop_lon Longitude Conditionally Required Longitude of the location.
141
142Conditionally Required:
143• Required for locations which are stops (location_type=0), stations (location_type=1) or entrances/exits (location_type=2).
144• Optional for locations which are generic nodes (location_type=3) or boarding areas (location_type=4).
145zone_id ID Conditionally Required Identifies the fare zone for a stop. This field is required if providing fare information using fare_rules.txt, otherwise it is optional. If this record represents a station or station entrance, the zone_id is ignored.
146stop_url URL Optional URL of a web page about the location. This should be different from the agency.agency_url and the routes.route_url field values.
147location_type Enum Optional Type of the location:
148• 0 (or blank): Stop (or Platform). A location where passengers board or disembark from a transit vehicle. Is called a platform when defined within a parent_station.
149• 1: Station. A physical structure or area that contains one or more platform.
150• 2: Entrance/Exit. A location where passengers can enter or exit a station from the street. If an entrance/exit belongs to multiple stations, it can be linked by pathways to both, but the data provider must pick one of them as parent.
151• 3: Generic Node. A location within a station, not matching any other location_type, which can be used to link together pathways define in pathways.txt.
152• 4: Boarding Area. A specific location on a platform, where passengers can board and/or alight vehicles.
153parent_station ID referencing stops.stop_id Conditionally Required Defines hierarchy between the different locations defined in stops.txt. It contains the ID of the parent location, as followed:
154• Stop/platform (location_type=0): the parent_station field contains the ID of a station.
155• Station (location_type=1): this field must be empty.
156• Entrance/exit (location_type=2) or generic node (location_type=3): the parent_station field contains the ID of a station (location_type=1)
157• Boarding Area (location_type=4): the parent_station field contains ID of a platform.
158
159Conditionally Required:
160• Required for locations which are entrances (location_type=2), generic nodes (location_type=3) or boarding areas (location_type=4).
161• Optional for stops/platforms (location_type=0).
162• Forbidden for stations (location_type=1).
163stop_timezone Timezone Optional Timezone of the location. If the location has a parent station, it inherits the parent station’s timezone instead of applying its own. Stations and parentless stops with empty stop_timezone inherit the timezone specified by agency.agency_timezone. If stop_timezone values are provided, the times in stop_times.txt should be entered as the time since midnight in the timezone specified by agency.agency_timezone. This ensures that the time values in a trip always increase over the course of a trip, regardless of which timezones the trip crosses.
164wheelchair_boarding Enum Optional Indicates whether wheelchair boardings are possible from the location. Valid options are:
165
166For parentless stops:
1670 or empty - No accessibility information for the stop.
1681 - Some vehicles at this stop can be boarded by a rider in a wheelchair.
1692 - Wheelchair boarding is not possible at this stop.
170
171For child stops:
1720 or empty - Stop will inherit its wheelchair_boarding behavior from the parent station, if specified in the parent.
1731 - There exists some accessible path from outside the station to the specific stop/platform.
1742 - There exists no accessible path from outside the station to the specific stop/platform.
175
176For station entrances/exits:
1770 or empty - Station entrance will inherit its wheelchair_boarding behavior from the parent station, if specified for the parent.
1781 - Station entrance is wheelchair accessible.
1792 - No accessible path from station entrance to stops/platforms.
180level_id ID referencing levels.level_id Optional Level of the location. The same level can be used by multiple unlinked stations.
181platform_code Text Optional Platform identifier for a platform stop (a stop belonging to a station). This should be just the platform identifier (eg. "G" or "3"). Words like “platform” or "track" (or the feed’s language-specific equivalent) should not be included. This allows feed consumers to more easily internationalize and localize the platform identifier into other languages.
182routes.txt
183
184File: Required
185Field Name Type Required Description
186route_id ID Required Identifies a route.
187agency_id ID referencing agency.agency_id Conditionally required Agency for the specified route. This field is required when the dataset provides data for routes from more than one agency in agency.txt, otherwise it is optional.
188route_short_name Text Conditionally required Short name of a route. This will often be a short, abstract identifier like "32", "100X", or "Green" that riders use to identify a route, but which doesn't give any indication of what places the route serves. Either route_short_name or route_long_name must be specified, or potentially both if appropriate.
189route_long_name Text Conditionally required Full name of a route. This name is generally more descriptive than the route_short_name and often includes the route's destination or stop. Either route_short_name or route_long_name must be specified, or potentially both if appropriate.
190route_desc Text Optional Description of a route that provides useful, quality information. Do not simply duplicate the name of the route. Example: "A" trains operate between Inwood-207 St, Manhattan and Far Rockaway-Mott Avenue, Queens at all times. Also from about 6AM until about midnight, additional "A" trains operate between Inwood-207 St and Lefferts Boulevard (trains typically alternate between Lefferts Blvd and Far Rockaway).
191route_type Enum Required Indicates the type of transportation used on a route. Valid options are:
192
1930 - Tram, Streetcar, Light rail. Any light rail or street level system within a metropolitan area.
1941 - Subway, Metro. Any underground rail system within a metropolitan area.
1952 - Rail. Used for intercity or long-distance travel.
1963 - Bus. Used for short- and long-distance bus routes.
1974 - Ferry. Used for short- and long-distance boat service.
1985 - Cable car. Used for street-level cable cars where the cable runs beneath the car.
1996 - Gondola, Suspended cable car. Typically used for aerial cable cars where the car is suspended from the cable.
2007 - Funicular. Any rail system designed for steep inclines.
201route_url URL Optional URL of a web page about the particular route. Should be different from the agency.agency_url value.
202route_color Color Optional Route color designation that matches public facing material. Defaults to white (FFFFFF) when omitted or left empty. The color difference between route_color and route_text_color should provide sufficient contrast when viewed on a black and white screen.
203route_text_color Color Optional Legible color to use for text drawn against a background of route_color. Defaults to black (000000) when omitted or left empty. The color difference between route_color and route_text_color should provide sufficient contrast when viewed on a black and white screen.
204route_sort_order Non-negative integer Optional Orders the routes in a way which is ideal for presentation to customers. Routes with smaller route_sort_order values should be displayed first.
205trips.txt
206
207File: Required
208Field Name Type Required Description
209route_id ID referencing routes.route_id Required Identifies a route.
210service_id ID referencing calendar.service_id or calendar_dates.service_id Required Identifies a set of dates when service is available for one or more routes.
211trip_id ID Required Identifies a trip.
212trip_headsign Text Optional Text that appears on signage identifying the trip's destination to riders. Use this field to distinguish between different patterns of service on the same route. If the headsign changes during a trip, trip_headsign can be overridden by specifying values for the stop_times.stop_headsign.
213trip_short_name Text Optional Public facing text used to identify the trip to riders, for instance, to identify train numbers for commuter rail trips. If riders do not commonly rely on trip names, leave this field empty. A trip_short_name value, if provided, should uniquely identify a trip within a service day; it should not be used for destination names or limited/express designations.
214direction_id Enum Optional Indicates the direction of travel for a trip. This field is not used in routing; it provides a way to separate trips by direction when publishing time tables. Valid options are:
215
2160 - Travel in one direction (e.g. outbound travel).
2171 - Travel in the opposite direction (e.g. inbound travel).Example: The trip_headsign and direction_id fields could be used together to assign a name to travel in each direction for a set of trips. A trips.txt file could contain these records for use in time tables:
218trip_id,...,trip_headsign,direction_id
2191234,...,Airport,0
2201505,...,Downtown,1
221block_id ID Optional Identifies the block to which the trip belongs. A block consists of a single trip or many sequential trips made using the same vehicle, defined by shared service days and block_id. A block_id can have trips with different service days, making distinct blocks. See the example below
222shape_id ID referencing shapes.shape_id Optional Identifies a geospatial shape describing the vehicle travel path for a trip.
223wheelchair_accessible Enum Optional Indicates wheelchair accessibility. Valid options are:
224
2250 or empty - No accessibility information for the trip.
2261 - Vehicle being used on this particular trip can accommodate at least one rider in a wheelchair.
2272 - No riders in wheelchairs can be accommodated on this trip.
228bikes_allowed Enum Optional Indicates whether bikes are allowed. Valid options are:
229
2300 or empty - No bike information for the trip.
2311 - Vehicle being used on this particular trip can accommodate at least one bicycle.
2322 - No bicycles are allowed on this trip.
233Example: Blocks and service day
234
235The example below is valid, with distinct blocks every day of the week.
236route_id trip_id service_id block_id (first stop time) (last stop time)
237red trip_1 mon-tues-wed-thurs-fri-sat-sun red_loop 22:00:00 22:55:00
238red trip_2 fri-sat-sun red_loop 23:00:00 23:55:00
239red trip_3 fri-sat red_loop 24:00:00 24:55:00
240red trip_4 mon-tues-wed-thurs red_loop 20:00:00 20:50:00
241red trip_5 mon-tues-wed-thurs red_loop 21:00:00 21:50:00
242
243Notes on above table:
244
245 On Friday into Saturday morning, for example, a single vehicle operates trip_1, trip_2, and trip_3 (10:00 PM through 12:55 AM). Note that the last trip occurs on Saturday, 12:00 AM to 12:55 AM, but is part of the Friday “service day” because the times are 24:00:00 to 24:55:00.
246 On Monday, Tuesday, Wednesday, and Thursday, a single vehicle operates trip_1, trip_4, and trip_5 in a block from 8:00 PM to 10:55 PM.
247
248stop_times.txt
249
250File: Required
251Field Name Type Required Description
252trip_id ID referencing trips.trip_id Required Identifies a trip.
253arrival_time Time Conditionally required Arrival time at a specific stop for a specific trip on a route. If there are not separate times for arrival and departure at a stop, enter the same value for arrival_time and departure_time. For times occurring after midnight on the service day, enter the time as a value greater than 24:00:00 in HH:MM:SS local time for the day on which the trip schedule begins.
254
255Scheduled stops where the vehicle strictly adheres to the specified arrival and departure times are timepoints. If this stop is not a timepoint, it is recommended to provide an estimated or interpolated time. If this is not available, arrival_time can be left empty. Further, indicate that interpolated times are provided with timepoint=0. If interpolated times are indicated with timepoint=0, then time points must be indicated with timepoint=1. Provide arrival times for all stops that are time points. An arrival time must be specified for the first and the last stop in a trip.
256departure_time Time Conditionally required Departure time from a specific stop for a specific trip on a route. For times occurring after midnight on the service day, enter the time as a value greater than 24:00:00 in HH:MM:SS local time for the day on which the trip schedule begins. If there are not separate times for arrival and departure at a stop, enter the same value for arrival_time and departure_time. See the arrival_time description for more details about using timepoints correctly.
257
258The departure_time field should specify time values whenever possible, including non-binding estimated or interpolated times between timepoints.
259stop_id ID referencing stops.stop_id Required Identifies the serviced stop. All stops serviced during a trip must have a record in stop_times.txt. Referenced locations must be stops, not stations or station entrances. A stop may be serviced multiple times in the same trip, and multiple trips and routes may service the same stop.
260stop_sequence Non-negative integer Required Order of stops for a particular trip. The values must increase along the trip but do not need to be consecutive.Example: The first location on the trip could have a stop_sequence=1, the second location on the trip could have a stop_sequence=23, the third location could have a stop_sequence=40, and so on.
261stop_headsign Text Optional Text that appears on signage identifying the trip's destination to riders. This field overrides the default trips.trip_headsign when the headsign changes between stops. If the headsign is displayed for an entire trip, use trips.trip_headsign instead.
262
263A stop_headsign value specified for one stop_time does not apply to subsequent stop_times in the same trip. If you want to override the trip_headsign for multiple stop_times in the same trip, the stop_headsign value must be repeated in each stop_time row.
264pickup_type Enum Optional Indicates pickup method. Valid options are:
265
2660 or empty - Regularly scheduled pickup.
2671 - No pickup available.
2682 - Must phone agency to arrange pickup.
2693 - Must coordinate with driver to arrange pickup.
270drop_off_type Enum Optional Indicates drop off method. Valid options are:
271
2720 or empty - Regularly scheduled drop off.
2731 - No drop off available.
2742 - Must phone agency to arrange drop off.
2753 - Must coordinate with driver to arrange drop off.
276shape_dist_traveled Non-negative float Optional Actual distance traveled along the associated shape, from the first stop to the stop specified in this record. This field specifies how much of the shape to draw between any two stops during a trip. Must be in the same units used in shapes.txt. Values used for shape_dist_traveled must increase along with stop_sequence; they cannot be used to show reverse travel along a route.Example: If a bus travels a distance of 5.25 kilometers from the start of the shape to the stop,shape_dist_traveled=5.25.
277timepoint Enum Optional Indicates if arrival and departure times for a stop are strictly adhered to by the vehicle or if they are instead approximate and/or interpolated times. This field allows a GTFS producer to provide interpolated stop-times, while indicating that the times are approximate. Valid options are:
278
2790 - Times are considered approximate.
2801 or empty - Times are considered exact.
281calendar.txt
282
283File: Conditionally required
284Field Name Type Required Description
285service_id ID Required Uniquely identifies a set of dates when service is available for one or more routes. Each service_id value can appear at most once in a calendar.txt file.
286monday Enum Required Indicates whether the service operates on all Mondays in the date range specified by the start_date and end_date fields. Note that exceptions for particular dates may be listed in calendar_dates.txt. Valid options are:
287
2881 - Service is available for all Mondays in the date range.
2890 - Service is not available for Mondays in the date range.
290tuesday Enum Required Functions in the same way as monday except applies to Tuesdays
291wednesday Enum Required Functions in the same way as monday except applies to Wednesdays
292thursday Enum Required Functions in the same way as monday except applies to Thursdays
293friday Enum Required Functions in the same way as monday except applies to Fridays
294saturday Enum Required Functions in the same way as monday except applies to Saturdays.
295sunday Enum Required Functions in the same way as monday except applies to Sundays.
296start_date Date Required Start service day for the service interval.
297end_date Date Required End service day for the service interval. This service day is included in the interval.
298calendar_dates.txt
299
300File: Conditionally required
301
302The calendar_dates.txt table can explicitly activate or disable service by date. It can be used in two ways.
303
304 Recommended: Use calendar_dates.txt in conjunction with calendar.txt to define exceptions to the default service patterns defined in calendar.txt. If service is generally regular, with a few changes on explicit dates (for instance, to accommodate special event services, or a school schedule), this is a good approach. In this case calendar_dates.service_id is an ID referencing calendar.service_id.
305 Alternate: Omit calendar.txt, and specify each date of service in calendar_dates.txt. This allows for considerable service variation and accommodates service without normal weekly schedules. In this case service_id is an ID.
306
307Field Name Type Required Description
308service_id ID referencing calendar.service_id or ID Required Identifies a set of dates when a service exception occurs for one or more routes. Each (service_id, date) pair can only appear once in calendar_dates.txt if using calendar.txt and calendar_dates.txt in conjunction. If a service_id value appears in both calendar.txt and calendar_dates.txt, the information in calendar_dates.txt modifies the service information specified in calendar.txt.
309date Date Required Date when service exception occurs.
310exception_type Enum Required Indicates whether service is available on the date specified in the date field. Valid options are:
311
3121 - Service has been added for the specified date.
3132 - Service has been removed for the specified date.Example: Suppose a route has one set of trips available on holidays and another set of trips available on all other days. One service_id could correspond to the regular service schedule and another service_id could correspond to the holiday schedule. For a particular holiday, the calendar_dates.txt file could be used to add the holiday to the holiday service_id and to remove the holiday from the regular service_id schedule.
314fare_attributes.txt
315
316File: Optional
317Field Name Type Required Description
318fare_id ID Required Identifies a fare class.
319price Non-negative float Required Fare price, in the unit specified by currency_type.
320currency_type Currency code Required Currency used to pay the fare.
321payment_method Enum Required Indicates when the fare must be paid. Valid options are:
322
3230 - Fare is paid on board.
3241 - Fare must be paid before boarding.
325transfers Enum Required Indicates the number of transfers permitted on this fare. The fact that this field can be left empty is an exception to the requirement that a Required field must not be empty. Valid options are:
326
3270 - No transfers permitted on this fare.
3281 - Riders may transfer once.
3292 - Riders may transfer twice.
330empty - Unlimited transfers are permitted.
331agency_id ID referencing agency.agency_id Conditionally Required Identifies the relevant agency for a fare. This field is required for datasets with multiple agencies defined in agency.txt, otherwise it is optional.
332transfer_duration Non-negative integer Optional Length of time in seconds before a transfer expires. When transfers=0 this field can be used to indicate how long a ticket is valid for or it can can be left empty.
333fare_rules.txt
334
335File: Optional
336
337The fare_rules.txt table specifies how fares in fare_attributes.txt apply to an itinerary. Most fare structures use some combination of the following rules:
338
339 Fare depends on origin or destination stations.
340 Fare depends on which zones the itinerary passes through.
341 Fare depends on which route the itinerary uses.
342
343For examples that demonstrate how to specify a fare structure with fare_rules.txt and fare_attributes.txt, see https://code.google.com/p/googletransitdatafeed/wiki/FareExamples in the GoogleTransitDataFeed open source project wiki.
344Field Name Type Required Description
345fare_id ID referencing fare_attributes.fare_id Required Identifies a fare class.
346route_id ID referencing routes.route_id Optional Identifies a route associated with the fare class. If several routes with the same fare attributes exist, create a record in fare_rules.txt for each route.Example: If fare class "b" is valid on route "TSW" and "TSE", the fare_rules.txt file would contain these records for the fare class:
347fare_id,route_id
348b,TSW
349b,TSE
350origin_id ID referencing stops.zone_id Optional Identifies an origin zone. If a fare class has multiple origin zones, create a record in fare_rules.txt for each origin_id.Example: If fare class "b" is valid for all travel originating from either zone "2" or zone "8", the fare_rules.txt file would contain these records for the fare class:
351fare_id,...,origin_id
352b,...,2
353b,...,8
354destination_id ID referencing stops.zone_id Optional Identifies a destination zone. If a fare class has multiple destination zones, create a record in fare_rules.txt for each destination_id.Example: The origin_id and destination_id fields could be used together to specify that fare class "b" is valid for travel between zones 3 and 4, and for travel between zones 3 and 5, the fare_rules.txt file would contain these records for the fare class:
355fare_id,...,origin_id,destination_id
356b,...,3,4
357b,...,3,5
358contains_id ID referencing stops.zone_id Optional Identifies the zones that a rider will enter while using a given fare class. Used in some systems to calculate correct fare class. Example: If fare class "c" is associated with all travel on the GRT route that passes through zones 5, 6, and 7 the fare_rules.txt would contain these records:
359fare_id,route_id,...,contains_id
360c,GRT,...,5
361c,GRT,...,6
362c,GRT,...,7
363Because all contains_id zones must be matched for the fare to apply, an itinerary that passes through zones 5 and 6 but not zone 7 would not have fare class "c". For more detail, see https://code.google.com/p/googletransitdatafeed/wiki/FareExamples in the GoogleTransitDataFeed project wiki.
364shapes.txt
365
366File: Optional
367
368Shapes describe the path that a vehicle travels along a route alignment, and are defined in the file shapes.txt. Shapes are associated with Trips, and consist of a sequence of points through which the vehicle passes in order. Shapes do not need to intercept the location of Stops exactly, but all Stops on a trip should lie within a small distance of the shape for that trip, i.e. close to straight line segments connecting the shape points.
369Field Name Type Required Description
370shape_id ID Required Identifies a shape.
371shape_pt_lat Latitude Required Latitude of a shape point. Each record in shapes.txt represents a shape point used to define the shape.
372shape_pt_lon Longitude Required Longitude of a shape point.
373shape_pt_sequence Non-negative integer Required Sequence in which the shape points connect to form the shape. Values must increase along the trip but do not need to be consecutive.Example: If the shape "A_shp" has three points in its definition, the shapes.txt file might contain these records to define the shape:
374shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence
375A_shp,37.61956,-122.48161,0
376A_shp,37.64430,-122.41070,6
377A_shp,37.65863,-122.30839,11
378shape_dist_traveled Non-negative float Optional Actual distance traveled along the shape from the first shape point to the point specified in this record. Used by trip planners to show the correct portion of the shape on a map. Values must increase along with shape_pt_sequence; they cannot be used to show reverse travel along a route. Distance units must be consistent with those used in stop_times.txt.Example: If a bus travels along the three points defined above for A_shp, the additional shape_dist_traveled values (shown here in kilometers) would look like this:
379shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled
380A_shp,37.61956,-122.48161,0,0
381A_shp,37.64430,-122.41070,6,6.8310
382A_shp,37.65863,-122.30839,11,15.8765
383frequencies.txt
384
385File: Optional
386
387Frequencies.txt represents trips that operate on regular headways (time between trips). This file can be used to represent two different types of service.
388
389 Frequency-based service (exact_times=0) in which service does not follow a fixed schedule throughout the the day. Instead, operators attempt to strictly maintain predetermined headways for trips.
390 A compressed representation of schedule-based service (exact_times=1) that has the exact same headway for trips over specified time period(s). In schedule-based service operators try to strictly adhere to a schedule.
391
392Field Name Type Required Description
393trip_id ID referencing trips.trip_id Required Identifies a trip to which the specified headway of service applies.
394start_time Time Required Time at which the first vehicle departs from the first stop of the trip with the specified headway.
395end_time Time Required Time at which service changes to a different headway (or ceases) at the first stop in the trip.
396headway_secs Non-negative integer Required Time, in seconds, between departures from the same stop (headway) for the trip, during the time interval specified by start_time and end_time. Multiple headways for the same trip are allowed, but may not overlap. New headways may start at the exact time the previous headway ends.
397exact_times Enum Optional Indicates the type of service for a trip. See the file description for more information. Valid options are:
398
3990 or empty - Frequency-based trips.
4001 - Schedule-based trips with the exact same headway throughout the day. In this case the end_time value must be greater than the last desired trip start_time but less than the last desired trip start_time + headway_secs.
401transfers.txt
402
403File: Optional
404
405When calculating an itinerary, GTFS-consuming applications interpolate transfers based on allowable time and stop proximity. Transfers.txt specifies additional rules and overrides for selected transfers.
406Field Name Type Required Description
407from_stop_id ID referencing stops.stop_id Required Identifies a stop or station where a connection between routes begins. If this field refers to a station, the transfer rule applies to all its child stops.
408to_stop_id ID referencing stops.stop_id Required Identifies a stop or station where a connection between routes ends. If this field refers to a station, the transfer rule applies to all child stops.
409transfer_type Enum Required Indicates the type of connection for the specified (from_stop_id, to_stop_id) pair. Valid options are:
410
4110 or empty - Recommended transfer point between routes.
4121 - Timed transfer point between two routes. The departing vehicle is expected to wait for the arriving one and leave sufficient time for a rider to transfer between routes.
4132 - Transfer requires a minimum amount of time between arrival and departure to ensure a connection. The time required to transfer is specified by min_transfer_time.
4143 - Transfers are not possible between routes at the location.
415min_transfer_time Non-negative integer Optional Amount of time, in seconds, that must be available to permit a transfer between routes at the specified stops. The min_transfer_time should be sufficient to permit a typical rider to move between the two stops, including buffer time to allow for schedule variance on each route.
416pathways.txt
417
418File: Optional
419
420The GTFS-Pathways extension uses a graph representation to describe subway or train, with nodes (the locations) and edges (the pathways).
421
422To go from the entrance (which is a node represented as a location with location_type=2) to a platform (which is a node represented as a location with location_type=0), the rider will go through walkway, fare gates, stairs, etc (which are edges represented as pathways). The proposal also adds another type of location, a generic one called "generic node", to represent for example a walkway crossing from which different walkways can be taken.
423
424Warning: Pathways must be exhaustive in a station. As consequence, as soon as one platform (as stop), entrance or node belonging to a station has a pathway linked to it, the station is assumed to have exhaustive description of its pathways. Therefore, the following common sense rules apply: - No dangling location: If any location within a station has a pathway, then all locations should have pathways (except for those platforms that have boarding areas). - No locked platforms: Each platform must be connected to at least one entrance via some chain of pathways. There are very rare stations in the real life where you cannot go outside. - No pathways for a platform with boarding areas: A platform that has boarding areas is treated as a parent object, not a point. It may not have pathways assigned. All pathways should be for boarding areas.
425Field Name Type Required Description
426pathway_id ID Required The pathway_id field contains an ID that uniquely identifies the pathway. The pathway_id is used by systems as an internal identifier of this record (e.g., primary key in database), and therefore the pathway_id must be dataset unique.
427Different pathways can go from the same from_stop_id to the same to_stop_id. For example, this happens when two escalators are side by side in opposite direction, or when a stair is nearby and elevator and both go from the same place to the same place.
428from_stop_id ID referencing stops.stop_id Required Location at which the pathway begins. It contains a stop_id that identifies a platform, entrance/exit, generic node or boarding area from the stops.txt file.
429to_stop_id ID referencing stops.stop_id Required Location at which the pathway ends. It contains a stop_id that identifies a platform, entrance/exit, generic node or boarding area from the stops.txt file.
430pathway_mode Enum Required Type of pathway between the specified (from_stop_id, to_stop_id) pair. Valid values for this field are:
431• 1: walkway
432• 2: stairs
433• 3: moving sidewalk/travelator
434• 4: escalator
435• 5: elevator
436• 6: fare gate (or payment gate): A pathway that crosses into an area of the station where a proof of payment is required (usually via a physical payment gate).
437Fare gates may either separate paid areas of the station from unpaid ones, or separate different payment areas within the same station from each other. This information can be used to avoid routing passengers through stations using shortcuts that would require passengers to make unnecessary payments, like directing a passenger to walk through a subway platform to reach a busway.
438• 7: exit gate: Indicates a pathway exiting an area where proof-of-payment is required into an area where proof-of-payment is no longer required.
439is_bidirectional Enum Required Indicates in which direction the pathway can be used:
440• 0: Unidirectional pathway, it can only be used from from_stop_id to to_stop_id.
441• 1: Bidirectional pathway, it can be used in the two directions.
442
443Fare gates (pathway_mode=6) and exit gates (pathway_mode=7) cannot be bidirectional.
444length Non-negative Float Optional Horizontal length in meters of the pathway from the origin location (defined in from_stop_id) to the destination location (defined in to_stop_id).
445
446This field is recommended for walkways (pathway_mode=1), fare gates (pathway_mode=6) and exit gates (pathway_mode=7).
447traversal_time Positive Integer Optional Average time in seconds needed to walk through the pathway from the origin location (defined in from_stop_id) to the destination location (defined in to_stop_id).
448
449This field is recommended for moving sidewalks (pathway_mode=3), escalators (pathway_mode=4) and elevator (pathway_mode=5).
450stair_count Non-null Integer Optional Number of stairs of the pathway.
451
452Best Practices: one could use the approximation of 1 floor = 15 stairs to generate approximative values.
453
454A positive stair_count implies that the rider walk up from from_stop_id to to_stop_id. And a negative stair_count implies that the rider walk down from from_stop_id to to_stop_id.
455
456This field is recommended for stairs (pathway_mode=2).
457max_slope Float Optional Maximum slope ratio of the pathway. Valid values for this field are:
458• 0 or (empty): no slope.
459• A float: slope ratio of the pathway, positive for upwards, negative for downwards.
460
461This field should be used only with walkways (pathway_type=1) and moving sidewalks (pathway_type=3).
462
463Example: In the US, 0.083 (also written 8.3%) is the maximum slope ratio for hand-propelled wheelchair, which mean an increase of 0.083m (so 8.3cm) for each 1m.
464min_width Positive Float Optional Minimum width of the pathway in meters.
465
466This field is highly recommended if the minimum width is less than 1 meter.
467signposted_as Text Optional String of text from physical signage visible to transit riders. The string can be used to provide text directions to users, such as 'follow signs to '. The language text should appear in this field exactly how it is printed on the signs - it should not be translated.
468reversed_signposted_as Text Optional Same than the signposted_as field, but when the pathways is used backward, i.e. from the to_stop_id to the from_stop_id.
469levels.txt
470
471File: Optional
472
473Describe the different levels of a station. Is mostly useful when used in conjunction with pathways.txt, and is required for elevator (pathway_mode=5) to ask the user to take the elevator to the “Mezzanine” or the “Platform” level.
474Field Name Type Required Description
475level_id ID Required Id of the level that can be referenced from stops.txt.
476level_index Float Required Numeric index of the level that indicates relative position of this level in relation to other levels (levels with higher indices are assumed to be located above levels with lower indices).
477
478Ground level should have index 0, with levels above ground indicated by positive indices and levels below ground by negative indices.
479level_name Text Optional Optional name of the level (that matches level lettering/numbering used inside the building or the station). Is useful for elevator routing (e.g. “take the elevator to level “Mezzanine” or “Platforms” or “-1”).
480feed_info.txt
481
482File: Optional
483
484The file contains information about the dataset itself, rather than the services that the dataset describes. Note that, in some cases, the publisher of the dataset is a different entity than any of the agencies.
485Field Name Type Required Description
486feed_publisher_name Text Required Full name of the organization that publishes the dataset. This may be the same as one of the agency.agency_name values.
487feed_publisher_url URL Required URL of the dataset publishing organization's website. This may be the same as one of the agency.agency_url values.
488feed_lang Language code Required Default language used for the text in this dataset. This setting helps GTFS consumers choose capitalization rules and other language-specific settings for the dataset.
489feed_start_date Date Optional The dataset provides complete and reliable schedule information for service in the period from the beginning of the feed_start_date day to the end of the feed_end_date day. Both days can be left empty if unavailable. The feed_end_date date must not precede the feed_start_date date if both are given. Dataset providers are encouraged to give schedule data outside this period to advise of likely future service, but dataset consumers should treat it mindful of its non-authoritative status. If feed_start_date or feed_end_date extend beyond the active calendar dates defined in calendar.txt and calendar_dates.txt, the dataset is making an explicit assertion that there is no service for dates within the feed_start_date or feed_end_date range but not included in the active calendar dates.
490feed_end_date Date Optional (see above)
491feed_version Text Optional String that indicates the current version of their GTFS dataset. GTFS-consuming applications can display this value to help dataset publishers determine whether the latest dataset has been incorporated.
492feed_contact_email Email Optional Email address for communication regarding the GTFS dataset and data publishing practices. feed_contact_email is a technical contact for GTFS-consuming applications. Provide customer service contact information through agency.txt.
493feed_contact_url URL Optional URL for contact information, a web-form, support desk, or other tools for communication regarding the GTFS dataset and data publishing practices. feed_contact_url is a technical contact for GTFS-consuming applications. Provide customer service contact information through agency.txt.
494
495implementacja automatu ile bylo startow ile stopow