Skip to content
Tony Laidig edited this page Dec 29, 2016 · 1 revision

Prediction Interface

The prediction module will output messages containing new stop-level predictions for a single vehicle as individual messages in the (new) prediction queue. It will output one such message for each message it receives from the inference queue (with the exception of buses for which it cannot formulate any predictions, such as some buses currently making non-revenue movements).

The prediction messages will be in GTFS-realtime format, according to the below specification. GTFS-realtime was selected as the ideal format for this information because:

  • It is an open standard format
  • It is implemented using Protocol Buffers, a highly space and time-efficient multi-language binary serialization scheme. This is important because each prediction message will have a large number of predictions (one for each stop the bus will make) and so ASCII formats (e.g. JSON) used in the other queues are not appropriate.

Below is an example of a prediction message. It is shown in the ASCII/textual format that is used to represent (otherwise-binary) Protocol Buffer content. In addition, explanatory comments (not typically used in this expository convention) are preceded by '//'/

Example Prediction Output.pbdebug
header {
	gtfs_realtime_version: "1.0"
	incrementality: DIFFERENTIAL
	timestamp: 1330030345776 //timestamp for the time the message was generated
}
entity {
	id: "????"  // need to figure out what this ID means and how it is supposed to be used
	trip_update {
		trip {
			trip_id: "MTA NYCT_XXXXXXXXXXXX" //the trip_id for which predictions are offered, fully qualified with agency ID
			route_id: "MTA NYCT_B63" //the route_id for the trip, fully qualified with agency ID.  not actualy
			schedule_relationship: SCHEDULED //indicates that this trip is a regularly scheduled trip (that's all we have in OneBusAway-NYC.  If necessary, UNSCHEDULED or ADDED could be used to indicate informal inference, if needed (but shouldn't be)
		}
		vehicle {
			id: "MTA NYCT_7560" // vehicle ID, fully qualified agency with ID
			label: "7560" // the plain bus number, no agency
		}
		stop_time_update { // first stop_time_update, for the first predicted stop on the given trip
			stop_sequence: 10 //must be the same as from the bundle.  but not really needed at all.
			stop_id: "MTA_123456" //fully-qualified stop_id, from the bundle
			arrival: { //required for all stops except the first/origin stop of a given trip
				time: 1330030345776 //predicted arrival time for the given bus at the given stop on the given trip
			}
			departure: { //departure predictions are only required for the first/origin stop of a given trip
				time: 1330030345776 //predicted arrival time for the given bus at the given stop on the given trip
			}
		}
		stop_time_update { //next stop_time_update, for the next predicted
			stop_sequence: 11
			stop_id: "MTA_123457"
			arrival: {
				time: 1330030345776 //predicted arrival time for the given bus at the given stop on the given trip
			}
			departure: {
				time: 1330030345776 //predicted arrival time for the given bus at the given stop on the given trip
			}
		}
		[... more stop_time_updates, but only as far as the end of the given trip ...]
 
		timestamp: 1330030345776 //timestamp of the original observation on the bus.  In the OneBusAway-NYC case, time_reported
	}
	trip_update { //optionally, for subsequent trips on the block that the given bus is serving.  only if inference is formal
		trip {
			trip_id: "MTA NYCT_XXXXXXXXXXXX" //the trip_id for a subsequent trip for which predictions are offered
			route_id: "MTA NYCT_B63"
			schedule_relationship: SCHEDULED
		}
		vehicle {
			id: "MTA NYCT_7560" //it must be the same vehicle, if it's coming in the same prediction update
			label: "7560"
		}
		stop_time_update {
			...
		}
		[... more stop_time_updates, but no further than the end of the given trip ...]
 
		timestamp: 1330030345776 //timestamp of the original observation on the bus.  In the OneBusAway-NYC case, time_reported
	}
	[... more trip_updates, but no further than the end of the block the bus is currently serving.  likely less far...]
}

Some notes on the above specification-by-example:

  • The above example does not have realistic trip_id, stop_id, and timestamp values. Those should be replaced, or at least understood as such.
  • All trip, route, vehicle, and stop ID's are fully-qualified with agency prefixes.
  • The semantics and value of the entity::id element is TBD.
  • This example hints at a subject to be discussed in further detail elsewhere: for a given bus, how far out will the prediction module predict? how many stops on the current trip? subsequent trips?
Clone this wiki locally