For even more detail, refer to gtfs.org
Dataset: The contents of a feed. The feed itself is static and stays in a single location with a single name, but the contents change with each update that results from new datasets.
Feed: The actual GTFS itself, not the data within it. The feed stays at a single location, but gets updated with new datasets (see above.)
GTFS+: A term that is often applied to experimental or extensible files and fields in GTFS. Learn more about additional fields and files.
Validation: New datasets should be validated before being pushed to the feed to ensure no errors or mistakes have been made in either the data, or the files themselves. There are several open-source validators available, but all require some technical proficiency. All major applications will perform some kind of validation on new datasets pushed to feeds when they attempt to 'ingest' them. Notably, Google Maps will notify you if your feed fails validation when you attempt to upload it, along with what has caused it to fail.
Agency: GTFS only allows for a single entity to be the rider-facing representative of a service. In some cases, the operator, funder, administrator, and governing body are all called separate things, and may all have relevance to different parties. The key thing is to select the name riders will recognize, whether this is a branded service name, the operator's public name, or the name of the city or county who 'runs' the service.
Zone: Zones are applied to stops to facilitate fare rules (see below.) Stops can only be described with a single zone, so if a stop has a variable zone based on whether a rider is boarding, or offboarding, at the stop, multiple stops may need to be created at the exact same location to account for this kind of fare structure.
Alignment: The path of travel a vehicle takes along the course of a trip. Also called the shape.
Block: The vehicle assignment for a trip. Does not correspond to a distinct, physical vehicle - it is the stand-in for connecting multiple trips that will be serviced by the same vehicle. Driver assignment is not described by a block unless the driver and vehicle assignments are the same. See Operations and GTFS.
Calendar: A way to describe a particular slate of schedules, or a single bid. Calendars in GTFS can be described using either service periods (for regularly scheduled services, like weekday and Saturday services) or distinct service descriptions for every day of the year (for services that do not easily fit into regular schedules, or to account for lots of service variation,)
Direction: A value of either 0 or 1 (binary) to describe pairs of service within a route's trips, such as Inbound and Outbound, or Northbound and Southbound. Can also be used to describe a loop by leaving blank, or describing all trips on that route as 0. There is no way to describe three or more directions on a single route's trips.
Headsign: Headsign gets used a variety of ways in GTFS, depending on the consuming application and whether a trip requires further detail than a single value (such as a loop route.) Headsigns should describe destination information to riders, and can do so at the trip level (a single headsign for the whole trip, such as "Downtown") or at the stop level (where headsign values change based on where in the trip a rider boards the vehicle.) Some applications use headsign as proxy for direction, or pattern (stops serviced.) GTFS defines the headsign more narrowly, going so far as to defining it as matching the physical signage/scroll visible on the front of the vehicle.
Service Exception: A way to describe expected service modifications, such as holiday service, service cancellation, added service, or special event services, These are used along with calendars to create
Fare Rule: An entry that defines when a fare should be applied to a trip, such as by route, or zone.
AFC: Automatic Fare Collection. Technology that allows for electronic fare payment and collection, such as "tap on" cards.
APC: Automatic Passenger Counting/Automatic People Counter. Technology that allows for passenger counting and vehicle capacity information gathering.
AVL: Automatic Vehicle Location. Technology for locating vehicles and broadcasting or recording their locations. Usually involves on-board GPS and some sort of communications equipment to send vehicle locations back to a central system. The information is used to track on-time performance of vehicles and their operators, and for predicted arrival systems and apps.
Consumer: A piece of software or application that 'reads' or 'ingests' a piece of data, such as GTFS. Common GTFS consumers include applications like Google Maps and Transit App, as well as software tools like many CAD/AVL tools. Additionally, the term may be used to generally refer to technology, sectors, or entire companies/organizations. With the GTFS community hosted on Google/Transit, for changes to the specification to be accepted, a representative of a GTFS consumer must vote for the change.
Producer: Broadly refering to the party responsible for creating, sharing and hosting a piece of data, such as GTFS. Common GTFS producers include in-house staff at transit agencies, third party vendors, consultants or software company that produce GTFS, or as a by-product of another data source (such as a CAD/AVL GTFS-rt feed that also generates a static GTFS.) With the GTFS community hosted on Google/Transit, for changes to the specification to be accepted, a representative of a GTFS producer must vote for the change.
Deviated-Fixed Route: A route that can service certain zones, areas, or boundaries off the main path of travel of the bus. Common use case is a route that can 'deviate' 1/4 mi in any direction from the 'fixed' part of the route to provide additional service to unmarked or on-demand stops. Often pickups require calls in advance, and drop offs must be coordinated with the driver.
Fixed Route: A route that sticks to a defined path of travel and sequence of stops. Fixed routes can have variations throughout the day, such as abbreviated/shortened trips at the start and end of the day, but the overall stops serviced remains relatively 'fixed' throughout the service day.
Flag Stop: A stop that is unmarked but allowable for pickup or drop off. GTFS does not differentiate at the stop level whether a stop is on demand/flag, or always serviced - that level of detail is described per-trip. Stops that are always on demand only must have pickup and drop off restrictions included in stop_times.txt when they appear in trips, and must be included in trips in order to show up on trip planning applications. A stop that is included in a GTFS, but not included on any trips, will not be visible in any meaningful way for riders.
Manifest: Used in Paratransit to lay out all the passengers that need to be transported and Trips to be made. In rural fixed-route systems, manifests are often used to let drivers know about any customers that will be at On-Demand Stops.
Dwell: A period of time between an arrival and a departure, which can be described in GTFS by having a separate arrival time from the departure time. Best described for longer dwells (>5 minutes) where riders would benefit from a different offboarding or onboarding time to catch this trip (eg, a bus that arrives at the mall at 11:00 and departs at 11:15 will tell a rider going to the mall they will get to their destination at 11:00, while telling a rider leaving the mall to board at 11:15, not 11:00.)
Frequency: Frequency in GTFS is used to describe trips that are no exact and instead headway-based. A GTFS using frequencies will indicate that service is happening at a regular interval without providing exact stop times. Trip planning applications may choose to describe these trips using language like "service every 20 minutes" instead of describing an exact stop time a rider should get to a stop to board a vehicle.
Headway: The interval of time between buses, or the interval of time between stops. Often used to describe frequency of service, such as "20 minute headways" indicating that buses service a stop every 20 minutes.
Interlinging: When a vehicle or block services more than one route in a service day. Blocks allow applications to 'see' when trips can be connected across routes, potentially giving riders information about possible trips with no transfer necessary.
Interpolated Time: A stop time that is inserted, either by machine or by hand, that is an approximate stop time between two defined stop times. Many applications require every stop have a stop time associated with it, but only timepoints have defined stop times. Interpolation allows riders to see more accurate stop times between timepoints (rather than only seeing the last available stop time.)
Loop/True Loop: Because GTFS allows trips to be described in pairs (such as Inbound and Outbound) using direction, a loop should only be employed to describe service when it lacks any defined directionality (like North or South) and stops are rarely, or never, serviced in two or more directions on a single street. Applications that are gathering a rider's location will have difficulty describing which stop a rider should use if a trip is a loop and servicing stops on both sides of a street. A rider may be told to board at a stop heading Outbound when they actually want to go Inbound, but that information is obscured because both stops just indicate they are heading the same direction, which is 'loop.' Even loops that are serviced in clockwise and counterclockwise fashion by vehicles can be described in binary (clockwise can be 0, counterclockwise can be 1.) Additionally, loops require that the first and last stop of the trip be the same stop (unless using multiple bays at a station or depot.)