Updated March 1 at 10:00 am: Data for the Queen route for the months of October and November covering the period of split operation are now available for viewing.
George Bell has put together an application that displays the TTC’s vehicle monitoring data as an animation. The effect is something like NextBus, but for historical data. You can watch streetcars bunch now from the comfort of your own computer.
He is using the same source data from the TTC as I used for my analyses. At this point, only St. Clair for January is available.
A few notes from George:
I’ve put together the beginnings of a bing maps viewer for the data. Love for feedback from the community.
Just a word to people before clicking on the link – the data files for each day are about a meg or two each. Silverlight is required, and if you don’t have it a link will be shown so you can get it.
Please leave general comments in this thread, and send bug notes, requests for fixes, etc. to George using the link provided on his site.
When you view a day’s data, be sure to zoom in so that the route fills your screen and you watch things unfold in full detail. January 8th, a date already mentioned in my analytic article, gives a visual feel for the complete chaos of the line’s behaviour.
There is part of me that SCREAMS out that the TTC should make this data and the presentation format available for every route, every day. Anyone who wants to know how a route behaved would only need to pull up its animated version.
Real time would be even nicer. I can imagine a route supervisor (or an interested member of the public) sitting with an iPad to keep track of the service.
Wow! Having this in real time would SURELY be a great way to manage transit routes, I hope someone at TTC is paying attention! (If George did this in a weekend one must wonder why the Next Bus system has taken 3.5 years to, sort of, be done for one streetcar route.) The announcement is still on the NextBus website – ” Toronto, Canada — September 11, 2006 — Grey Island Systems International, Inc. (TSX VENTURE:GIS) is pleased to announce that the Board of the Toronto Transit Commission (TTC) approved the recommendation for award of contracts for the Next Vehicle Arrival System to Grey Island for its NextBus System. Total value of the contracts is $9,920,000.” ) Hmmm
Similar technology in a portable format is currently being used by supervisors in real time for the 501 Queen route. This has been in place since early last fall. Real time includes car number and deviation from schedule. GPS is still relatively new to the TTC, and as far as I know not all of the buses are equipped yet. New things are in the works, and hopefully the buses are soon to come. The TRUMP unit (which is archaic, late ’80s technology) is capable of now switching from deviation of schedule to a headway format, but has yet to be used. This is probably because of the on street supervisors that already manage the headways. The TRUMP unit, and in some cases the GPS (i.e. downtown) have limitations for signal strength (valleys, etc.) and add cloud cover for GPS. This along with other factors makes real time difficult.
Steve: Yes, buses are still to come, but the streetcar fleet has been finished. I know that there was concern about the need for fairly expensive hand-held units for the 501 supervisors, but that was before the arrival of the iPad. This will put simple technology in the hands of everyone, not just TTC staff, and should make huge changes in how information is delivered to customers. (I am not plugging Apple here, simply pointing out that the idea someone needs an expensive, specialized device for use in the field really does not apply any more.)
Downtown resolution may be trickier, although the TTC used good quality GPS units to get around most of these problems. When I turn to analysis of Queen for the split operation last fall, we will see how much or little bad data there might be. One of the biggest problems with predictive displays like the old CIS was that they depended on the printed timetable which often bore no relationship to the real world. CIS would have cars roaming opposite to their actual direction of travel when cars were short turned, and sudden jumps in location (“teleportation” as I have called it) happened whenever the system managed to correct itself.
In the new GPS data, I have seen a few cars whose units are clearly not working because they report nonsensical locations quite regularly. In the animations, if you leave the scale wide enough to see the GTA, you will see the occasional car that pops up all over the place. I filtered this sort of data out of my analysis, but George left it in the tables behind the animation. I wonder if anyone at TTC is monitoring this sort of thing to spot cars that need maintenance on their GPS?
It seems to me that a simple metering system at the terminal loops should work. As a streetcar leaves the terminal loop a signal is turned red for a specific (Settable from Transit Control) time. A following streetcar would not leave the loop on a red signal.
This would mean that the streetcars would at least be spaced out when they leave the terminal loop.
Even after a major blockage (Which does not appear to be the main problem here) this process along with some judicious short turning would automatically space out the service.
I may be wrong, but I suspect that George was using historical data.
To be usefull the Next Vehicle system would need to be operated in real time, and would require appropriate displays at key stops. This would likely require customization of the software and the addition of hardware designed for outside use.
Steve: Of course George is using historical data. It is the same data for the month of January that I used to generate my charts and analyses. However, the same data is collected in real time and, among other things, drives the NextBus displays and similar real-time maps for route supervisors. Obviously, information needs to be added to make the underlying application even more useful for route monitoring — things like scheduled crew changes and information about the actual destination of the vehicle (not the fictional value on the timetable).
The TTC needs to think ahead to a time, probably not that far distant, where high quality hand-held displays will be widely available and cheap, and they should aim at that target.
This comment was sent to me via email from Brent Hooton:
Thanks again for posting this information. I always have found these analyses fascinating but even more so now that the time-space diagrams have been made even more precise due to the conversion from CIS to GPS.
It’s awfully tempting to look negatively upon some of these charts, especially when you see bunches of 4 or 5 streetcars leaving a terminal in a row without holding one or two back to fill a trailing gap… or when a streetcar is short turned only to re-enter service in a bunch heading the other direction. However, I’m willing to hold off and wait for the later data to see how (if) these teething pains were addressed.
It might provide some interesting context if you or one of your readers could describe what supervisors see. Subway supervisors have a “big board” with a map of the system that shows the location of every train plus the elapsed time since the most recent train at each station (which starts flashing if the time exceeds a certain time, something tells me one average headway plus two minutes). Is there anything comparable for bus and streetcar supervisors? Do they see something like the “next bus” display available for Spadina and Harbourfront? Would it help if they could see something like your service chart (the time/distance plot) generated in real time?
Steve: Yes, the supervisors now have map-format displays like NextBus and this should make their tracking of cars much easier than on the old CIS system. Having said that, it is quite clear that wharever was being used to manage the 512, it (the technology or the use of it) was not working for the first three weeks of January. When I turn to week four, you will see that a much more routine method was adopted to deal with inadequate scheduled running times, and the vehicles leave termini on a much more reliable spacing. This was achieved even before the new schedules came in on February 14.
My real complaint here is that a potential showpiece route, one which had endured so many complaints during construction, took a month after it opened to “get it right”. By extension, the TTC’s laissez-faire attitude to route management (just keep short turning things to stay “on time”) did not work here. How long have we suffered poor service on routes because of inadequate supervision and management that actively looks for ways to fix problems?
Ideally, central route supervisors, just as on the subway, should be able to dispatch cars from termini, and automated systems should be available to perform this task when service is running close to normally.
Here’s an idea (well, more than one, actually. But they overlap, unlike the 509 and 510 routes this afternoon):
At the same time as ordering iPads (or whatever devices) for the route managers, perhaps the same map with moving dots could be posted on a 27″ screen on the ticket hall wall at all subway stations, instead of the printed maps (that are so often out of date, missing, or hidden somewhere inexplicable).
The TTC would not need to reprint maps for the stations as a result of new buildings or new one-way streets; and the it would be able to say, categorically, that it is being open about BOTH its performance AND it’s provision of up-to-date, useful information to travellers. I would envision that each station would show at least the entire length of the routes that reach that station. Oh, and maybe these screens could have touch abilities for interactive provision of information (like route-planning from ‘here,’ published headways, actual headways, city information, etc., etc.). I note that they should revert to the maps (with a clock), NOT advertising, by default when nobody has touched the screen for a small time. Advertising has no place, here, except, perhaps for a time-limited overlay of the names and locations of, say, banks, restaurants, etc. that are local to the map (yes, moving maps in the buses and streetcars).
And smaller, ipad-sized versions in streetcar shelters and bus shelters (the wonders of solar power and Wi-fi/GSM). Maybe even in streetcars and buses.
Oh, and the TTC could simply provide a list of URLs the above ‘station maps’ on its web site, to replace the woeful ‘information’ available there now.
The simplicity of this is that it’s one (evidently simple) system, deployed in many places.
What a wonderful thing for the TTC to be able to say to all customers, be they at home or on a streetcar: “We use the same real-time information as is available to you on station walls, in streetcars, in bus shelters, and on our web site, because the TTC has truly entered the 21st.-century with its customers as it most important focus.”
Creating and managing a system like this on touch-enabled tablets and larger screens is definitely simple and very cheap, as George has shown.
How many birds would the TTC hit with THAT stone? (Ensuring they’re not swans, of course.)
Steve: Be careful with those stones! They have TTC policies carved on them!
Do you know if the CIS data log includes +/- schedule deviation values for each polling entry, or can this only be calculated from the actual schedule? It would be very interesting to see a +/- figure beside each vehicle icon as it travels. You’d be able to see quite clearly if any particular operator is running ahead or leaving a terminal ahead of schedule. It would also better illustrate what exactly is going on in a pack of streetcars and how they got that way. If every vehicle in a pack is running late then obviously they are going to stay that way until the latest leaders are short-turned, at least if the line is being managed solely by schedule. The problem with evening out the spacing under that method is that it would force every operator to run as late as the latest run. In the subway that leads to mid-line crew swaps, and I really don’t see this as a practical means of operating a surface line unless it happens at the terminals only. It may or may not require an extra driver to make this possible but I don’t know.
I’m really impressed with what George has accomplished so far. This app should prove quite useful, especially if it gets travel direction arrows and a few remaining anomalies in the data get patched. It also got me thinking that it would be neat to see an animated version of your line graphs with vehicle icons tracing the line graph paths in real time. That might more clearly illustrate headway variations across the whole line at any moment then the ‘street view’ can. Now if I could see both animations at the same time running in sync and the vehicle icons in the street view matching the colours of the graph tracings that would be really slick. (Okay, now maybe I’m getting a little too excited! Who ever said statistics were boring?)
Steve: Some of the older CIS data extracts I received did include schedule deviations, although I didn’t make use of this. A major problem was that CIS got a vehicle’s location and direction wrong, and so making the deviation meaningless. I didn’t ask for it in these extracts as my real concern is with vehicle spacing (ie regularity of service), not with the schedule (although I understand how the deviation info could throw light on supervisory decisions). The service on St. Clair was so far off schedule most of the time through January and early February until the schedules changed.
George is now in the unenviable position of a developer whose “clients” (you readers) have a long list of enhancement requests. I went through the same thing in the early days of my graphic analyses. If we were being paid to do this work, we would make a fortune, like all good consultants, on “change orders”, those options the client forgot to ask for or claimed they didn’t need when haggling over the base contract.
I agree that schedule information is not necessarily important if your aim is to illustrate headway irregularity. You’ve done a fine job of that. However it is of critical importance to show if line management is focusing primarily or wholely on keeping the operators on schedule. Exclusivity of this seems to be the primary reason for headway irregularities. Now that you’ve clearly illustrated the ‘ragged’ headways you need to clearly illustrate what is causing them using a visual method that the average person can understand if you’re going to achieve change. We need to expand on the message “Your service is crappy” by showing the key culprits and exactly how they act to cause “crappy service”. We of the blogosphere of course understand and appreciate how you present your data and how well that dismisses traffic congestion and other past TTC excuses as the culprits. Unfortunately, beating them over the head with their own data hasn’t produced much in the way of results (however satisfying it might have been).
If it turns out that every streetcar in a ‘pack’ is running behind schedule (or later than the trend) then you have a pretty good idea why. You can’t short-turn every car plus you can’t hold each of them at a control point because they all get as late as the latest one in the lead. They don’t care if a car short-turns out of a pack and straight into a new one because headway is not their primary concern, if at all. Also, if certain operators are leaving terminals early or running ‘hot’ routinely then we should be able to track this behaviour better from the schedule data and it might show where some of the problems are developing.
If the operational methodology doesn’t change then the management will always have failed in our eyes but not in theirs. This is because the goals of the ridership are not the same as those of management. Management looks at the pattern of cars along the line and only sees late operators not getting to change-off points on time and looming overtime. The public only sees ragged service with bunches/gaps and short-turns. In other words the TTC is managing staff instead of managing service. Demonstrating this is key but the solutions could be difficult. The TTC needs to see how managing headway as the priority could actually make managing staff easier and cheaper through overall stability of the system. That would allow both sides to see their issues through each others’ ‘coloured glasses’ and show how merging each other’s goals could be mutually beneficial.
I added the november and october data for the 501, it is up now.
I like the idea of showing cars that are running in packs, or places where gaps are big. That’s something I am working on. Visually highlighting when that happens…
Thanks George — this is great and really helps bring the data to life.
Steve, I think there’s an Easter egg for you in the 501 data: on October 10, a little after 7 am, Swan Boat 4251 makes a crossing of Humber Bay!
Some GPS ‘glitches’ may not be the fault of the units; signal reflections, like what can happen downtown amid tall buildings, can cause GPS receivers to misread their location and spit out quite wonky data. It’s a known liability of the technology.
I’m not saying this is the cause of every error in this dataset, but it’s one possibility.
Steve: If you watch the animations for Queen, you will see that a lot of the “jumps” belong to a few vehicles and continue even when they are stationary at a carhouse far from downtown. On St. Clair, there are few locations where the street is hemmed in by towers. I believe that overwhelmingly this is a hardware problem on specific cars, not a generic problem with the system.
I found what looks to be a piece of bus data on Jan 20th.
Vehicle 9415 appears on Dufferin St beside Yorkdale Mall near Jane Osler Blvd starting at 06:42:20 (coming from Wilson Yard?). It heads west on Lawrence at 06:44:00, south on Black Creek Dr at 06:49:00, south on Weston Rd at 06:52:00, west and looping south on Gunns Rd at 06:55:40 and into the loop at 06:57:20. Service on St. Clair starts at 06:59:40
Steve: Buses running to and from service on St. Clair show up from time to time.
Oh and George thank you for your hard work. This is phenomenal!