Trip Updates
When agencies publish, GTFS-RT Trip Updates, Transit and other third parties can display the most accurate departure information of a vehicle completing a trip. This is arguably the most important detail to riders, as it tells them exactly when their vehicle will serve their stop, ultimately allowing them to navigate their trip plans with more confidence. We recommend agencies follow the GTFS Realtime standard for Trip Updates. If you are using an alternative API format, we have some best practices outlined in the section dedicated to non GTFS-RT API’s.
In this article:
How Transit Displays Trip Updates
TripDescriptor
- In the TripUpdate entity, the TripDescriptor is used to identify a specific trip. It should include a trip_id that corresponds with a valid trip in the static GTFS data, this ensures the realtime information is assigned to the intended trip.
- If trip_id can’t be provided; route_id, direction_id, start_date and start_time must be provided instead. In the case that trip_id’s are not matching, Transit will use these fields to attempt to match the realtime to the correct trip as a fallback.
ScheduleRelationship
- SCHEDULED is used for a trip that is running more or less according to GTFS schedule. Transit will display the Trip Update with realtime waves, and will round down to the nearest minute to simplify display and provide a safety buffer to help riders avoid a near-miss for their departure.
- CANCELED is used when a trip is cancelled in its entirety, it is the fastest way to communicate a cancellation to riders.
- Transit crosses out cancelled departures with an unambiguous strike-through in the list of a line’s upcoming departures shown on the app’s main screen, and in the route details. This way, users can know that a vehicle will not be appearing at their stop at the stated time.
- DUPLICATED is used when an adding an extra trip for that wasn’t initially scheduled in the static data. DUPLICATED trips must have the same service pattern as a trip occuring within 30 days in the static data.
ADDED enumeration is now deprecated in favor of DUPLICATED, producers should migrate to using DUPLICATED instead. However, Transit still supports ADDED for backward compatibility. To be displayed in Transit, ADDED trips must have the same service pattern as a trip in the static data occurring within 4 ½ hours.
- DELETED trips are completely removed from the schedules in the app and not visible to riders.
- NEW is not yet supported by Transit but we are intending to add support soon.
- UNSCHEDULED is used for trips defined with frequencies.txt in the GTFS Static. Transit does not support UNSCHEDULED trips by default, and would need to configure them manually.
if your GTFS Schedules are described using frequencies.txt, please contact us to verify if your feed structure is compatible with our configuration for frequencies.
StopTimeUpdate
StopTimeUpdates specify realtime information at the stops served by a trip.
StopTimeEvent
- StopTimeEvent’s may include either a delay compared to schedule, or a time. Transit supports both types of updates, however:
- time is preferred as it is explicit and offers greater reliability.
- delay is less reliable because it is dependent on matching with the trips in the schedule, and when matching is not possible, we can still use the absolute time.
ScheduleRelationship
- Transit supports SCHEDULED and SKIPPED and NO_DATA.
- Use SKIPPED in the case of a detour, when a vehicle does not serve its scheduled stops. Transit will display the crossed through departure time and designate “Skips this stop”.
- Similar to the ScheduleRelationship for the TripDescriptor, Transit does not support UNSCHEDULED StopTimeUpdates by default.
How Transit Displays Trip Updates
When tapping on a route, Transit will display the next 5 departures. The associated realtime information will be displayed only if the departure is within the next 90 minutes. After which, departures will display scheduled time from the GTFS Static.
In the More Departures list, Transit will display realtime for all trips if they are provided. Realtime for trips departing more than 4 ½ hours in the future are considered low-confidence and thus, are not displayed.
Transit doesn’t display realtime updates that are stale. If the header of the TripUpdate protobuf is older than 10 minutes, we drop TripUpdates and revert to showing scheduled times.
Non-GTFS-RT API’s
Not all agencies are able to produce GTFS RT feeds for third parties. We do our best to work with feeds in other formats. When providing an API, please ensure your endpoint allows as many requests needed to provide information to all your riders. The API should contain the information to be able to match, at a high level, the stop, and the trip.
- To match the stop, the API must contain a stop_id or stop_code from the static GTFS.
- To match the trip, we can use either the trip_id, or the route_id and trip_headsign. Matching with trip_id’s is the best way to associate real time data with a scheduled item. If it’s impossible to include a trip_id, we can also use the route and headsign. Provide either route_id or route_short_name, and the trip_headsign. Both should directly match the static data.
In some cases, we may be able to find a solution for APIs that don’t meet these requirements – but they are less likely to work consistently and reliably. This may, in turn, incorrectly set riders’ expectations about when to expect a vehicle to appear at their stop.
Implicit Cancellations
- For non-GTFS-RT, note that the app will automatically cancel a departure if a trip is missing realtime information and the agency has provided realtime information for later trips.
- For example: there are three departures scheduled in 7, 10, and 18 minutes. The agency has provided realtime information for the trips in 10 and 18 minutes, but not for the trip in 7 minutes. The app will consider the scheduled trip in 7 minutes to be cancelled, and display the strike-through.
If your agency prefers to keep displaying these trips as scheduled and not cancelled, please contact us data@transitapp.com, and we can disable this functionality for your feed.
Transit's Prediction Engine
- What can you do if your agency doesn’t have a trip updates endpoint, or if your trip updates are otherwise unreliable? Transit has developed a prediction engine that uses machine learning to generate accurate arrival times from Vehicle Positions. Our predictions are typically more accurate than most agency data based on metrics generated by our ETA Accuracy Benchmark
- To enable the prediction engine, we need accurate, frequently updated vehicle locations, and two weeks to train a machine learning model for your city. Note that our prediction engine has been extensively tested on bus networks, but may not perform as well for other modes.
- In some cases, we may need to “switch on” trip updates without a two-week lead time. In these cases, we can enable a less sophisticated prediction engine, which uses vehicle locations to propagate delays down the route.
Automated Checks
- Transit's realtime checker continuously monitors the status of the Trip Update feed. If the total number of active trips expected in the Trip Update feed falls below a certain threshold, we designate that the feed is down. We offer automated email notifications to inform your agency when Trip Updates are down.
To subscribe to these realtime checker emails, please send a request to data@transit.app.