Provide realtime trip information with TripUpdates

A stop_time_update message can provide information about the arrival or departure at a stop for a particular trip. To update the arrival time, provide a TripUpdates feed with a well-matched TripDescriptor and accurate stop_time_update information for stops and timestamp at which the progress is measured.

You must follow a few basic guidelines:

• The TripUpdates feed should include the best-available prediction of the next upcoming StopTimeUpdate.
• If possible, the feed should continue to include any previously visited stops. Use StopTimeUpdates to represent stops using stop_id or stop_sequence, with values indicating the final times of when the vehicle arrived or departed the stop.
• If available, include a TripUpdate.timestamp of when the latest measurement of the associated vehicle was taken.

When you successfully create a TripUpdate, we support re-routing based on the realtime departure and arrival times provided through GTFS realtime TripUpdate feeds.

When you provide both TripUpdate and VehiclePosition for the same trip, we’ll decide which type of message to use:

• TripUpdate message with ETAs based on stop_time_update information.
• VehiclePosition message based on position information with a forecast of the ETAs from our prediction algorithm.

Example

Trip T is scheduled to depart at 7 PM today from station S. The GTFS realtime TripUpdate feed shows that the trip has a delay of 5 minutes at station S. Now, when you search for connections from station S at 7:03 PM, trip T will display as one of the possible connections. The realtime TripUpdate updated the departure time of trip T to be after the scheduled departure time.

Example code:

trip_update {
  trip {
    trip_id: xxx
    start_time: 12:34:56
  }
  stop_time_update {
    stop_sequence: 0
    stop_id: "child_stop_id"
    arrival {
      time: 1284457468
    }
  }
}

Please ensure that:

• The start_time in trip_descriptor should be the same as the departure_time defined in the static feed.
• After the start_time is defined to maintain reference to the trip, it should be stable.
• Specify the delay with the stop_time_update in either the time or the delay field.

For frequency based schedules, the next trip arrival time always appears as green and on time.

For fixed schedules, the actual delay time displays:

  

To indicate a change in a stop, the agency can update the stop_id of the StopTimeUpdate object. The stop_sequence must be provided and the replaced stop_id must be a parent_station or share a parent_station with the new stop_id.

Example code:

trip_update {
  trip {
    trip_id: xxx
    start_time: 12:34:56
  }
  stop_time_update {
    stop_sequence: 0
    stop_id: "child_stop_id"
    arrival {
      time: 1284457468
    }
  }
}

How users get platform information:

 

 

Use a SKIPPED value for the schedule_relationship in the StopTimeUpdate object.

• If the affected stop is a boarding or alighting stop for a user query, then the trip with the skipped stop will be removed from the search results.
• If the affected stop is in the middle of a trip that doesn't require boarding or alighting, the trip won't be removed from search results.

Example code:

trip_update {
  trip {
    trip_id: xxx
    start_time: 12:34:56
  }
  stop_time_update {
    stop_sequence: 0
    schedule_relationship: SKIPPED
  }
}