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.
Steve Munro 
It appears that the TTC are not the only transit agency having some problems with data sent to and received from NextBus. That said, I think that the TTC tend to adjust schedules very frequently which may create problems too (though it does, theoretically, allow for fine tuning to improve service!) Also, as you have pointed out many time, the schedule and what actually reaches the street, and when, tend to differ.
Steve: If NextBus is so stressed by getting new schedules every six weeks from one agency, it’s hard to understand how they remain in business serving a hundred of them.
LikeLike
503 was also more than useless this morning; only showing 3 vehicles in service; I saw at least one 503 bus pass that wasn’t on the tracker (and I was only on that route for the 5 minutes it parallels 504). Oddly 502 was much better.
Complaints to TTC yield excuses about the app not being TTC – ignoring that TTC’s own next vehicle displays are equally and identically wrong.
While there have been some TTC data problems, it would appear that Nextbus simply hasn’t uploaded the new data. Incompetence at Cubic or did TTC create unreadable data for them?
Steve: Wherever the problem lies, the TTC is not taking responsibility for the issue. I wonder if they will be as “hands off” when it comes to Presto?
LikeLike
Agreed. They completely ignore that they’ve awarded contracts to Nextbus.
Also frustrating is their reluctance to issue a simple service alert, to advise customers that the next vehicle displays in stations and at stops and nextbus data are showing incorrect information
LikeLike
This problem happened during the last new schedule in mid December, but it was a lot less noticeable. The problem is simply that NextBus is using an out of date GTFS schedule. I have emailed opendata@ttc.ca about it. I have found them to be responsive in the past.
From what I’ve seen the NextBus and GTFS schedules usually match. I suspect NextBus takes in GTFS schedule and processed it to generates its data. It’s a standard format it can get from many agencies.
Steve: NextBus does NOT use the GTFS schedule, but a separate data file from TTC that contains more info than is in GTFS.
TransSee shows off route vehicles, so you can see more streetcars but not all of them.
The old version of TransSee lists off route vehicle between your stop and the predictable vehicles.
The new TransSee 2.0 (still under development) lists all off route vehicles.
Steve: It has nothing to do with on route and off route vehicles. NextBus does not include in its feed vehicles claiming to be run numbers that are not in the schedule. You won’t see them. Nobody will.
LikeLike
In other words NextBus is pretty much useless!
Steve: Not exactly, but it depends on having the current schedules so that the run number values line up with what is operating. Unscheduled extras are a special case. They require that the TTC include dummy runs in the NextBus schedule extract and that such extras “sign on” to the system with one of those dummy numbers so that NextBus will pick it up. Even with this there can be problems because, by definition, an “extra” does not have a defined schedule to which it will adhere.
LikeLike
This service alert has been posted by TTC:
LikeLike
re: scheduled vs unscheduled runs — has something changed in the past year or two in how TTC and/or NextBus treat these?
At one time, unscheduled runs used to show up alongside the scheduled runs. I distinctly recall logging into NextBus on Victoria Day and Canada Day to see what it looked like with all of the extras on 92 Woodbine South running every minute or two. Anything signed as a 92 showed up. This year I checked it on both days and it only showed 3 buses on the route (the regularly scheduled runs) — it didn’t show any of the extras.
Steve: This depends on (a) the TTC providing for “extra” runs in the schedule it sends NextBus, and (b) the TTC actually slotting these into the service with appropriate run numbers so that NextBus will track them. One could argue that this is an architectural issue at NextBus (it requires “schedules” from which to base predictions even for extras), but if the TTC does not make provision for these extra runs, NextBus won’t track them.
LikeLike
Fun fact: The two LCD screens at St. Clair West station that show all vehicles’ departure times have been supplemented by LED displays over every bus and streetcar bay that show an individual route’s departure times. (Nowhere does the TTC tell you that what it’s giving you are departure times, by the way; you just have to know that.)
Readers will be amused to hear that the LCD screens and individual LED screens do not agree and have shown different departure times on every occasion I’ve been to that station since the individual screens were turned on last Saturday. Neither system can handle the 19:15 last arrival of the 126, either, which is still shown as departing at that time.
Steve: We have the same setup at Broadview Station. The problem is that the station screens do not update themselves on the same cycle or frequency as the individual route screens. Until it was fixed, we could have displays on the platform that were several minutes “stale” showing buses about to arrive when they had already left.
LikeLike
Surely this problem with NextBus is a simple fix. All the TTC has to do is ensure that whenever there is a schedule change that a feed update to NextBus is included in the process.
Steve: And even if something goes wrong at the NextBus end, TTC should catch this on the first day of a new schedule’s operation (a Sunday) so that it can be fixed for the first weekday of service.
LikeLike
I’m usually a fan of your posts, but I really don’t understand how you managed to write such a long-winded post about a simple data/processing error by a third party. We didn’t even have this technology a few years ago and it goes down for 12 hours and you type up a massive diatribe. Seriously? Maybe just take a step back next time and chill before getting all worked up over something so minor.
Steve: The length of this post was occasioned by three factors.
First, the underlying processes of NextBus are not well understood, and people make assumptions about what is “broken”. A short tutorial was in order, including for some TTC staff who clearly didn’t understand the situation.
Second, there were major changes on a few routes and the NextBus info was useless. Until the TTC was beaten over the head with this fact, they didn’t take the problem seriously, and did not even acknowledge they might have a role in fixing things.
Third, this has happened several times before, sometimes because NextBus has not uploaded (for whatever reason) new schedules, or because the schedule info supplied by the TTC is wrong. The last time this happened, it took over two weeks to fix. This affects not just smartphone apps, but all public “next bus/car” info displays undermining their credibility. In the current situation, we do not know for sure whether the fault lay with NextBus (failure to update) or with TTC. It was down for two days, not 12 hours, and this was a short outage because of the stink raised about the problem. We have had the technology for several years, and people depend on it to make decisions about their travel plans.
The TTC was supposed to have instituted quality control procedures to prevent this, or at least to flag it as soon as it happens. It was obvious to anyone who looked at affected routes on the first day of the new schedule (Sunday) that things were amiss, and it was easy to download the schedule data NextBus was using through their publicly available API. The date on the schedules was December, clearly the wrong info.
It should not be beyond basic management to check at each schedule change that the new schedules are actually in place on the first day they operate, that the service displays look reasonable, and to fix any problems asap.
It is this process, or rather the repeated failure of the process, and the lack of attention to “customer service” which was my topic. Not a brief outage.
The “fans” should not have to do quality control for the TTC.
LikeLike
According to the http header, the GTFS route data was last updated on Dec 23. 2015. NextBus would have received their data at around the same time. I suspect the NextBus offices where closed from the 24th to noon Eastern time on Jan 4th, so no one was there to process and upload the new data and they didn’t think it was important enough to do it from home or something.
Steve: That really does not make sense. Lots of agencies change schedules all the time, and a 7×24 service like NextBus should have no trouble putting new data into play. Heck, it should be easy enough to automate the cutover to occur in the middle of the night. It’s not as if some poor soul has to schlepp in to work at 3am and load a deck of cards into the reader.
(And, yes, I know there are many readers who have not the faintest idea that a “deck of cards” does not include a Joker).
LikeLike
I am not in IT and too young in any way to have used them. But for some reason in my elementary school we had cards from the time the School Board used them. For some reason instead of throwing them in the garbage (no recycling back then) someone left them in my school which had no admin functions.
It hits me that I know what you meant, does that mean I am old??? What a scary thought! Then again I still make phone calls with my “smart” phone I guess that qualifies me hahaha.
LikeLike
NextBus was sold a couple of years ago, their Chief Technology Officer who responded to developer’s questions was let go and new customers are few and far between. I get the impression that NextBus is just being milked for its existing customers. When is their contract up?
Steve: Don’t know. I will have to ask.
LikeLike
NextBus was acquired by Cubic in 2013. The info is on their website – which also suggests they continue to expand.
LikeLike
Though it’s a bit (or a lot) off topic, I think one of the ‘lessons’ about the Nextbus situation (learned or not) is that the TTC needs to react more quickly when comparatively small things go wrong.
Another example of an area where the TTC need to improve is installing temporary bus stops. Two examples in my neighbourhood:
172 bus eastbound @ Parliament (stop 11914) where the stop sign was attached to a streetlight pole. The pole was knocked over in November (maybe October) and there is still no sign of a bus stop, temporary or permanent, despite an online ‘complaint’ to the TTC in late November.
Then there is the northbound 75 bus stop at King St E. This was ‘suspended’ in late 2013 or early 2014 because there was construction. The construction finished in early December and this was communicated by me to the online TTC folks at that time. Nothing happened so one of my neighbours emailed Chris Upfold and was promised ‘we will get it done”. (He noted that at any time 75 stop poles are ‘missing”.) Now it’s 10 January and the stop remains suspended (and not noted in the TTC schedule) but a green dot has been painted on sidewalk to signify that someone, someday, will put up a bus stop pole there. This stop is (or used to be) a popular stop for bus/streetcar connections and it would hardly seem hard to put up a temporary pole or tape a paper Stop sign to the existing Hydro pole within a day or so but ….
Perhaps it’s time to buy a supply of temporary poles or print up some more temporary cardboard Stop signs and then ensure staff use them?
Steve: There are standard cardboard temporary stop signs that any route supervisor, given the inclination and initiative, could put up at a moment’s notice. On a related note, my local stop SB at Broadview/Danforth is in or out of service depending on which signage you look at. On the stop pole itself, in service; on the shelter, not. In fact streetcars stop there regularly.
On a related note: any word on the new bus stop poles/signage and the new format for the (difficult to understand) ‘pole schedules’ that the TTC were testing out a year or so ago?
Steve: Nope. The TTC’s bigger problem is the lag time between schedule changes and posted notices, whatever their format, due to staffing limitations and a lack of any sense of urgency to this problem.
LikeLike
Here is a suggestion: If the TTC staff responsible for this replacement is so overworked how about contracting it out? Perhaps the suggestion that this will be done may motivate some to work a little harder to get it done and keep the work in house.
BTW I recall years ago there were temporary wooden stop “poles” about 4-5 feet high and four legs to support it. Worked fine. What happened to them? KISS
LikeLike
I assume someone at TTC reads your blog – the 75 bus stop at King now has a temporary bus stop sign fixed to the Hydro pole.
LikeLike
Yesterday (Tuesday) morning, a vehicle parked in the southbound bike lane on Sherbourne just south of King caught my eye. I watched a supervisor run across Sherbourne (against the light, of course), tape a couple of temporary STOP markers to the traffic light pole, then run back to his vehicle (against the light, again, of course).
Everything about that _except_ putting the stop signage up was wrong. (Why couldn’t he just stop on eastbound King, behind the parked cars, right _at_ the corner he needed to be at? It’s like he was intentionally trying to do the least he had to, in the most obnoxious manner possible.)
But you’ll be happy to know that, as of 9:30 am, the route 75 stop northbound at King was finally marked. 🙂
LikeLike