Weekend operations on Queen have some problems in common with the weekday service, but these show up at different times and locations. In place of rush hour effects, the line is affected by shopping and entertainment-related congestion that builds and ebbs over longer periods.
On Saturday, the service is reasonably well behaved until early afternoon, but at that point, bunching sets in. As on weekdays, there appears to be no effort to space out the service and pairs of cars travel across the city together. This is difficult to justify especially considering the long layovers most cars get at Humber and Long Branch.
Some artifacts of the CIS system show up in the chart including:
- Cars appear to arrive at Humber Loop westbound, depart immediately eastbound and operate quite slowly at the start of their trip. This is caused by my inability to distinguish the departure from Humber as a distinct event, and only the arrival time is shown. In fact, cars at Humber have a layover.
- Cars occasionally appear to reverse direction briefly because their location, as calculated from the odometer, is slightly ahead of reality. When they pass a signpost, their position is reset .
- In some cases, eastbound cars seem to take a long time make the last part of their trip to Neville (from about Wineva eastward). This is caused by CIS not reporting their progress at intervening locations, and the layover at gets counted into the travel time. This is a similar effect to the one we see at Humber for departures.
One particular event is worth looking at. A gap opens up inbound from Humber at about 11:30 am. An inbound car from Long Branch (green line) sits for quite a while at Humber, along with two outbound Humber cars (blue and brown) while one outbound car (orange) runs through to Long Branch. Those three outbound cars arrived in a pack westbound following what appears to be a dawdler (brown) all the way from Neville. The inbound Long Branch car (green) that clearly should go east ahead of this pack waits at Humber and follows the slow car (brown) who is short turned eastbound at Woodbine Loop.
At no time is there any indication of line management, and this parade of cars sticks together causing a 30 minute gap to Neville. What is worse, they continue westbound and are joined by a short turn coming out of Woodbine (grey) after a respectable layover right in front of the pack rather than into the gap it should have filled westbound.
Queen 2006.12.09 Service Chart
Headways on Queen are not regular and the operation has the same problem we saw on weekdays that cars do not leave terminals on a regular spacing. Westbound from Neville, headways stay roughly three minutes either side of the average, but this opens up, particularly in the early afternoon when aggressive short turning eastbound at Woodbine Loop begins. Even with the short turns rejoining the line westbound, the headway regular swings the full six minutes within the TTC’s “on time” target, and these swings become more accentuated as pairs of cars cross the city. By the time they reach Dufferin, headways range five minutes either side of the average.
West of Roncesvalles, headways start to open up due to short turns, and west of Humber Loop, service deteriorates badly. Headway swings of 8 to 10 minutes either side of average are common, and pairs of cars operate almost together on a line that is supposed to have 12 minute service. There are two gaps of over half an hour.
Queen 2006.12.09 Headways Westbound
Eastbound from Long Branch Loop, the average headway sits quite reliably at 12 minutes for most of the day, although there are some swings away from the target band especially following one long westbound gap. Clearly, the long layovers at Long Branch do smooth out the inbound service in this case, but it doesn’t stay smooth for long.
Comoparing the swing in headways at Long Branch Loop and those further east enroute to Humber, we can see the headways open up and the pairing of cars set in.
By the time we reach Parkside, the average headway should be 6 minutes, but the trend line sits persistently above this peaking at about 3:00 pm due to short turns at Roncesvalles. Even with the merge point at Humber inbound where cars could be despatched on a regular headway, service inbound at Parkside bounces back and forth in a range between 3 and 18 minutes.
East of Roncesvalles, the average is back down to 6 minutes with a swing of roughly 4 minutes either way (2 to 10 minutes). Again, there does not seem to be any attempt to manage service eastbound from Ronces even though the cars are sitting on their own right-of-way at the eastbound stop and could wait for an appropriate time to leave.
As the cars make their way across the city eastbound, the gaps open up and by the time we reach Broadview, gaps of 12 minutes are common.
Once we get into the Beach, the average headway stretches out peaking at 10 minutes about 3:00 pm due to short turns, an equivalent pattern to the one we saw in Parkdale.
I have already discussed the 30-minute mid-afternoon gap to Neville that was the product of poor line management, not of traffic congestion.
Queen 2006.12.09 Headways Eastbound
The short turn charts present the destinations of cars outbound from Yonge in both directions. The time scale is based on departures at Yonge and the spacing of the vertical lines shows how regular (or not) the headway is at that point. The lengths of the lines show how far each car actually travelled with no regard to how long the trip took. On Saturday morning, you can see a reasonably well behaved mix of Humber and Long Branch cars crossing Yonge westbound, and an almost continuous service of Neville cars eastbound.
After lunch, things fall apart completely. Many westbound cars short turn at Roncesvalles, and a few at Dufferin. Roughly half of the service is short-turned eastbound.
Come the evening, short turning drops off again although headways are a bit ragged (note that these are headways at Yonge, not at the terminals).
Queen 2006.12.09 Short Turns Westbound Queen 2006.12.09 Short Turns Eastbound
The next set of charts show the times taken by cars between various points on the line. Each dot represents one car’s journey between two points. The charts show a number of different pieces of information:
- When the dots stay close to the trend line plotted through them, this shows that every trip over the link took close to the same time, give or take a minute or so, and that there were few random delays that would delay cars.
- The trend line moves gradually up and down showing the changes in link times over the day as passenger and road traffic build up and then ebb.
- Where a major delay does occur, the link times spike because one or more cars took much longer to cover ground than the average.
Looking at the westbound links we see:
- Travel times run between 6 and 10 minutes with a spike at about 12:30 caused by a delay. The hump in the trend line is actually caused by this spike and you can see that without it, the line would have been almost flat.
- Woodbine to Greenwood, and Greenwood to Broadview are both flat with small variations.
- Broadview to Yonge sees the data start to scatter away from the trend line indicating that some cars are having a worse time getting through passengers and traffic than others. I have not yet had a chance to correlate this with headways, although I would expect the longer trips to be for cars that were in gaps.
- Yonge to Spadina does not have too much scatter, but does show the effect of weekend shopping traffic on Queen West with the peak coming just before 3 pm.
- Spadina to Strachan continues the Queen West shopping congestion pattern, and onward from their to Gladstone. The drops to very short link times westbound to Gladstone are a side-effect of problems with the CIS data as Gladstone appears to be a location where the actual location of cars is sometimes reset and they appear to move backwards. This fouls up the link time calculations.
- Interestingly, the section from Gladstone to Wilson Park (just east of Roncesvalles) is almost flat even though this is an area that can be plagued by spillover effects from the Gardiner.
- Running times are quite consistent all the way to Long Branch as we would expect from private right-of-way followed by a wide, uncongested road.
Eastbound links are a bit different:
- The values are flat all the way to Humber as we would expect.
- The graph for the run from Humber to Parkside is not reliable because the “departure” times at Humber appear to actually be recorded as of when a car arrives. The cars inbound from Long Branch get a layover in the early morning and often in the evening, and this is included in the “link time” to Parkside
- Eastbound from Wilson Park to Gladstone shows a rise in link times to the early afternoon. Similarly there is a slow rise in times in the Strachan to Spadina link.
- The Spadina to Yonge link shows more scatter and peaks mid-evening due to entertainment district traffic.
- Link times east from Yonge are fairly flat. The spikes in the Greenwood to Woodbine link are caused by layovers eastbound at Russell Carhouse for crew changes.
- Times from Woodbine to Neville bounce around a lot because CIS does not reliably report arrival times at Neville. Some of these “link times” include layover time at the terminal.
The point in all this is that running times between various points on the line are fairly well-behaved and predictable. There is some variation in every trip segment, inevitably, but the route should be able to absorb a regular amount of congestion of this type. We will see in a later post an example of a day where congestion got totally out of hand, but that’s another story.
Queen 2006.12.09 Link Times Westbound Queen 2006.12.09 Link Times Eastbound
The Sunday service charts are linked below. I won’t dwell on them beyond saying that they exhibit all of the problems found on Saturday but with to a much worse degree. Huge swings in headways are common, with immense gaps in service at the terminals. Pairs of cars travel together over long distances.
Looking at the service charts, you can easily see that there is no traffic congestion to speak of because bunches of lines do not exhibit the characteristic change in slant that severe congestion would produce. This is confirmed by the link time charts which show that westbound, there is some rise in the Neville to Woodbine segment, and also in the Gladstone to Wilson Park segment, but nothing to explain the complete collapse of service quality. Similarly, there is a rise in link times eastbound in the Beach during the evening, but daytime operations are fairly steady.
The short turn charts are intriguing because almost all of this activity occured in the Beach, with few short-turns at Roncesvalles.
This day gives an example of complete abdication of responsibility for line management.
Queen 2006.12.10 Service ChartQueen 2006.12.10 Headways Westbound Queen 2006.12.10 Headways Eastbound
Queen 2006.12.10 Link Times Westbound Queen 2006.12.10 Link Times Eastbound
Queen 2006.12.10 Short Turns Westbound Queen 2006.12.10 Short Turns Eastbound
Later in the month, there is a build-up of pre-Christmas shopping traffic, but these two day show how even with no untoward weather, serious congestion or delays, transit service can be a shambles.
Steve Munro 
Steve,
I really don’t understand the extent of the bunching problem. That is to say, I don’t get the cause, in particular, I’m talking about weekend service. To illustrate an example, albeit from another route.
I was driving to downtown each of the last 2 weekends, helping friends move. In the course of doing so, heading in from the east end, I took Gerrard.
On Upper Gerrard @ Woodbine, at 11am on a Sunday, I passed runs 9, 10, 11 and 12 within 60 seconds………I wouldn’t see Run 13 till Broadview. There was no indication of congestion or traffic.
The following weekend, I was on my way down on the Saturday…between 1 and 2 pm. Same thing…(some of the same run numbers too).
As you are pointing out, this not just a Gerrard problem, nor just a Queen/King car problem. In fact, on my way home from a movie on Sunday night, I witnessed the same thing on Spadina (even with its ROW)…4 cars s/b at Queen (within 2 minutes) ….1 car after 10 minutes n/b, in the very early evening.
What is the common thread, other than lousy service?
Steve: The common thread is that despite the ability to monitor all of the service centrally, there is little attempt to manage it properly.
LikeLike
Excellent detailed analysis, Steve!
Do you think some of these problems could be solved if the line was broken back up into shorter distinct routes? (I think it used to be, many years ago?)
For example, three more manageble routes could be:
Long Branch to Roncesvalles
Roncesvalles to Yonge
Yonge to Neville Loop
The only problem would be mandatory transfers between each sement, which could be seen as an undesirable feature for riders. And it takes time to load and unload an entire streetcar, too, I suppose. And it might require more vehicles.
What do you think about mandatory transfers like that? Are there really a large number of riders who are going from one end of the route all the way to the other end? Are the majority of trips shorter in nature?
It seems to make sense to use Roncesvalles as a new “transfer hub” because of the car yard and the fact that it’s got so many other good transit connections.
Even though passengers would be “forced off” at Roncesvalles, at least they can catch either the Queen OR King car to take downtown, or up to the subway…seems to me like an easier way to manage and balance service along the King/Queen corridor.
The TTC seems unable to effectively manage the entire Queen line in its current form, so perhaps a new route structure should be tested out?
Steve: I proposed some time ago a revised route structure as follows:
Queen:
Neville to Humber
Long Branch:
Long Branch to downtown via King (M-F all day until early evening)
Long Branch to Dundas West via Roncesvalles (weekday evenings and all day on weekends)
The important thing is to maintain an overlap in any new arrangement so that even if cars are short turned, riders can still transfer between segments.
LikeLike
From this and your prior analyses, it seems like a recurring theme is that cars are not being spaced properly following layovers. I am curious as to who makes the decision about the timing of cars exiting layovers, and why. Is this controlled directly by supervisors, or do drivers have some discretion? Why would they ever let cars leave in bunches?
Steve: This is entirely up to the drivers. What is so galling is that little or nothing is done to correct the situation.
LikeLike
Steve,
Would it possible or desirable to have a transit signals installed at the ends of lines.
Signals that like those in the subway absoutely enforce when vehicles must stay or could go?
Those signals then being tied either to the prescribed schedule of the route, or to minimum space time between departures.
Steve: The CIS system already has the ability to tell an operator whether they are “on time”. However, CIS has no ability to regulate headways or to tell someone how far ahead the next car might be. This gets tricky because the “car ahead” might not actually be on the same route or it may be short turning soon and therefore not “count” for headway calculations.
The other big problem is the way that CIS mistakes where a car actually is. This is an ongoing complaint by operators because their “on time” info can be completely out of whack.
At CIS control, the route supervisors don’t accurately know where cars are, and their location is plotted positionally, not as a headway. If a car goes off route for a diversion, CIS is completely lost.
The fundamental issue here (and I say this as a long time I.T. professional) is that the system is designed to report on and “manage” an ideal condition, not the world of transit operations as it actually exists. Even then, it screws up in enough ways to make the data suspect.
LikeLike
Unbelievable! I doubt most riders are aware of the lack of management, though they suffer the results. It seems like it would be cheap to fix this compared with the expense of capital projects, and it would earn the TTC a lot of goodwill. I wonder what is holding them back.
Steve: First they have to recognize and admit that they have a problem. For years, the TTC has blamed all service difficulties on traffic congestion rather than actually studying how lines work in real life. Yes, there is congestion, but a lot of this is predictable and can be managed. Delays that actually block lines for extended periods are comparatively rare.
LikeLike
Where would the Cherry Street LRT fit into the picture? The top end is at King Street East and goes down. Could the Long Branch eventually go down Cherry Street, when it is built?
Steve: That’s one place to take it, but again we risk creating one line that is too long to manage properly. Also, my Long Branch proposal doesn’t come downtown evenings and weekends.
Cherry Street may be a small shuttle until the issue of connecting under the railway and to Queen’s Quay is worked out. Thereafter, one possible service is Broadview Station to Union Station via Cherry and Queen’s Quay East.
LikeLike
When Charles asked about who determines the layover time, Steve responeded, “This is entirely up to the drivers. What is so galling is that little or nothing is done to correct the situation.”
The TTC seems to like to suck and blow at the same time. While they leave something like this that is so critical to overall operation and line management to the drivers, the supervisors have a habbit of micro-managing so many other aspects of the operation.
Case in point from a driver I know: one day while driving a bus, traffic was clogged up due to an accident that resulted in a car fire. With a shift of wind direction, his vehicle was directly down wind from the fire and all of its acrid smoke that we all know come from a car fire. With passengers beginning to cough and choke from the smoke, he decided to pull off on a side street and get around the problem and back on route.
Well, from the response from those sitting at a desk looking at CIS data and Google maps, you would have though he had committed a crime against humanity for taking his bus off route without official permission. Never mind the fact that within five minutes the order was being given to have all vehicles follow his same detour – he dared to do it before they said so – choking passengers be damned!
Maybe it is just me, but common sense tells me that something like controlling the departure time from a layover should not be up to the driver while something requiring immediate response, possibly for the health and safety of passengers, should be.
LikeLike
Why don’t you guys organize yourselves into the “Queen Streetcar Headway Control Vigilante”? Get down on the street and take down badge numbers — the first shift is Steve’s, from midnight to 6am.
It’s always been obvious the drivers are doing whatever they want, but this is nothing new. It’s been going on for years, and Queen isn’t the only route affected. In fact, they use traffic as an excuse to do it even more.
What happened to your friend Bob? What does he have to say about this?
Steve: While I am not impressed by what I am seeing in the CIS data, I have to lay the primary blame on management. Years ago, the idea of regulating service was commonplace, but when CIS came in, the TTC had the mistaken idea that everything could be handled and centralized with technology. Along the way, they forgot what managing service really looks like. If erratic headways are tolerated, they will be exploited first by a few, then by many. The really hard work is getting the organization as a whole back on track.
As for midnight shifts taking badge numbers, that’s not the point. If CIS control did its job, and if the TTC’s policy goals were to run well spaced service, not merely to keep (in theory) to the schedules, there would be no need for a “vigilante” inspectorate.
Yes, I know this happens everywhere. It showed up on King, but not as badly because running times there are not as bloated as on Queen where extensive and excessive layovers are common. When you see the data for Downtowner, it is really shocking. That will come next week, maybe, as I have other things to work on for the 501 in preparation for next week’s meeting at Metro Hall.
LikeLike
Are there any plans to replace CIS? Are there any proven off-the-shelf systems that other transit authorities use? Also, can they use the new GPS units they’ve installed for the stop announcements to get better data?
Steve: There are plans to make some small improvements to CIS, but the TTC really needs to look at other off-the-shelf software. CIS is one of those leftovers from the era when Toronto and Ontario would build everything themselves and the industry would beat a path to our door. It didn’t quite work out that way.
Yes, the GPS data will eventually be fed into CIS to replace the signpost system and this will greatly improve vehicle location data. However, CIS was never designed to manage headways, only to report on-time performance. I can think of various useful additions, but why build them when it may be cheaper to buy a product that supports many other systems and has gone through all its teething problems.
They might even find themselves with some reporting tools that produce the kind of analyses I have done.
LikeLike
Another IT professional’s perspective:
CIS is clearly something meant to be built upon. The first problem to solve is to know where vehicles are. The second problem to solve is, where should they be? CIS might solve the first problem, but misses the boat on addressing the second. Which is fine. This is how technology works: get a stable basis, and build on it, or engineer for your basis’s failings. The Internet is a cake like this, 8 layers deep.
After reading your other post on GPS positioning, I’m convinced that replacing CIS is not *per se* a solution. The problem is developing tools that can help an analyst analyze.
I claim the problem is one of visualization, not data quality. Information systems get data outliers all the time, and and ought to be smart enough to throw them out. To take an example that is only 100 years out of date, consider Etienne-Jules Marey’s train schedule rendering from France: You can see train speed, bunching, service levels at a given station, short turns, and so forth -all on one display.
I would be fascinated to know what kind of visuals the TTC uses to evaluate its routes.
Steve: Your model is admirable, but in the TTC’s case fails because they built the base and then stopped. That was two decades ago. The idea of analytical tools was part of the original promise of CIS (the sort of thing IT folk see in the glossy brochures every day), but it was never implemented.
Outliers, ah yes, outliers. I have had lots of fun building code to ferret out as many as possible, but when CIS is claiming that the same car is in two completely different parts of the city at the same time, it’s a challenge. The GPS technology will eliminate the need for CIS to guess where a car is and where it is going, and this will really clean up the data.
You mention visualization. One thing that would be really useful would be for supervisors in the field to call up real time displays so that they could make decisions based on a full view of the line, not just what they can see for a few blocks either way.
The chart you link to is, of course, the same format as the ones I use for the service charts. I don’t think the TTC has any visuals to perform route evaluations. This idea has been around for a very, very long time and the fact that the TTC doesn’t produce these as a standard tool for service review tells you all you need to know.
M. Marey has a fascinating background as you can see on Wikipedia, and a monograph on Marey’s work on aviation.
I am amused that you, he and I all share the same name, one way or another, and that your domain name, pronounced with a suitable accent, could be taken as a reference to certain ornithological forms of transit.
LikeLike
Steve
Is there room for another route at Broadview besides 504/505 or is your comment re:Cherry assuming some expansion or reconfiguration of the streetcar bays?
Steve: No there isn’t even room for the service we have there today, and streetcars regularly back up onto Broadview Avenue despite having more platform space than the old single-track loop. Part of the problem is extra running time, especially on 505 Dundas which is still turning at Lansdowne, but has enough time in the schedule to make Dundas West when the bridge re-opens in mid-December.
Adding any more tracks would require a complete rethink of the loop (and more construction that we locals would go bananas about). The TTC should have taken a bite out of the TPA lot just east of the station, but we all know that parking is sacrosanct. It’s a very, very busy station, and anytime someone suggests that a Don Mills subway/LRT be added to what is there now, I go into fits of laughter.
LikeLike
These very detailed route analyses certainly confirm that the TTCs service on King and Queen (and doubtless most other surface routes) is poorly managed (maybe ‘unmanaged’ is a better word). The analyses also show that traffic congestion, though obviously a factor, cannot be blamed for most of the gaps and bunchings. It is no good advertising a 10 minute service if IN PRACTICE it is really three cars or buses coming in convoy every 30 minutes! I completely agree that the length of the 501 Queen route magnifies these delays so splitting it in some way (I like your suggestion) makes very good sense. It will be interesting to see what the Rocket Riders meeting comes up with and whether the TTC pays any attention and, more importantly, DOES SOMETHING!.
However, I wonder if it is worth bothering about anything except maybe splitting the route until the TTC has a proper and accurate CIS/GPS system and has the ability AND THE WILL to use the data it generates to adjust service in real time. From what you say it appears that the present data is too messy and complex to be of any help with real-time route management and it can, at best, only be useful for post mortems. However, the TTC seems not to have done ANY of the kind of analysis you are now doing; it would be interesting to hear if they have done their own studies and their responses to this series of postings.
Having easy to use, current and accurate information available when making decisions is essential and I wonder if there are there examples of transit services in cities as complex as Toronto which manage transit routes properly? Is there standard ‘transit route management” software ‘out there’? Does the TTC have ANY plans (and $$ in the budget) to buy it, and then use it? For many reasons, including the human rights complaints about announcing stops, they are certainly planning, and have $$, to convert to using GPS but if the resulting information (which should be more accurate) is then not analysed and used to improve route management it is all rather pointless! There is money in the budgets for GPS but is there any money there for using the information which is collected to provide better route management?
LikeLike
It might be possible to fit all streetcars on a certain route with removable, off-the-shelf GPS equipment which could be downloaded at the end of the day to provide cross-analysis with what CIS recorded.
This could help trace the anomalies in CIS so that extra posts could be emplaced until full GPS goes live. It would also put drivers on their best behaviour knowing that their route was under analysis which in itself could produce very interesting CIS data.
The equipment could then be rotated around the routes to produce some short term improvements in CIS reliability pending the arrival of a GPS-CIS.
Steve: It’s not quite that simple. CIS uses the signposts to set an absolute location for a vehicle, and at that point, the data is correct. However, until the car reaches a new signpost, CIS may miscalculate its location (faulty odometer on just that car) or its direction (wrong guess about the route actually taken). If the car goes off route, CIS doesn’t know what to do. Using GPS to calibrate the signposts and intersection locations (which are already reasonably accurate) won’t change the problems with the algorithm for calculating the change in a car’s position or the total absence of support for off-route moves.
LikeLike