Does More Running Time Improve Service?

[This is a long article, and I won’t hold it against anyone for failing to read all the way to the end, or not looking at every page of every chart. The issue here is a system-wide one of how service is scheduled and managed using routes where the TTC is attempting to improve operations as a reference.]

At the TTC Board Meeting of December 2015, Chief Service Officer Richard Leary gave a presentation “Performance Based Service” outlining the work done to date to improve the reliability of surface routes. [A YouTube video of the presentation is also available.]

The focus of changes made to several schedules has been that end-to-end running times should reflect actual on-street conditions rather than presenting drivers with an unattainable goal that cannot be met during typical conditions, let alone anything unusual such as poor weather or unusually bad traffic congestion.

The changes to date are summarized in the table below.


In some cases, the extra running time is provided simply by widening the headway. For example, if a route takes one hour, and it has a bus every 10 minutes, that’s six buses. Extending the headway to 11 minutes would change the round trip to 66 minutes with no added cost. In theory, if this allows vehicles to stay on time, better service might actually be provided because all buses would show up as planned. That, however, depends on them being properly spaced so that their capacity is evenly used.

In other cases, where the problem is not just scheduled time but also capacity, more vehicles can be added. In the example above, a seventh bus would allow the headway to stay at 10 minutes while the trip time went up to 70. With the long-standing problems of a constrained fleet, this is only possible in off-peak periods, or by raiding other routes for vehicles.

Continue reading

NextBus Next to Useless After Major Schedule Changes

Updated January 5, 2016: New schedules have been installed at NextBus and the service on affected routes should now appear correctly.

On January 3, 2016, the TTC implemented major changes in the schedules on 501 Queen and 510 Spadina, as well as minor changes to 509 Harbourfront and 511 Bathurst. Since then, NextBus information has been wildly erratic for these routes.

There are a few underlying problems of which I am aware from past experience like this, and there are likely more, but it’s worth consolidating this information in an article.

First, it is important to understand the basics of how NextBus works:

  • TTC vehicle location information is collected by their monitoring system which polls each bus and streetcar every 20 seconds to obtain GPS readings. These are consolidated into an updated feed that is available to NextBus, but not to the general public.
  • There are two extracts of schedule data that provide the “in theory” version of service for external agencies/applications:
    • A GTFS (General Transit Feed Specification) data feed available through the City of Toronto’s Open Data site
    • A NextBus-specific feed that is not public
  • NextBus uses the real-time data plus the schedule to produce maps showing all vehicles on a route, plus predictions of arrivals at stops. The predictions are based on historical tracking of vehicles and their likely running times, not on scheduled values, except at termini where a vehicle is expected to leave on its scheduled time.
  • Downstream stops from terminals show predicted arrivals based on the schedule until a vehicle leaves the terminal. This can cause errors in predictions because the schedule and real world might differ. Conversely, predictions based on actual travel times will correct for cases where the schedule is unrealistic provided that a vehicle is actually enroute to the stop. This is a “Catch 22” situation.
  • Predictions and displays (e.g. on video displays at stations) can run “late” to the real world for a variety of reasons related to latency in updating the data at each step along the way. If the “real-time” location feed is slow getting from TTC to NextBus, then vehicle positions will not reflect the world “now”, but some time ago. If the station/stop displays do not refresh their information frequently, they will show stale predictions.
  • NextBus only displays vehicles whose “run number” (the reference number assigned by the TTC to each vehicle) is actually in the schedule. When schedules change, an entirely new set of run numbers might be in use, or there could be some overlap with the old schedule. This can cause only partial service to be tracked/predicted because some vehicles are not linked to a run number that is in the schedule NextBus is using. Problems arise either if the new schedule is not imported to NextBus, or if the data exported from the TTC is in error.

All of the apps that run on various platforms use the NextBus feed. They may present this information in different ways, but all are limited to whatever NextBus puts out because that is the only feed available.

As I write this, there is an additional problem with the NextBus display for Queen which is hinted at by the snapshot below.


Note that all of the cars show with the arrow pointing west. If you watch the animated version, some of these cars are actually moving east. Predictions are wildly inaccurate because NextBus does not seem to “know” that eastbound cars actually are eastbound. (This snapshot was taken at 5:15 am.)

The problem changed somewhat later (5:56 am) when a few “eastbound” cars did show up in the display, and in downstream predictions. However, the predictions are still wrong because they only include cars NextBus is tracking, not all service on the route.


For example, NextBus claims there will be two cars eastbound at Bathurst in 18 minutes (they are both at Humber Loop eastbound), and the next one 53 minutes hence.

It is a bit early in the day for examples, but there will likely be cars missing from displays and predictions for 510 Spadina (which has a completely revised schedule for Flexity operation), on 509 Harbourfront and 511 Bathurst (which have been revised to terminate at Fleet Loop due to construction).

Updated: The problem with vehicle direction tracking also appears to have affected 505 Dundas.

The schedule data [this link returns a large XML file] NextBus is using for 501 Queen is from December 2015 when all service operated from Long Branch to Neville rather than with a route split at Humber. (For those who are interested, search on the string “scheduleClass” to locate the start of each block of schedules available.) The situation is the same for other routes.

This type of foul-up between TTC and NextBus has occurred before and at times has taken weeks to resolve making the “service” NextBus provides of poor quality, to be as generous as possible. The problems may lie at TTC or they may be at NextBus or some combination of the two, but they are problems that should be fixed. At the very least, some basic testing should occur at the TTC’s end when there is a change to ensure that the updated schedules have been installed. If I can do this with a simple XML call to the NextBus site, then so can anyone at the TTC.

Problems have arisen in the past where the TTC’s schedule extract for NextBus does not contain complete or correct data. This will only show up with actual use, but some sort of internal quality control on the content of the extract should be possible, especially for a major change such as the restructuring of a route.

This has been an ongoing problem, and it says a lot about the TTC’s alleged commitment to “Customer Service” that it has not been fixed.