In a previous article, I examined the report on the Bunching & Gapping pilot now in progress at the TTC.
At the November 3 Board meeting, there was almost no discussion of that report, but in its place management provided a short presentation. Unfortunately, this portion of the meeting was not uploaded to YouTube, and so readers will not be able to view it for greater detail.
Information about hot spots on routes was presented in a different way from the original report. Both versions are shown below.
The original version has more granularity showing the issues specific to each route segment.
The presentation shown at the meeting included a hot spots map across the whole system, but this is not included in the published deck. I will ask TTC for a copy and add it here when available.
The important point about that map is that the hot spots are all over the city, while conventional wisdom presents this more as a downtown, streetcar-centric problem.
Results on the pilot routes have been mixed, and even this has required a high level of supervision that likely would not scale to the entire system and most hours of service. As an alternative, the TTC is considering an AI (Artificial Intelligence) tool developed at York University. Initially this would be used in an advisory manner to route supervisors who would decide whether its recommendations were valid. Later, it would directly instruct operators to hold enroute to even out headways.
A decision to hold a vehicle would take into account the relative loads of the leading (gap) bus and the trailing (bunched) one. Ideally, a bunched bus will have the lighter load and holding it to space service will affect fewer riders. This is not always the case if pairs of buses leap-frog to share the work along a route, and the “trailing” bus might have the heavier load at some points.
A proof of concept dashboard gives an idea of what might be presented to a route supervisor. This shows recommended holds, as well as the distribution of historical and predicted bunching. Note that the scale on the chart is the number of bunched buses, not the gap size to be corrected.
The challenge here will be for the AI model to predict future behaviour. Many things affect bus spacing, and some of them are not predictable. For example, irregular terminal departures can begin a process where a small gap gradually widens. That effect can be predicted and service adjusted, but the actual late or early departure is only known when it happens. Developing gaps are easy to spot along a route because the future service at a location can be predicted by what is in the few kilometres approaching it.
Congestion caused by accidents cannot be predicted, but the act of smoothing out service can deal with its results at least in part based on past experience with similar events. There is no mention of short turns or tracking of issues with buses running late due to insufficient schedule time, or the timidity of a junior operator.
Notable in the presentation is the implication of headway management, not on-time performance. The TTC needs to decide which of these it will adopt and incorporate that into terminal dispatching.
There is also the question of whether the Service Standards are too generous in defining the allowable variation in “on-time” and “headway” values. Departures are supposed to be no more than 5 minutes late, and never early. Headways on a 10-minute service like 7 Bathurst can vary from 5 to 15 minutes. If the AI tool uses these as its goal, it will perpetuate the uneven service allowed by the standards, particularly in headway management. There is also a danger that route speed will be determined by spacing service to accommodate the slowest drivers.
No computer system inherently “knows” what it is supposed to achieve, and depends on the parameters set down by its developers. If the TTC does not fully understand what “good service” should look like, an AI tool will only work toward expectations built into its design. An important component should be the ability to tighten or relax the targets for “good” service management.
TTC plans to shift the focus of its more intense supervision from the 7 Bathurst and 24/924 Victoria Park routes to 29/929 Dufferin and 25/925 Don Mills. I have collected tracking data on these routes for some time, and will publish analyses of changes in route behaviour after a few months have accumulated.
The Board approved the following motion:
Request TTC staff report back to the TTC’s Strategic Planning Committee as a part of consideration for 2026 budget priorities on the resource requirements, staffing, and operational needs to sustain a full-year Bunching and Gapping Pilot in 2026 as well as the feasibility of expanding the pilot to additional key routes across the City to improve service and reliability.
The next meeting of the Strategic Planning Committee is on November 25, 2025.
Steve Munro 
Is it normal for the City not to put up everything for public viewing? If not was this an oversight, a technical problem or done because someone said something they wish they hadn’t??
Steve: There was a technical problem that was not solved until after the lunch break. The morning portion of the meeting appears to have been lost. This is the second time this has happened with a TTC meeting, but it’s a City issue.
LikeLike
Does anyone have the contacts for the folks at York…would be interested in talking with them/helping out if they are interested…
Steve: Due to the lack of a video of the first half of the meeting when this presentation occurred, I don’t have the person’s name. I hope to get it when I get a copy of their deck.
LikeLike
Oy. As soon as I saw those two letters together, I knew the ship was lost. Fire the entire layer of upper management and probably the board, too.
Sad.
Steve: A few Board members who fancy themselves IT savvy have been pushing management to make use of AI. Let’s just say that my opinion of them is inversely proportional to the amount they push that technology. The root problem is that TTC management don’t fully understand the problem and avoid any sense they might be somehow responsible. A nice AI project will divert everyone’s attention for a while.
LikeLike
As someone once said
Using AI to carry out routine (or more complex) tasks is somewhat similar. AI can (maybe) identify patterns that are hard for a person to see but if it then tries to manage things based on existing procedures and rules it will not have happy ending!
LikeLike
I take the 7 Bathurst bus north for work twice a week, the Dupont to Davenport delays have nothing to do with park cars or left turns. It’s the light at Davenport being so short going northbound. South of Dupont to Bloor, 100% park cars.
LikeLike
An AI system for transit that doesn’t also interact with robust signal priority is a waste of time, money, and thought. I dream of a giant brain that both drives the vehicles and controls the signals so that transit is quicker and more evenly spaced out. Every time I say something like that, a person less than half my age pulls out their phone and shows me evidence that it already exists, or at least is in development. I’m not hopeful that any property in Ontario would be an early adopter, but I dream on. And it’s not that I’m against human transit drivers. It’s just that there don’t seem to be many in these parts (or supervisors or managers or planners) who care how long it takes riders where they are going.
Steve: It doesn’t help that signals and transit vehicles are operated by two completely separate departments/agencies of the city, that the TTC refuses to accept responsibility for some of its own problems, and that political capital goes to routes with 10 minute service rather than busier corridors.
LikeLike
York University has a good computer science programme with research in all areas of computer science including artificial intelligence.
You can contact Professor Dr Amir Asif at asif@eecs.yorku.ca who is a professor at the Department of Electrical Engineering & Computer Science at York University, he will get you in touch with the research team responsible for the development of this software.
The TTC needs to implement AI solutions to get rid of the completely unnecessary staff. For instance: why do we need to hire hundreds of highly paid people just to open and close doors? It is 2025 now and this is ridiculous. These kinds of things were automated in Asian countries decades ago and even driverless buses are running in mixed traffic in Asian countries such as China.
Steve: Hundreds of people to open and close doors? I think not. Both Lines 1 and 4 use one person crews, and this will be expanded to Line 2 when the ATC system is in place. New trains for the line are designed for this type of operation. The maximum number of trains in service on Line 2 is 46. Allowing for shifts and weekends, this means that the likely saving for OPTO will be maybe 150 people. This is a considerable number, but not hundreds.
LikeLike
Interesting.
When two buses bunch completely, isn’t the best thing then – at least in theory – to have everyone on the emptier bus get off and switch to the more crowded bus, and then have the fully empty bus wait so that new gap can grow? Hypothetically, if buses were really easy to get on and off — level platforms, Spanish solution, whatever — then wouldn’t that make sense? Or maybe it would just be easier to achieve no bunching to begin with?
Steve: There is no guarantee that the combined loads of the emptier bus will fit on the more crowded one, especially in the off peak when the service standards call for minimal standees. Also making that change will delay the crowded bus, will be particularly annoying to riders who had seats on the empty bus, possibly challenging for those with mobility devices, strollers, etc., and finally a really annoying process in bad weather. It would have to occur at a stop with capacity for both buses to be beside paved sidewalk with no parking. All in all, keeping the buses better-spaced should achieve better distribution of riders between vehicles without making riders on the “emptier” bus suffer for the TTC’s inability to run regular service.
I say all of this from personal experience changing between vehicles, sometimes under less than ideal conditions.
LikeLiked by 1 person
Have you received a service memo for the November 16th service change where some routes that connects to the future lines 5 and 6 will take place in preparation for the opening?
Steve: No, although some info about the Line 6 changes is already available on the TTC’s site. I await the detailed memo from TTC.
LikeLike
Hi steve, what do you think of my route proposal?
136 St. George:
Union Stn – Summerhill Stn via University & Davenport
(Northbound)
Starts at 1 Front Street (Union Station), Left onto Yonge, Left onto bay, Right onto Front, Northbound onto University Avenue, Left onto Queen, Right onto Beverly (which becomes St. George Street), Right onto Dupont, Right onto Davenport, Left onto Yonge Street, Right onto Shaftesbury avenue & Left onto Summerhill Avenue (Terminates at Yonge & Summerhill).
Steve: Convoluted and certainly not a fast way to bypass Bloor-Yonge.
LikeLike
John Bastos wrote: route 136…
Your routing around Union Station not very clear as it says Union station -> left on Yonge then left on Bay then Right onto Front. Is that via Wellington back to Bay?
Who would ride this route and where would they be headed?
LikeLike
That’s not going to happen. The TTC has given up on any service on Front St. The 121 used to provide an East-West route from the Distillery to Fort York, much of the route on Front Street. The only E-W route between King Street and Queen’s Quay. But they just gave up on running the service west of Bay Street. The City of Toronto does nothing to control traffic there and during rush hours every day, especially in the evening, Front Street is jammed with 905ers who can’t wait to get out of the city they hate back to their dull enclaves. So the TTC axed the service.
LikeLike
Steve. Why have you stopped advocating for the Scarborough LRT to Malvern that you were so desperate to build for so many years? The Scarborough subway is only one part of a network that is needed in Scarborough and not enough by itself. What happened to your advocacy of transit networks vs single lines? Seems like you have forgotten your roots.
Steve: The LRT to Malvern is supposed to be part of the Eglinton East LRT, although I have my doubts we will ever see it built thanks to diversion of all available monies to subway projects. I am glad you recognize the fact that the Scarborough subway is not enough by itself, but the future of a Malvern line is also threatened by the proposed Sheppard East extension. Malvern is not on the very coarse grid of potential subway routes, but that’s where all the attention goes these days.
The Scarborough LRT would have had its own right-of-way, no street running like Eglinton, all the way from Kennedy Station to Malvern, but that wasn’t “good enough” for Scarborough boosters. They are getting what they asked for.
And, by the way, the subway will do little for bunching and gapping of bus services, and feeding the new stations will create distortions in the bus network that could challenge, not aid, local travel withing Scarborough.
LikeLike
This will be hobbled by the apparent fact that short turns still appear to be verboten and the only tool in the box is to hold a bus… at least that’s what it looks like from the presentation where everything seems to be oriented around should a bus be held and for how long.
That may work in some cases where most buses are operating generally to schedule but one bus happens to start to catch up because it’s a little lighter, the operator left a little early etc.
It seems that in most case it’s the opposite, the leading bus starts falling behind, it gets more crowded, it falls behind more etc. and that’s why the trailing bus catches up. A hold-only strategy means
Bus 1 falls behind and therefore is delayed
Bus 2 catches up and is ordered to hold i.e. is also delayed
Bus 3 ends up having to be held too lest it catch up to bus 2
A cascading series of holds and delays that end up slowing down the route just because Bus 1 happened to luck out and arrive at a high school just as it’s letting out. The route ends up being as slow as whatever bus is slowest and most delayed. Oh and by the way, that gap in front of Bus 1 still exists.
If bus 2 catches up to bus 1, you’d be better off cutting your losses on that run and looking for opportunities to short turn bus 1 or 2 so that gap doesn’t end up carrying on up and down the route throughout the afternoon… like on so many service charts you’ve prepared…
If I was a supervisor and I was trying to bring back short turns as an acceptable tool (even if only in moderation), now would be the time to do it… either because of the new push on more active service management (i.e. the status quo without short turns isn’t working)… or use AI as the excuse (“let’s use technological tools to help us implement short turns in a better way that helps customers rather than inconveniencing them”).
Steve: You flagged an obvious gap in the possible “training” of an AI system. If it doesn’t know that short turns are possible, it won’t advise them. It could be argued that if the route is that badly screwed up, it’s time for manual intervention, assuming there’s someone around who knows how to unscramble the mess.
LikeLike
The obvious answer to this is to go through and tell the AI, these are the possible short turn locations…you could also tell them where safe places to wait are…places to go slow…stop light and stop sign locations…stop locations…create like a whole map for each route…some of this can be done with existing data…
The logic for a short turn is essentially:
1. Can we do one (is there a route coming up, will it result in excessive overtime or go over staffing limits)
2. Should we do one (is there a need for it, what is the current number of people on vehicle, cost in overtime, what is the historical success or failure rate for a short turn at this location, what do we think the current success or failure rate for one at this time will be based on traffic, history and other factors)
3. Communicate it (send out the notification, and wait to determine if it was accepted by the driver…cancel it if the scoring becomes poor due to lack of response or a rejection by driver (based on perhaps on street conditions), or if during the short turn the scoring becomes poor and there is a way to abort it – ie return to route)
4. Do it (analyze whether it’s going to work while it’s happening)
5. Score it (was it successful)
6. A final analysis can be performed to find underperforming or frequently unused short turn routes to determine if there are ways to improve their reliability or shorten them – scoring for that short turn can be reset
Where success is a metric based on whether you will improve the point in time distribution of vehicles based on headways or schedule…
Some short turn routes will have weak data for scoring – because they don’t occur in a location very often…but the score can still make use of light, traffic and time data to create a score…even without historical (bus) data…
Anyways all of the above can’t be done by humans reliably in a short period of time…so even as an advise and consent system this would likely provide better results that the existing system.
Steve: But your entire analysis assumes that this background/logic is fed into the AI engine to begin with. The issue is not the ability to construct the model, but the willingness to incorporate options into it. It’s not as if they can learn best practices from existing TTC operations, or even worse might guess at them and have them proscribed.
LikeLike
(Mike on Nov 12 12:09 am)
Yes, forgot to put Wellington in, my mistake, and people using this route would mainly be commuters, U of T students, and residents around the Annex, Davenport, and Summerhill. They’d mostly be headed downtown to Union, to University Ave hospitals/offices, or to school at U of T.
(SingaporeBill on November 12 8:00 PM)
Great, thanks for the insight! But keep in mind that this is only a proposal and I never expected this to actually become a real route anyways.
LikeLike