GTFS download and formats: transit schedule files, realtime feeds, and GIS workflows
GTFS, the General Transit Feed Specification, is an open standard for publishing public transportation schedules, stop locations, routes, trips, service calendars, fares, and related geographic information. A GTFS Schedule feed is normally distributed as a ZIP archive containing comma-separated text files with .txt extensions. GTFS Realtime is a separate, frequently updated Protocol Buffers feed for trip updates, service alerts, and vehicle positions. GTFS is not one global dataset with fixed coverage, a universal update schedule, or a single data license: each feed is published by a transit agency, public authority, vendor, or aggregator, and its geography, completeness, cadence, and terms depend on that publisher.
GTFS is best understood as a standard for exchanging transit information rather than as a single downloadable map layer. It gives different transit systems a shared vocabulary for representing agencies, stops, routes, trips, stop times, service dates, shapes, fares, accessibility information, and other rider-facing details. For GIS users, GTFS is especially valuable because it links scheduled movement to physical locations: stops have coordinates, routes can be represented with geographic shapes, and trips connect those locations to times and service calendars. The result is a dataset that can support transit mapping, accessibility analysis, network modeling, timetable production, and location-based applications.
How EDK fits
For: GIS analysts, transportation planners, transit agencies, routing developers, researchers, mapping teams, public-sector data users, and developers who need machine-readable transit schedules or realtime service information.
GTFS contributes a specialized transportation layer to the broader task of finding, understanding, and computing about the physical world. Its stop coordinates, route shapes, station structures, service calendars, and trip times describe how people can move through real places at particular times. That makes GTFS useful alongside roads, buildings, addresses, sidewalks, land use, population, destinations, and other geographic layers. GTFS does not provide a complete world model: it generally does not supply a comprehensive road network, building inventory, address index, parcel fabric, or authoritative physical description of every place. Its value is narrower and highly structured: it turns public transit service into data that can be joined to geographic features and analyzed as a time-dependent mobility system.
- •Combine GTFS stops, routes, and service calendars with a physical-world feature layer to identify which schools, clinics, parks, workplaces, or other destinations are reachable by transit within a selected time window.
- •Compute and compare transit access across neighborhoods by joining stop locations and scheduled travel times with population, buildings, roads, administrative areas, or environmental features, while preserving the distinction between scheduled service and actual realtime conditions.
- •Use GTFS shapes and stops as a transportation context layer when interpreting geographic change, public-asset demand, construction impacts, or service requests near transit corridors and stations.
Dataset profile
Formats
GTFS Schedule ZIP archive
Comma-separated text files with .txt filenames
GTFS Realtime Protocol Buffers binary messages
GeoJSON for applicable supported demand-responsive geographic features
Converted GIS and analytical formats such as GeoPackage, PostGIS tables, Parquet, or GeoJSON, created by downstream users rather than defining the canonical GTFS distribution
Access methods
Permanent fetch URL hosted by a transit agency or its technology vendor
Government or public data portal
GTFS feed directories and aggregators such as Mobility Database and Transitland
HTTP access to GTFS Realtime binary feeds
Local download, archival, and batch processing of published ZIP files
Quality and limits
GTFS is a specification, not a guarantee that a feed is complete, current, authoritative, or internally consistent.
Coverage may omit agencies, private operators, demand-responsive services, temporary routes, informal services, or station details.
Optional files and fields are not present in every feed, limiting cross-feed comparability.
Stop coordinates and route shapes may be approximate, outdated, generalized, or modeled differently by different publishers.
Static schedules describe planned service and should not be interpreted as a guarantee of actual departure, arrival, or vehicle operation.
Realtime feeds may be delayed, stale, unavailable, incomplete, or difficult to match if the static feed version changes.
Feed licenses and attribution requirements vary; the specification license does not settle rights for the underlying data.
GTFS does not replace a pedestrian network, road graph, address database, building layer, parcel layer, or comprehensive physical-world basemap.
Analysis workflows
Download and archive the original ZIP, source URL, fetch time, feed version, and stated license before transformation.
Validate required files, identifiers, coordinate ranges, duplicate keys, date ranges, referential integrity, and publisher-specific warnings.
Load stops as point geometry and shapes as line geometry; preserve the original identifiers so trips, routes, and schedules can be joined reliably.
Resolve calendar.txt and calendar_dates.txt for a selected date before calculating which trips actually operate.
Build timetable, frequency, transfer, stop-access, or time-dependent network analyses using scheduled times and clearly documented assumptions.
Join GTFS with roads, walkways, buildings, addresses, destinations, population, administrative boundaries, environmental features, or public assets for geographic accessibility and service-impact analysis.
Ingest GTFS Realtime separately, match it to the appropriate static feed, and store observation timestamps and feed versions.
Compare feed snapshots over time to detect route, stop, schedule, geometry, or service-calendar changes.
Report publisher, feed vintage, validity period, coordinate reference assumptions, processing steps, and license terms with every derived layer or metric.
Value inside EDK
What GTFS contains
A basic GTFS Schedule feed models public transportation as linked tables. agency.txt identifies the operating organization. routes.txt describes services such as bus, rail, ferry, or cable-car routes. trips.txt represents individual journeys operated on a route. stops.txt provides stop or station identifiers, names, and geographic coordinates. stop_times.txt records the arrival and departure times of each trip at each stop. calendar.txt and calendar_dates.txt describe regular operating days and exceptions. The official GTFS documentation describes these elements as the base features needed to represent a working transit service. (gtfs.org)
Optional and extended files add detail that can matter in GIS and routing workflows. shapes.txt can describe the geographic path followed by a vehicle. feed_info.txt records publisher, language, validity dates, and version information. Fare, pathway, level, transfer, translation, location-group, and rider-information features can provide more detail, but not every feed includes every supported feature. The practical question is therefore not only whether a feed is labeled GTFS, but which files and fields it actually publishes.
- •Core files commonly include agency.txt, routes.txt, trips.txt, stops.txt, stop_times.txt, calendar.txt, and calendar_dates.txt.
- •Shapes, fares, pathways, transfers, translations, feed metadata, and other files are optional or feature-dependent.
- •The geographic unit can be one agency, a metropolitan area, a region, or a larger collection of services.
- •The presence of a GTFS file does not by itself establish that the feed is complete, current, authoritative for every operator, or suitable for navigation.
Geography, temporal coverage, and update cadence
GTFS has no fixed global geographic extent. Its geography is determined by the transit publisher and the services selected for the feed. A local agency feed may cover only its own routes and stops; a regional feed may include multiple operators; an aggregator may distribute many separate feeds rather than one seamless network. Before analysis, inspect agency identifiers, stop coordinates, route types, feed metadata, and the publisher's documentation to determine what area and operators are actually represented.
Temporal coverage is equally important. Schedule feeds describe planned service over a validity interval, commonly communicated through calendar.txt, calendar_dates.txt, and, when present, feed_info.txt. The official guidance recommends that published schedules remain valid for at least the next seven days and encourages agencies to publish known changes in advance. However, agencies differ: some update weekly or monthly, while others update quarterly or on another operational schedule. There is no universal GTFS refresh interval. (gtfs.org)
- •Geographic coverage is publisher-defined rather than standardized globally.
- •Static schedules describe planned service and validity periods, not guaranteed vehicle performance.
- •Realtime feeds may change frequently and can become stale or unavailable independently of the static feed.
- •Feed versions, download timestamps, and validity dates are essential for reproducible analysis.
Formats and access methods
The standard GTFS Schedule distribution is a ZIP archive containing comma-separated text files with .txt extensions. The files are relational: identifiers such as route_id, trip_id, service_id, and stop_id link records across tables. A GIS or database workflow normally begins by downloading and unpacking the archive, reading the text files with a CSV-aware parser, enforcing field types, and loading stop coordinates and route shapes into a spatial database or GIS project. The official documentation describes the stable public fetch link and ZIP archive as the normal publishing model. (gtfs.org)
GTFS Realtime uses a different format. The official schema is defined in gtfs-realtime.proto, and realtime messages are encoded with Protocol Buffers. A producer commonly serves the binary response over HTTP. The main entity families are trip updates, service alerts, and vehicle positions. Developers generally generate language-specific bindings from the schema or use an existing GTFS Realtime library. (gtfs.org)
- •Static GTFS: ZIP archive of CSV-formatted .txt files.
- •Realtime GTFS: Protocol Buffers messages served as a binary HTTP feed.
- •Common discovery paths: transit-agency websites, vendor portals, Mobility Database, Transitland, and government data catalogs.
- •Preserve the original archive and metadata before converting to GeoPackage, PostGIS, Parquet, GeoJSON, or another working format.
Suitable GIS and spatial-analysis workflows
A straightforward GIS workflow is to load stops.txt as point features using stop_lat and stop_lon, then load shapes.txt as line features when shapes are available. Join routes and trips through their identifiers, connect trips to stop_times, and apply calendar rules before calculating service for a particular date. This produces a date-aware transit layer rather than a simple map of all possible routes. If shapes are absent, a straight line between stops is not necessarily the vehicle path and should not be treated as an authoritative route geometry.
For accessibility analysis, select a date and time window, filter trips using calendar.txt and calendar_dates.txt, calculate scheduled arrivals and departures, and build a time-dependent network or timetable query. Combine the result with walkable streets, entrances, buildings, population, jobs, schools, healthcare, parks, or other destination layers. Analysts can then estimate stop access, service frequency, transfers, scheduled travel time, or the number of destinations reachable within a threshold. GTFS alone does not provide the complete pedestrian network, universal address coverage, or guaranteed travel times needed for every accessibility model.
- •Validate identifiers and date rules before calculating service for a specific day.
- •Use stop coordinates and published shapes as transit geography, not as a replacement for a pedestrian or road network.
- •Join GTFS to physical-world layers for destinations, demographics, buildings, roads, and administrative areas.
- •Keep scheduled, estimated, and observed times separate in dashboards and analyses.
- •Record source URLs, fetch timestamps, feed versions, and conversion steps for reproducibility.
License, strengths, and tradeoffs
The GTFS specification is published under the Apache 2.0 License, but that does not mean every GTFS feed is freely reusable under Apache 2.0. The feed is data published by a particular organization, and its terms may be stated on the agency website, in a data portal, in a vendor agreement, or in the feed's accompanying documentation. Some feeds may be open, some may require attribution, some may restrict redistribution or commercial use, and some may require an API key. If no clear feed license is available, the responsible conclusion is that the reuse terms are unavailable and should be confirmed with the publisher rather than inferred. (gtfs.org)
GTFS is strong when the task involves scheduled public transportation and requires a common, relatively simple exchange structure. It is portable across agencies and software ecosystems, understandable with ordinary data tools, and naturally connected to spatial analysis through stop coordinates and route shapes. Its relational design also makes it possible to preserve detailed service calendars instead of reducing transit to static lines on a map.
- •Strength: widely recognized, machine-readable structure for transit schedules and locations.
- •Strength: useful bridge between timetable data and geographic analysis.
- •Strength: supports both static planning data and a separate realtime exchange format.
- •Tradeoff: coverage, completeness, quality, and update cadence vary by publisher.
- •Tradeoff: optional features and agency modeling choices can reduce comparability between feeds.
- •Tradeoff: feed licensing is not standardized, and GTFS alone does not provide a complete basemap, routing graph, or guarantee of actual service.
Questions teams ask
Is GTFS one dataset that covers every transit system?
No. GTFS is a specification and publishing ecosystem, not one global dataset. Individual agencies, authorities, vendors, governments, and aggregators publish feeds with their own geographic coverage, operators, schedules, quality, and access terms.
What is the difference between GTFS Schedule and GTFS Realtime?
GTFS Schedule is the static or planned service feed, normally distributed as a ZIP archive of CSV-formatted text files. GTFS Realtime is a separate Protocol Buffers feed for current trip updates, service alerts, and vehicle positions. Realtime data is generally interpreted against a corresponding static schedule.
Can I use GTFS directly in QGIS or ArcGIS?
Yes, GTFS can be imported or converted for use in GIS software, and the GTFS documentation identifies ArcGIS and QGIS workflows. In practice, users commonly load stops as points, shapes as lines, and related schedule tables into a database or GIS project. Import support and the handling of calendars, frequencies, pathways, and realtime data depend on the specific tool or plugin.
How often should a GTFS feed be downloaded?
There is no universal answer. Follow the publisher's stated cadence and inspect feed validity and version metadata. For operational applications, fetch often enough to detect schedule changes; for realtime feeds, refresh according to the producer's guidance and retain timestamps so stale data can be identified.
Is every GTFS feed free to redistribute or use commercially?
No. The GTFS specification is Apache 2.0 licensed, but individual feeds may have separate licenses or restrictions. If the feed does not clearly state its terms, treat the license as unconfirmed and contact the publisher before redistribution or commercial use.
Keep exploring
Sources
General Transit Feed Specification overview
Official overview of GTFS Schedule, GTFS Realtime, the core feed structure, and specification licensing.
Open sourceGTFS Schedule reference
Official reference for GTFS Schedule files, fields, publishing practices, and validity requirements.
Open sourceCreating a GTFS dataset
Official explanation of static ZIP feeds, CSV-formatted text files, GTFS Realtime, Protocol Buffers, and update expectations.
Open sourceMaking a GTFS feed publicly available
Official guidance on permanent fetch links, aggregators, GIS use, and publishing practices.
Open sourceGTFS sharing data resources
Official directory of recognized GTFS discovery resources including Mobility Database and Transitland.
Open source