repository·master·Indexed 21 days ago
https://github.com/google/transitThe central hub for GTFS, an open standard for distributing transit system data. Includes documentation for GTFS Schedule, used for static transit information via ZIP-bundled text files, and GTFS Realtime, used for real-time updates via Protocol Buffers. The repository provides protocol buffer definitions, specification references, schema details for files like agency.txt and stops.txt, and guides for implementing and publishing transit feeds.
The General Transit Feed Specification (GTFS) is an open standard used by public transit agencies to distribute transit system information to riders. It provides a standardized format that allows transit data to be consumed by various software applications.
GTFS is composed of two primary formats:
GTFS Schedule Best Practices are recommended guidelines for describing public transportation services using the GTFS Schedule Reference format. While not mandatory, following these practices improves data quality and the rider experience. These recommendations complement the official GTFS Schedule Reference (which uses terms like "recommend" or "should").
Best practices are categorized into two main structures:
GTFS Realtime supports four primary types of information that can be combined within a single feed. Feeds are served via HTTP and should be updated frequently (ideally whenever new data is received from an Automatic Vehicle Location system).
Supported entity types:
A GTFS feed is a collection of text files bundled into a single ZIP file. Each text file within the ZIP models a specific aspect of transit information, such as stops, routes, trips, and schedule data.
Developers use these feeds to power applications like trip planners, timetable publishers, and other transit-related tools. The exact schema and requirements for each file are defined in the GTFS reference.
The pathways.txt file uses a graph representation (nodes and edges) to describe the internal access of a station (e.g., walkways, stairs, fare gates).
Key Node Types:
location_type=2: Station entrance/exit.location_type=0 or empty: Platform or stop.location_type=3: Generic node used to connect pathways.Guidelines for implementation:
stops.stop_access=1).location_type=4), it is treated as a parent object. Do not assign pathways to the platform itself; assign them to each individual boarding area.location_type=2) via a chain of pathways, unless the stop is marked with stops.stop_access=1 (directly accessible from the street).The ScheduleRelationship enum defines the relationship between a real-time trip and the static GTFS schedule. This is used to distinguish between trips that follow the existing schedule, trips that are extra/new, and trips that replace existing ones.
Key Values:
SCHEDULED: The trip follows the GTFS schedule or is closely associated with it.NEW: An extra trip unrelated to any existing trips (e.g., to handle sudden passenger load). Requires specifying the complete journey via StopTimeUpdates.DUPLICATED: A new trip that is identical to an existing scheduled trip except for the start date/time. Used with TripUpdate.TripProperties.trip_id, start_date, and start_time to copy a trip. The original trip is not modified; to cancel the original, a separate CANCELED update must be sent.REPLACEMENT: A trip that replaces an existing scheduled trip (e.g., due to a diversion). The complete journey must be specified via StopTimeUpdates.CANCELED: A trip that existed in the schedule but was removed.DELETED: An experimental value used to entirely remove information about a trip from consuming applications (e.g., when a trip is being replaced by substitute service) so it doesn't appear as 'cancelled' to riders.UNSCHEDULED: Used for trips defined in frequencies.txt with exact_times = 0.The EntitySelector allows you to specify which parts of the network are affected by an alert. You can use multiple informed_entity objects to cover different parts of the network.
You can select entities using their GTFS identifiers:
Agency: Affects the entire network.Route: Affects a specific route.Route type: Affects all routes of a specific type (e.g., all subways).Trip: Affects a specific trip.Stop: Affects a specific stop.informed_entity): If you include multiple fields in a single informed_entity, they are joined by an AND operator. For example, providing both route_id: "1" and stop_id: "5" means the alert applies only to route 1 at stop 5.informed_entity objects): To represent an alert affecting multiple distinct entities (e.g., both route 1 AND stop 5), you must add multiple informed_entity objects to your alert—one for each affected entity.Trip updates represent fluctuations in the GTFS timetable. They provide predicted arrival or departure times for stops, or communicate complex scenarios like trip cancellations, additions, or re-routing.
Key Rules for Producers:
TripUpdate for the current trip. Producers are encouraged to include updates for future trips in the same block to prevent 'prediction pop-in' and warn riders of downstream delays.TripUpdate entities for different trips in the same block do not need to be sent in scheduled order.GTFS governance is the framework used to maintain, update, and develop the General Transit Feed Specification (GTFS). It ensures the specification evolves in a stable, predictable, and collaborative way through community decision-making. The framework consists of four main components:
The Uncertainty field applies to both the time and the delay values in a StopTimeUpdate. It specifies the expected error in the true delay as an integer in seconds.
Example:
If a long-distance bus has an estimated delay of 15 minutes, but the arrival time is expected to fall within a 4-minute window of error (+2 / -2 minutes), the Uncertainty value would be 240 (4 minutes $\times$ 60 seconds).
The feed_info.txt file is used to store information about the GTFS dataset itself, rather than the transit services described in other files. This is useful when the dataset publisher is a different entity from the transit agencies.
Note: feed_info.txt does not have a primary key and is Conditionally Required.
A Vehicle Position message provides automatically generated location information (e.g., from an on-board GPS). To implement this, you must provide a TripDescriptor to identify the trip being served. You may optionally provide a VehicleDescriptor to identify the specific physical vehicle.
Key components include:
stop_sequence or stop_id.