Wiki source code of ChangeLog

Last modified by admin admin on 2024/07/23 04:54

version	line-number	content
2.1	1	== Changes for Fall 2016 Release ==
1.1	2
2.1	3	SIRI Version 2 for StopMonitoring and VehicleMonitoring. now supports ##minimum## detail level, cutting data usage by approximately 50% over the ##normal## level.
1.1	4
2.1	5	== Changes for Fall 2015 Release ==
1.1	6
2.1	7	SIRI Version 2 support for StopMonitoring and VehicleMonitoring. Using SIRI version 2 and new ##basic## detail level cuts data usage by approximately 20%.
1.1	8
2.1	9	== Changes for Fall 2012 Release ==
1.1	10
	11	A number of changes are coming in the Fall of 2012
	12
2.1	13	=== Deployment of OneBusAway RESTful API for "Discovery" of static information ===
1.1	14
2.1	15	MTA Bus Time is powered (in part) by the open source {{html}}<a href="https://github.com/OneBusAway/onebusaway/wiki">OneBusAway</a>{{/html}} (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.
1.1	16
2.1	17	The documentation for the OBA RESTful API is available {{html}}<a href="https://developer.onebusaway.org/modules/onebusaway-application-modules/current/api/where/index.html">online</a>{{/html}}. The modifications to this API with respect to MTA Bus Time are described {{html}}<a href="https://github.com/OneBusAway/onebusaway-application-modules/wiki/RESTful-API-Roadmap">here</a>{{/html}}. 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.
1.1	18
2.1	19	=== Multi-agency/operator expansion ===
1.1	20
2.1	21	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:
1.1	22
2.1	23	* All stops will have an ##agency_id##/##OperatorRef## of "MTA" (eg "MTA_308209") rather than "MTA NYCT" or "MTABC".
	24	* The ##OperatorRef## parameter of the [[VehicleMonitoring>>Developers.SIRIVehicleMonitoring]] and [[StopMonitoring>>Developers.SIRIStopMonitoring]] 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.
	25	* All routes will still have the ##agency_id##/##OperatorRef## of the GTFS file from which the routes originally came.
1.1	26
2.1	27	== Changes for July 2012 Release ==
1.1	28
	29	(Full documentation will be updated to include these changes closer to release date)
	30
2.1	31	New Parameters on StopMonitoring
1.1	32
2.1	33	2 new parameters that allow you to modulate the amount of information you get back from the ##StopMonitoring## call:
1.1	34
2.1	35	* ##MaximumStopVisits## - an upper bound on the number of buses to return in the results.
	36	* ##MinimumStopVisitsPerLine## - a lower bound on the number of buses to return in the results per line/route (assuming that many are available)
1.1	37
2.1	38	OnwardCalls Starting Point in StopMonitoring Results
1.1	39
2.1	40	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.
1.1	41
	42
	43
2.1	44	Transparency of Block vs. Trip-Level Assignment
1.1	45
2.1	46	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.
1.1	47
2.1	48	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.
1.1	49
2.1	50	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.
1.1	51
	52
	53
2.1	54	Scheduled Departure Time from Terminal
1.1	55
2.1	56	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."
1.1	57
	58
	59
2.1	60	StopMonitoring Updates to Use Block-Level Assignment
	61
	62	##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.
	63
	64	(% style="text-align:center" %)
	65	[[image:wraparound.png]]
	66
1.1	67	This is indicated by:
	68
2.1	69	* 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.
	70	* 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.
	71	* The ##FramedJourneyRef## (which has the GTFS trip_id) being different for a given bus than in in the ##VehicleMonitoring## result for that bus.
1.1	72
	73
	74
2.1	75	== Changes from MTA Bus Time B63 Pilot to Production Launch ==
	76
1.1	77	Summary of changes to the Bus Time API
	78
2.1	79	JSON:
1.1	80	API calls will return JSON rather than XML if the suffix of the URL is .json rather than .xml.
	81
2.1	82	SituationExchangeDelivery:
1.1	83	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.
	84
2.1	85	New Parameters:
1.1	86	MaximumNumberOfCallsOnwards in VehicleMonitoring and StopMonitoring:
2.1	87	Limits the number of OnwardCall elements returned in the query when VehicleMonitoringDetailLevel or StopMonitoringDetailLevel =calls
1.1	88
2.1	89	Changes to elements in MonitoredVehicleJourney and StopMonitoring include:
1.1	90
2.1	91	1. Inclusion of PresentableDistance element, a UI friendly distance field
1.1	92	2. Bearing is now more accurate
	93	3. CourseOfJourneyRef has been removed
	94	4. GTFS route_short_name now in PublishedLineName
	95	5. GTFS trip_headsign now in DestinationName
	96	6. Layover status information now in ProgressStatus
	97	7. OperatorRef is now the same as the GTFS Agency ID.
	98	8. OperatorRef/ GTFS Agency ID is prepended to the LineRef element.