GTFS: Public Transit Schedule and Location Data for GIS and Routing
GTFS, the General Transit Feed Specification, is an open data standard for describing public transportation services in machine-readable form. A typical GTFS Schedule feed connects agencies, stops, routes, trips, stop times, service calendars, and geographic shapes in a collection of comma-separated text files distributed as a ZIP archive. GTFS Realtime extends the ecosystem with vehicle positions, trip updates, and service alerts. GTFS is not one global dataset with fixed geographic coverage or a single license. Instead, it is a common specification used by transit agencies, public authorities, vendors, and data aggregators, with coverage, update frequency, completeness, and licensing determined by each feed publisher.
GTFS is one of the most important interoperability standards in the transit and location-data ecosystem. It turns a transit operator’s service information into linked tables that mapping systems, trip planners, accessibility tools, researchers, and GIS analysts can process consistently. The standard is designed around the physical and temporal structure of public transportation: agencies operate routes; routes contain trips; trips visit stops; stop times describe when vehicles arrive and depart; calendars determine when those services operate. GTFS also supports geographic shapes, station entrances, pathways, fares, transfers, translations, demand-responsive service, and other extensions. The official documentation describes GTFS Schedule and GTFS Realtime as separate but related formats. (github.com)
How EDK fits
For: Transit agencies, GIS professionals, transportation planners, mapping and routing developers, researchers, civic-data teams, accessibility analysts, and anyone who needs structured information about where public transportation operates and when it is scheduled to run.
GTFS is a focused representation of one important part of the physical world: public transportation infrastructure and service. Its stop locations, station hierarchies, route paths, service calendars, and scheduled movements can be related to roads, buildings, neighborhoods, employment centers, schools, public facilities, and other geographic features. In an E2-style world model, GTFS is most useful as a transit layer that helps explain how people and vehicles connect physical places over time. The strongest connection is not that GTFS replaces a world model or provides every element needed for routing. Rather, GTFS supplies structured transit observations that can be combined with broader geographic context and computed across space and time.
- •Combine GTFS stops, stations, pathways, and route shapes with roads, buildings, neighborhoods, public facilities, and other physical features to identify which places are served by transit and how service reaches them.
- •Measure and compare transit accessibility by calculating proximity, catchment areas, transfer opportunities, service frequency, or scheduled travel patterns around geographic features, while preserving the feed’s service dates and publisher-specific limitations.
- •Use GTFS as a time-aware transportation layer when analyzing changes to the physical environment, such as new construction, infrastructure projects, population growth, or public-asset locations near existing or proposed transit service.
Dataset profile
Formats
ZIP archive of comma-delimited text files with .txt extensions for GTFS Schedule
Protocol Buffers encoded according to gtfs-realtime.proto for GTFS Realtime
GeoJSON for certain GTFS Flex demand-responsive locations
Optional CSV-style files for shapes, fares, transfers, pathways, levels, translations, and feed metadata
Access methods
Direct download from a transit agency or transportation authority
Stable public feed URL suitable for automated retrieval
Publisher-controlled API or access endpoint, sometimes requiring an API key
GTFS and multimodal data aggregators listed through the GTFS ecosystem
Realtime endpoint serving Protocol Buffer messages
Quality and limits
GTFS is a specification, not a guarantee that a feed is complete, current, accurate, or internally consistent.
Geographic coverage, coordinate accuracy, route shapes, accessibility attributes, fares, transfers, and station pathways vary by publisher.
Static schedules describe planned service and may not reflect cancellations, delays, detours, vehicle positions, or other real-world conditions.
Service calendars and exceptions require date-aware processing; comparing feeds without aligning effective dates can produce misleading results.
Optional files may be missing even when an application depends on them.
A stop point or route shape is not automatically a complete pedestrian, road, address, or operational network.
The specification license does not determine the license of each individual feed.
Analysis workflows
Acquire and preserve the original feed URL, publisher, download timestamp, feed version, service date range, and license information.
Unzip and validate the static feed, checking required files, field names, identifiers, foreign-key relationships, duplicate records, coordinate ranges, timezones, and calendar consistency.
Load stops and stations as point layers and shapes as line layers when available; join them to routes, trips, and stop times using stable identifiers.
Filter trips and stop times by a target service date, weekday, time window, route type, agency, or service pattern before calculating frequency or accessibility measures.
Create stop catchments or proximity analyses, then distinguish straight-line screening from network-based walking or multimodal accessibility.
Analyze transfers, station entrances, pathways, fares, and demand-responsive zones only when the relevant optional files are present and validated.
Combine GTFS with roads, pedestrian networks, buildings, population, employment, public facilities, or other location data for broader physical-world analysis.
Incorporate GTFS Realtime separately, retaining timestamps and feed snapshots so planned schedules are not confused with observed or reported conditions.
Document publisher-specific limitations and license terms before publishing maps, derived datasets, routing results, or commercial applications.
Value inside EDK
What GTFS contains
A GTFS Schedule dataset is a collection of related text files. The required or foundational files identify the transit agency, routes, trips, stops, stop times, and service dates. In practical terms, agency.txt identifies the organization; stops.txt stores stop, station, and entrance locations; routes.txt describes passenger-facing services; trips.txt links individual vehicle journeys to routes and service patterns; and stop_times.txt records arrival and departure times for each trip. calendar.txt and calendar_dates.txt describe recurring service and date-specific additions or exceptions. (gtfs.org)
Optional files extend the model. shapes.txt can represent the geographic path followed by a trip. transfers.txt can describe transfer relationships, while pathways.txt and levels.txt can support more detailed station navigation. Fare-related files represent products, media, rules, and transfer conditions. translations.txt supports multilingual presentation, and feed_info.txt supplies metadata about the feed itself. GTFS Flex, now part of the official specification, supports discovery of demand-responsive transportation using zones, booking rules, and related structures. (gtfs.org)
- •Static schedule entities: agencies, stops, stations, routes, trips, calendars, and stop times.
- •Geographic and rider-facing additions: shapes, route colors, pathways, levels, translations, and station entrances.
- •Fare and transfer structures: fare products, fare media, fare rules, leg rules, and transfers.
- •Demand-responsive features: locations, zones, booking rules, and service patterns supported by GTFS Flex.
- •Realtime entities: trip updates, service alerts, and vehicle positions.
Geography, temporal coverage, and update cadence
GTFS has no fixed global geography. Each feed covers the service area selected by its publisher: a single municipal operator, a regional transportation authority, a group of agencies, or a broader national or metropolitan aggregation. A feed may represent bus, rail, tram, ferry, cable-car, demand-responsive, or other supported modes. The geographic precision also varies. Stops normally include latitude and longitude, while shapes may provide a detailed route path, but not every feed contains shapes or equally detailed station and pathway information. (gtfs.org)
GTFS is inherently time-dependent. Service calendars contain start and end dates, weekly operating patterns, and exceptions for holidays or special service. A current feed may include upcoming service, and the official reference recommends publishing current and upcoming service through a stable feed location. The specification recommends that a feed be valid for at least the next seven days and, where possible, cover at least the next 30 days, but these are publishing practices rather than a guarantee that every producer follows them. (gtfs.org)
- •Geographic extent is publisher-specific rather than global by default.
- •Static feeds describe scheduled service over defined service dates.
- •Realtime feeds are separate and may have different availability and reliability.
- •Feed version, modification date, and service-calendar range should be preserved in an analytical workflow.
- •A feed’s stop locations and shapes describe transit data, not necessarily the complete pedestrian, road, or rail infrastructure around them.
Formats and access methods
The standard GTFS Schedule distribution is a ZIP archive containing comma-delimited files saved with a .txt extension. The files use defined field names and identifiers such as agency_id, stop_id, route_id, trip_id, service_id, and shape_id to connect records. Consumers typically download the archive from a stable public URL, unpack it, validate the tables, and load them into a relational database, GIS, dataframe workflow, or transit-routing engine. (gtfs.org)
GTFS Realtime uses Protocol Buffers rather than the static CSV-style files. Applications generally use the official protobuf schema or generated language bindings to parse the feed. Realtime endpoints may be delivered through a public URL, an API, or another publisher-controlled access method. The official publishing guidance emphasizes consistent fetch links and stable file naming because automated consumers depend on predictable access. (gtfs.org)
- •Static format: ZIP archive containing comma-delimited .txt files.
- •Realtime format: Protocol Buffers encoded according to gtfs-realtime.proto.
- •Common access methods: agency download pages, stable feed URLs, APIs, and data aggregators.
- •Typical tooling: SQL databases, Python or R dataframes, GIS software, validators, and transit-routing engines.
- •GeoJSON is supported for certain GTFS Flex demand-responsive locations; it is not a replacement for the core static feed format.
Suitable GIS workflows
A basic GIS workflow begins by loading stops.txt as point features using stop_lat and stop_lon, then joining those points to routes, trips, and stop_times through the feed’s identifiers. Shapes can be loaded as line features when present. Analysts can symbolize routes by mode or agency, map service frequency, identify stops with limited scheduled service, and compare the spatial distribution of transit stops with neighborhoods, employment, schools, housing, public facilities, or environmental features.
For accessibility analysis, the important step is to respect time. A stop that exists geographically may not serve every day or every hour. Analysts can filter trips by service date, calculate scheduled departures or headways, build time-of-day summaries, and create catchment areas around stops. Straight-line buffers can be useful for screening, but they should not be confused with walking accessibility unless a suitable pedestrian network and transfer assumptions are added.
- •Map stops, stations, routes, and shapes as geographic layers.
- •Join schedules to stops to calculate departures, service spans, or frequency by time period.
- •Create stop catchments and compare transit access with buildings, population, jobs, schools, or public assets.
- •Analyze transfers and station pathways where the relevant optional files are present.
- •Combine GTFS with a pedestrian, road, or multimodal network for realistic access and journey analysis.
- •Validate service dates, identifiers, coordinates, timezones, and duplicate or missing records before publication.
License, strengths, and tradeoffs
GTFS should be understood as an open standard rather than a single universally licensed data collection. The public specification repository identifies the project under the Apache 2.0 license, while the GTFS website states that its documentation is generally under Creative Commons Attribution 3.0 and code samples under Apache 2.0. Those terms apply to the specification materials, not automatically to every transit feed published by every agency. Individual feeds may have their own attribution, redistribution, commercial-use, rate-limit, or access requirements. (github.com)
Before redistributing or using a feed commercially, inspect the publisher’s terms, attribution requirements, metadata, and any restrictions attached to the actual data. If no license is stated, that absence should be reported rather than treated as permission to reuse the feed freely.
- •Strength: A widely adopted, machine-readable structure connects transit geography with schedules and service dates.
- •Strength: The format is simple enough for agencies and vendors to publish while remaining useful to mapping, routing, research, and GIS systems.
- •Strength: The ecosystem supports both scheduled service and realtime operational updates, with extensions for fares, transfers, pathways, translations, and demand-responsive transportation.
- •Tradeoff: GTFS is not one dataset, so coverage, completeness, update frequency, and data quality vary by publisher.
- •Tradeoff: Static schedules describe planned service and may not match actual vehicle movement, delays, cancellations, or temporary conditions.
- •Tradeoff: A feed may omit shapes, pathways, fares, accessibility details, or other optional components needed for a particular analysis.
- •Tradeoff: Licensing belongs to the feed publisher unless clearly stated otherwise; the open specification does not make every feed unrestricted.
- •Tradeoff: GTFS does not replace a complete street, pedestrian, address, land-use, or operational transit network.
Questions teams ask
Is GTFS one dataset that covers the whole world?
No. GTFS is a specification and publishing ecosystem. Individual feeds are produced by transit agencies, authorities, vendors, or aggregators, and each feed has its own geographic coverage, service period, update process, quality, and licensing terms.
What is the difference between GTFS Schedule and GTFS Realtime?
GTFS Schedule is usually a ZIP archive of CSV-style .txt files describing planned service, including stops, routes, trips, stop times, and calendars. GTFS Realtime is a separate Protocol Buffers format for information such as trip updates, service alerts, and vehicle positions.
Can GTFS be used for GIS mapping?
Yes. Stops can be mapped as points from their latitude and longitude, and shapes can be mapped as route lines when provided. Analysts can join these layers to schedules and service calendars, but should validate coordinates, identifiers, dates, timezones, and optional-file availability before analysis.
Does GTFS provide a complete road or walking network?
No. GTFS describes public transportation service and related transit geography. It may include route shapes and station pathways, but it does not automatically provide a complete pedestrian, road, address, or land-use network. Journey-planning workflows commonly combine GTFS with other geographic network data.
Is every GTFS feed free to redistribute?
No. The GTFS specification is openly documented, but the data in an individual feed may have separate terms. Check the publisher’s license, attribution instructions, access conditions, and commercial-use requirements before redistributing or building a public service on the feed.
Keep exploring
gtfs analysis workflow
A focused workflow for validating GTFS files, modeling transit schedules in GIS, filtering service by date and time, and analyzing stops, routes, transfers, and accessibility.
gtfs download and formats
A practical guide to locating GTFS feeds, understanding static ZIP archives and realtime Protocol Buffer feeds, preserving versions, and checking publisher terms.
Sources
GTFS Schedule Reference
Official specification reference for GTFS Schedule files, fields, requirements, service calendars, publishing practices, and extensions.
Open sourceGTFS Realtime Reference
Official reference for realtime transit entities, including trip updates, service alerts, and vehicle positions.
Open sourceGTFS Creating a Dataset
Official explanation of the static GTFS feed structure, CSV-style text files, ZIP distribution, and foundational entities.
Open sourceGTFS Publishing Data
Official guidance on stable feed URLs, consistent access links, and publishing practices.
Open sourceGoogle Transit GTFS Repository
Primary project repository describing GTFS as an open standard and identifying the repository license as Apache 2.0.
Open source