[GTFS Digest] January 2025 - A Vote on Rider Categories and a Proposal on Interoperable βtrip_idβs see the light¶
The February GTFS Digest covers the ongoing vote on rider_categories.txt for GTFS-Fares v2, the adoption of agency_fare_url clarifications, and proposals like original_trip_id for trip referencing and boarding_permissions.txt for vehicle carriage rules. Discussions include GTFS Realtime versioning and best practices for unique IDs.
The GTFS Digest is a resource generated monthly by MobilityData providing an overview of developments on GTFS.
We really value your feedback and would like to know how we did. We invite you to fill out this form and help us achieve the full potential of this tool.
π Contributor Shoutouts¶
Harpreetkaur, Laurent, Stephanie Daniels, Wojciech, & Angela Teyvi
Thank you for joining the GTFS slack and contributing to the community with your valuable threads.
David1234
Shoutout for posting your first Pull Request on google/transit. We are looking forward to seeing how it develops!
Miklcct
We applaud you for sticking with your proposal after an unsuccessful vote. Advocating for a proposal can be tricky and building consensus takes lots of patience.
π³οΈ Currently Voting¶
[GTFS Fares v2] Add rider_categories.txt #511
The rider_categories.txt file is part of the GTFS-Fares v2 proposal, aimed at modeling rider categories that are eligible for certain fares.
- Voting ends on 2025-02-13 at 23:59:59 UTC.
π Recently Adopted¶
Clarify use of agency_fare_url #524
This PR extends the definition of agency_fare_url to also include URL pages with fare information instead of just pages that allow purchasing tickets.
π Active Proposals¶
Enhancing GTFS Schedule and Realtime with original_trip_id #534
Davidr1234 suggests adopting original_trip_id
from the Google Transit extension in both GTFS Schedule and GTFS Realtime. This would allow for seamless referencing of trips between GTFS and other standards, such as SIRI and NeTEx, which have a similar concept.
Introduce boarding permissions to specify the carriage of vehicles at per-stop granularity #533
Miklcct proposes a generic solution to specify whether any kinds of vehicles can be carried, boarded, or alighted on public transport services at a per-stop granularity. This is achieved by introducing a new file, boarding_permissions.txt, which is referenced from stop_times.txt.
Clarification on continuous pickup/dropoff value and field Type in booking_rules.txt #528
This PR introduces clarifications specifically for demand-responsive transportation (DRT) services, allowing a value of 1 for continuous_pickup/continuous_drop_off when start_pickup_drop_off_window/end_pickup_drop_off_window are indicated. It also updates the data type of four fields in booking_rules.txt to a positive integer.
Addition of event_based_trips.txt to specification #527
This PR builds on issue #526, it suggests the addition of an event_based_trips.txt file to indicate to consumers and customers that applicable trips are post-event extras.
Add stops.stop_access field #515
This PR adds a stop_access field in stops.txt to indicate how the stop is accessed for a particular station. Please refer to this proposal for details. Adding this field is also the first phase of our three-phase plan to improve station modeling.
Deprecate TripUpdate.schedule_relationship = ADDED, add TripUpdate.schedule_relationship = NEW / REPLACEMENT to specify new / replaced trips which do not run on a schedule from the GTFS static. #504
The original proposal in this PR was changed after a vote failed. The updated proposal focuses on deprecating TripUpdate.schedule_relationship = ADDED in GTFS Realtime and replacing it with TripUpdate.schedule_relationship = NEW to indicate a completely new trip not found in GTFS Schedule, with the new value flagged as experimental. We invite as many people as possible to join the discussion to ensure the changes are thoroughly considered by the community before the next vote.
Other open proposals:
- Stop Time Events in the past should be kept #502
- [GTFS Fares v2] Add nonconsecutive_transfer_allowed field and clarify fare_transfer_type #498
- [GTFS Fares v2] Area Set matching predicates #483
- Clarification of CANCELED/SKIPPED TripUpdates VS NO_SERVICE Alerts #482
- [GTFS-Fares v2] Fare product/media transfer behavior #423
π₯ Most Active Conversations¶
[Discussion] GTFS Realtime Versioning #530
In recent discussions regarding GTFS Realtime, the community seems to have encountered difficulties in reaching consensus, leading to the topic of versioning being raised in the recent PR#504. To address this, we are opening this issue dedicated to discussing GTFS Realtime versioning.
Ad-hoc trips in GTFS-RT TripUpdates feed use of trip_id not found in GTFS-Static #529
Mpaine-act is setting up a new GTFS-Realtime TripUpdates feed and seeks guidance on handling trips not found in GTFS-Static. The issue compares two approaches: using a negative (fake) trip_id for backward compatibility or omitting the trip_id entirely.
Add communication_period and impact_period to GTFS Service Alerts #521
The GTFS Realtime Alert active_period field is ambiguous, as it could mean either the alert's display period or the disruption's duration. A proposal suggests adding communication_period for the alert's display and impact_period for the disruption timeframe to clarify its use.
Best Practices: Reasonable lengths in unique ids #518
This issue proposes to introduce a best practice that sets a recommended character limit for any ID used in a GTFS feed, triggering a validator warning if a value exceeds 36 bytes.
Global trip id #462
David from SKI+ proposes a new field "trip_global_id" in GTFS Schedule and Realtime for better integration with other standards like NeTEx and HRDF, addressing a need for a day-long valid trip identifier. This global ID would allow easier mapping of travel information across different data formats.
Proposed Best Practice: always including trip_id in TripDescriptor for SCHEDULED trips #465
This proposal suggests mandating the use of trip_id
in the TripDescriptor for SCHEDULED trips in GTFS Realtime to simplify data integration, as the alternative method using multiple identifiers often causes issues.
Slack conversations on #gtfs¶
Guillaume asked if Google is using boarding areas
Stephanie had a question about best practices for GTFS calendars
Wojciech inquired about cancelling scheduled trips in GTFS
Aaron asked about the expectations around shape_dist _travelled amongst GTFS consumers.
Angela requested a method to produce GTFS by querying OSM
Harpreetkaur seeked advice for best practices regarding GTFS-RT TripUpdates for the last stop of a trip
Slack conversations on #gtfs-realtime¶
Michael requested a tool that combines multiple GTFS-RT feeds into a single feed.
Laurent asked for advice about how to propagate delay in a trip that hasnβt started yet.
π Upcoming Events¶
GTFS-Fares v2 β Monthly meetings | February 25, 2025 @ 11 am EST
Topics : GTFS-Fares v2 extension Working Group Meeting
π¬ Join the GTFS Community¶
GitHub: google/transit: Share your ideas with the community! Join the official GTFS GitHub repository.
GTFS-changes: Get updates as soon as they happen, join the GTFS-changes google groups to get information about new pull requests and votes.
GTFS-realtime: Talk everything Realtime and stay up to date. This group is discussing the GTFS Realtime, asking questions, and proposing changes.
GTFS.org: The official GTFS documentation website. Here you will find frequently updated resources for your GTFS needs.
MobilityData Slack: Have a question about GTFS or need to connect with the community? Join in on GTFS slack conversations. This is a great place to have questions answered quickly by the over 1,300 mobility enthusiasts navigating our channels.
Thank you for reading this edition of the GTFS Digest! We look forward to bringing you the latest GTFS updates in 2025 and beyond.