Changes for Fall 2016 Release
SIRI Version 2 for StopMonitoring and VehicleMonitoring. now supports minimum detail level, cutting data usage by approximately 50% over the normal level.
Changes for Fall 2015 Release
SIRI Version 2 support for StopMonitoring and VehicleMonitoring. Using SIRI version 2 and new basic detail level cuts data usage by approximately 20%.
Changes for Fall 2012 Release
A number of changes are coming in the Fall of 2012
Deployment of OneBusAway RESTful API for "Discovery" of static information
MTA Bus Time is powered (in part) by the open source OneBusAway (OBA) software. While MTA Bus Time's SIRI API is a new addition to the OBA project, OBA does have its own RESTful developer API. We will be providing access to that that API, with some minor modifications, for the MTA Bus Time project.
The documentation for the OBA RESTful API is available online. The modifications to this API with respect to MTA Bus Time are described here. This API will allow you to "discover" static/baseline information about the bus services covered under MTA Bus Time. It is, effectively, a set of web services that gives you convenient HTTP-based access to selected subsets of information otherwise available from the GTFS files.
Multi-agency/operator expansion
MTA has two bus operating agencies: MTA New York City Transit and MTA Bus Company (with GTFS agency_id's "MTA NYCT" and "MTABC", respectively). These two agencies share the same bus stops and set of bus stop ID's. While their co-existence will be invisible to users of MTA Bus Time's web, mobile, and SMS interfaces, some slight changes are required to the developer API's to handle this situation:
- All stops will have an agency_id/OperatorRef of "MTA" (eg "MTA_308209") rather than "MTA NYCT" or "MTABC".
- The OperatorRef parameter of the VehicleMonitoring and StopMonitoring calls will become optional. You should still use it when you can (it will make the responses come back more quickly) but it's not strictly necessary.
- All routes will still have the agency_id/OperatorRef of the GTFS file from which the routes originally came.
Changes for July 2012 Release
(Full documentation will be updated to include these changes closer to release date)
New Parameters on StopMonitoring
2 new parameters that allow you to modulate the amount of information you get back from the StopMonitoring call:
- MaximumStopVisits - an upper bound on the number of buses to return in the results.
- MinimumStopVisitsPerLine - a lower bound on the number of buses to return in the results per line/route (assuming that many are available)
OnwardCalls Starting Point in StopMonitoring Results
In StopMonitoring, OnwardCalls currently start after the stop that is being monitored. With this new release, they start with the immediate next stop the bus will make.
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.
Scheduled Departure Time from Terminal
When a bus has a block-level assignment and is in the layover at a terminal, a new OriginAimedDepartureTime field on MonitoredVehicleJourney indicates the scheduled departure time of that bus from that terminal in ISO8601 format. This is reflected in the Bus Time UIs as "At Terminal, Scheduled to depart at HH:MM."
StopMonitoring Updates to Use Block-Level Assignment
StopMonitoring results will now include buses that are scheduled to stop at the monitored stop according to the schedule for their assigned blocks, even if they are not yet on the trip that will serve the monitored stop. This occurs only when those buses have a block-level assignment; otherwise, they are not included until they reach the terminal and present evidence that they will continue on to serve the monitored stop. In general, this means that StopMonitoring requests will have more results. The diagram below shows an example of this behavior.
This is indicated by:
- The ProgressStatus field will include a prevTrip flag, indicating that the bus is still on a trip prior to the one that will serve the monitored stop. The prevTrip flag may also be combined with layover when the bus is laying over and scheduled to depart.
- the OnwardCalls will start at the beginning of the trip on which the bus will serve the monitored stop. That means that the first OnwardCall will be often be more than 1 stop away.
- The FramedJourneyRef (which has the GTFS trip_id) being different for a given bus than in in the VehicleMonitoring result for that bus.
Changes from MTA Bus Time B63 Pilot to Production Launch
Summary of changes to the Bus Time API
JSON:
API calls will return JSON rather than XML if the suffix of the URL is .json rather than .xml.
SituationExchangeDelivery:
The SIRI SituationExchangeDelivery element in the response only appears when there is a service change active for a route or stop being called on. It is used by the responses to both the VehicleMonitoring and StopMonitoring calls.
New Parameters:
MaximumNumberOfCallsOnwards in VehicleMonitoring and StopMonitoring:
Limits the number of OnwardCall elements returned in the query when VehicleMonitoringDetailLevel or StopMonitoringDetailLevel =calls
Changes to elements in MonitoredVehicleJourney and StopMonitoring include:
- Inclusion of PresentableDistance element, a UI friendly distance field
2. Bearing is now more accurate
3. CourseOfJourneyRef has been removed
4. GTFS route_short_name now in PublishedLineName
5. GTFS trip_headsign now in DestinationName
6. Layover status information now in ProgressStatus
7. OperatorRef is now the same as the GTFS Agency ID.
8. OperatorRef/ GTFS Agency ID is prepended to the LineRef element.
