For Developers Index - SIRI MonitoredVehicleJourney Element

Page / - last modified by admin admin on 2019/11/11 05:34

SIRI MonitoredVehicleJourney Element

last modified by admin admin

on 2019/11/11 05:34

Table of Contents

SIRI MonitoredVehicleJourney Element

The PresentableDistance field:

Transparency of Block vs. Trip-Level Assignment

SIRI MonitoredVehicleJourney Element

The SIRI MonitoredVehicleJourney element contains most of the relevant real-time information about particular vehicles in the MTA Bus Time system. It is used by the responses to both the VehicleMonitoring and StopMonitoring calls. As much as possible, the values in a MonitoredVehicleJourney element correspond to the values in the MTA's GTFS data.

The XML below illustrates the SIRI MonitoredVehicleJourney element. Other notes on the contents of a MonitoredVehicleJourney follow the example.

<MonitoredVehicleJourney>
<!-- The 'fully qualified' route name (GTFS agency ID + route ID) for the trip the vehicle is serving. Not intended to be customer-facing. -->
<LineRef>MTA NYCT_B63</LineRef>
<!-- The GTFS direction for the trip the vehicle is serving -->
<DirectionRef>1</DirectionRef>
<!-- A compound element uniquely identifying the trip the vehicle is serving -->
<FramedVehicleJourneyRef>
<!-- The GTFS service date for the trip the vehicle is serving -->
<DataFrameRef>2011-01-28</DataFrameRef>
<!-- The GTFS trip ID for trip the vehicle is serving, prefixed by the GTFS agency ID -->
<DatedVehicleJourneyRef>MTA NYCT_20110102EA_087800_B63_0002_B63_19</DatedVehicleJourneyRef>
</FramedVehicleJourneyRef>
<!-- The GTFS Shape_ID, prefixed by GTFS Agency ID -->
<JourneyPatternRef>MTA NYCT_B630152</JourneyPatternRef>
<!-- The GTFS route_short_name -->
<PublishedLineName>B63</PublishedLineName>
<!-- GTFS Agency_ID -->
<OperatorRef>MTA NYCT</OperatorRef>
<!-- The GTFS stop ID for the first stop on the trip the vehicle is serving, prefixed by Agency ID -->
<OriginRef>MTA_801131</OriginRef>
<!-- The GTFS stop ID for the last stop on the trip the vehicle is serving, prefixed by Agency ID -->
<DestinationRef>MTA_801042</DestinationRef>
<!-- The GTFS trip_headsign for the trip the vehicle is serving -->
<DestinationName>BAY RIDGE SHORE RD via 5 AV</DestinationName>
<!-- If a bus has not yet departed, OriginAimedDepartureTime indicates the scheduled departure time of that bus from that terminal in ISO8601 format -->
<OriginAimedDepartureTime>2011-01-28T14:45:00.000-04:00 </OriginAimedDepartureTime>
<!-- SituationRef, present only if there is an active service alert covering this call -->
<SituationRef>
<SituationSimpleRef>MTA NYCT_8d065d76-2813-46ee-b024-20f956232831</SituationSimpleRef>
</SituationRef>
<!-- Always true -->
<Monitored>true</Monitored>
<!-- The most recently recorded or inferred coordinates of this vehicle -->
<VehicleLocation>
<Longitude>-73.97857</Longitude>
<Latitude>40.68448</Latitude>
</VehicleLocation>
<!-- Vehicle bearing: 0 is East, increments counter-clockwise -->
<Bearing>345.7</Bearing>
<!-- Indicator of whether the bus is making progress (i.e. moving, generally), not moving (with value noProgress), laying over before beginning a trip (value layover), or serving a trip prior to one which will arrive (prevTrip). -->
<ProgressRate>normalProgress</ProgressRate>
<!-- Optional indicator of vehicle progress status. Set to "layover" when the bus is in a layover waiting for its next trip to start at a terminal, and/or "prevTrip" when the bus is currently serving the previous trip and the information presented 'wraps around' to the following scheduled trip. -->
<ProgressStatus>layover</ProgressStatus>
<!-- Optional indicator of whether the bus occupancy is deemed to be "full","seatsAvailable" or "standingAvailable". If bus occupancy information is not available, this indicator is not shown (aka hidden.) -->
<Occupancy>seatsAvailable</Occupancy>
<!-- The vehicle ID, preceded by the GTFS agency ID -->
<VehicleRef>MTA NYCT_7582</VehicleRef>
<!-- Depending on the system's level of confidence, the GTFS block_id the bus is serving. Please see "Transparency of Block vs. Trip-Level Assignment" section below -->
<BlockRef>MTA NYCT_20120902CE_JG_24900_B35-26-JG_1503</BlockRef>
<!-- Call data about a particular stop -->
<!-- In StopMonitoring, it is the stop of interest; in VehicleMonitoring it is the next stop the bus will make. -->
<MonitoredCall>
<!-- The GTFS stop ID of the stop prefixed by agency_id -->
<StopPointRef>MTA_308214</StopPointRef>
<!-- The ordinal value of the visit of this vehicle to this stop, always 1 in this implementation -->
<VisitNumber>1</VisitNumber>
<!-- Predicted arrival/departure times in ISO8601 format -->
<ExpectedArrivalTime>2015-06-04T10:46:08.361-04:00</ExpectedArrivalTime>
<ExpectedDepartureTime>2015-06-04T10:46:08.361-04:00</ExpectedDepartureTime>
<!-- SIRI container for extensions to the standard -->
<Extensions>
<!-- The MTA Bus Time extensions to show distance of the vehicle from the stop -->
<Distances>
<!-- The distance of the stop from the beginning of the trip/route -->
<CallDistanceAlongRoute>3038.9</CallDistanceAlongRoute>
<!-- The distance from the vehicle to the stop along the route, in meters -->
<DistanceFromCall>1101.7</DistanceFromCall>
<!-- The distance displayed in the UI, see below for an additional note -->
<PresentableDistance>5 stops away</PresentableDistance>
<!-- The number of stops on the vehicle's current trip until the stop in question, starting from 0 -->
<StopsFromCall>5</StopsFromCall>
</Distances>
</Extensions>
</MonitoredCall>
<!-- The collection of calls that a vehicle is going to make. -->
<OnwardCalls>
<!-- A stop that the vehicle is going to make, if the detailLevel is set to calls -->
<OnwardCall>
<!-- The GTFS stop ID of the stop -->
<StopPointRef>MTA_308215</StopPointRef>
<!-- The ordinal value of the visit of this vehicle to this stop, always 1 in this implementation -->
<VisitNumber>1</VisitNumber>
<!-- The GTFS stop name of the stop -->
<StopPointName>5 AV - GARFIELD PL</StopPointName>
<!-- SIRI container for extensions to the standard -->
<Extensions>
<!-- The MTA Bus Time extensions to show distance of the vehicle from the stop -->
<Distances>
<!-- The distance of the stop from the beginning of the trip/route -->
<CallDistanceAlongRoute>3267.1</CallDistanceAlongRoute>
<!-- The distance from the vehicle to the stop along the route, in meters -->
<DistanceFromCall>1329.9</DistanceFromCall>
<!-- The distance displayed in the UI -->
<PresentableDistance>6 stops away</PresentableDistance>
<!-- The number of stops on the vehicle's current trip until the stop in question, starting from 0 -->
<StopsFromCall>6</StopsFromCall>
</Distances>
</Extensions>
</OnwardCall>
... more OnwardCalls
</OnwardCalls>
</MonitoredVehicleJourney>

The PresentableDistance field:

The logic that determines whether stops or miles are shown in the PresentableDistance field is below:

show distance in miles if and only if:

(distance in miles to _immediate next stop_ is > D) OR (distance in stops to current stop is > N AND distance in miles to current stop > E)

in other words, show distance in stops if and only if (the below is just the inverse of the above, according to DeMorgan's law):

(distance in miles to _immediate next stop_ is <= D) AND (distance in stops to current stop <= N OR distance in miles to current stop <= E)

Show "approaching" if and only if:

distance_in_miles to immediate next stop < P

show "at stop" if and only if:

distance_in_miles to immediate next stop < T

Current Parameter Values:

Parameter	Value
D	.5 miles
N	3 stops
E	.5 miles
P	500 feet
T	100 feet

Transparency of Block vs. Trip-Level Assignment

MTA Bus Time tries to assign buses to blocks- a sequence of trips that start and end at a depot. This allows the system to make a statement about what a bus will do after it reaches the end of its current trip.

However, there is not always enough affirmative and corresponding evidence to make such a strong statement. In this case, MTA Bus Time falls back to a trip-level assignment, where it just picks a trip from the schedule that is representative of the route and stopping pattern that the bus is likely to pursue.

The SIRI API now reflects this distinction as described here and in other items below. If the assignment is block-level, the new BlockRef field of the MonitoredVehicleJourney is present, and populated with the assigned block id.