Revised April 6 at 7:00 am: A short section has been added about Google Maps.
Revised April 5 at 10:00 pm: A section has been added at the end covering those e-initiatives which were not included in the discussion at the TTC.
On March 24, 2010, the Transit Commission received an update from staff on the status of various initiatives broadly relating to the use of information technology. These include:
Internet Trip Planner (ITP)
Next Vehicle Arrival System (NVAS)
Customer Service Disruption Notification (CSDN)
Narrowcasting
Next Train Arrival System (NTAS)
This article gives a summary of that presentation and a few of my own comments on these and other related matters.
Internet Trip Planner
The trip planner is still in its beta-testing stage. To date there have been about 820,000 page views on the planner, and this is about 10% of all traffic to the TTC.ca website. About 189,000 unique visitors have been to the trip planner so far, and there are an average of 22,000 page views daily. (To put that in context, that’s about ten times the traffic on my website on a moderate day.)
Of the 1,337 responses received, just over one third (35.55%) were suggestions. Application and data errors together accounted for just under 9%, while concerns about performance were just over 2%. Compliments ran slightly ahead of complaints at 12.43% to 9.88% respectively, and almost one third (31.29%) of the responses were not related to the trip planner.
This feedback will be analyzed in April leading to an updated version of the planner. Whether this will be a “beta 2” or “production” version is not yet known. (For non IT readers, as long as you call say something is “beta”, it’s not officially finished. Mind you, the most common phrase in computer system development is “fixed in the next release”.)
For the next project phase, the TTC intends to introduce a quick trip planner (simpler navigation into the process), alternate trip plan options, and support for mobile devices. Still to be confirmed is the scope, schedule and budget for this project.
Next Vehicle Arrival System
NVAS is publicly visible for routes 509 Harbourfront and 510 Spadina, and was for a time also visible for most of the other streetcar routes. (The first time you visit the NextBus site, you will have to navigate to the TTC, but your preference will be remembered for future visits.)
The data from NVAS are visible in three formats:
Full route maps
One of these is installed at Spadina Station, and the maps are available online through NextBus.
Next vehicle video displays
A display of expected next cars is installed at Spadina Station, and a simpler version of this is available for any stop along the 509 and 510 routes through NextBus.
The target for 2010 is to add video displays at five stations (St. Clair, Bathurst, Broadview, Dundas West, Main Street). The displays will be sized to accommodate addition of bus routes at these locations as these come onto the NextBus system.
Next vehicle LED text displays
Simplified next car displays are installed at Spadina and Union Stations. This type of display will be used in transit shelters at major stops across the system. Test units locations are:
Dundas & Spadina (505)
King & Bathurst, King & Spadina (504/508)
Queen & Spadina (501)
Bathurst & Adelaide (511)
Broadview and Dundas West Stations (505)
These are not yet displaying live data.
The target for 2010 is to install displays in 52 of 350 city-owned shelters. The choice of location is based on demand at the stops, the existence of a shelter, and the availability of power.
In subway stations, the 2010 target is to install 25 displays on platforms at the 5 stations listed above for video screens. The screens will give overall information for the station, while the LED displays will show service at specific streetcar platforms.
Several issues remain to be resolved for the general rollout of this technology including installation and maintenance agreements, stray hydro voltage problems at some locations, and contractual issues with the NVAS software vendor.
Limitations of NextBus
There are a few technical limitations of NextBus that will prove challenging in the TTC’s environment. The system is driven by a “schedule” model, and each vehicle is assigned to a predefined unit within the model. When a vehicle is short-turned or goes off route, manual adjustments must be made. This is a particular problem for diversions and other route disruptions which tend to occur at precisely the time when reliable “next bus” information is most needed.
Another limitation, although work on this is underway by the vendor, is that as a schedule-based system, it was not intended for routes that are managed to a headway whose value may change depending on circumstance.
In a future article, I plan to let the vendors of “NextBus” talk more about the capabilities of their system.
Text Messaging
By July 2010, the TTC hopes to have about 800 streetcar stops labelled with a code number for next vehicle arrival. This code can be used as a text message to a system that will return next vehicle arrival information.
The same codes will also be used in the NextBus website (handy for mobile users) and other applications such as the trip planner and online schedule lookups. How long it will take to complete this integration is not yet known.
Customer Service Disruption Notification
This service is already operating for subway delays, and is occasionally used for major bulletins about surface route events. The subscriber base is 18,900, and increase of nearly 3,000 in early 2010.
The premise of this system is that a rider would subscribe to information notices about one or more routes of interest, and that outgoing notices would be tagged for delivery to subscribers to the affected route(s). Future enhancements will allow riders to subscribe from multiple email addresses, receive information about surface routes, limit notices to specific routes, times and days of the week.
This technology is limited by the delivery mechanism for email. Email finds its way to users through various intermediate steps, and each of these can introduce delay to the process. One example of delay is that your email client (whether it is on a desktop machine on a mobile device) only checks for new mail every “n” minutes. Messages arriving in your account’s inbox won’t get to you until the next time your device checks in. Other similar delays exist in the Internet’s email delivery machinery.
By contrast, a text message is, by definition, to be sent “now” and it tends to travel more quickly through the network. If you subscribe to a Facebook page via text message, you will get notices when the page is updated, and this can be done for the TTC’s own page. As I was writing this article, I received a text message alerting me to a delay at Osgoode at 4:24 pm, and the all clear came via text at 4:30. The email advising that there was a problem did not arrive until 4:38, and it came together with the all clear message.
My Blackberry received email from another source at 4:32 pm between the arrival of the “all clear” text message and the delivery of the eAlert emails. This indicates that the emails had not arrived in my inbox from the TTC until that time even though they were actually sent at the same time as the text messages.
This shows the difference in delivery mechanisms, and a limitation on timeliness of notices that is out of the TTC’s hands.
The TTC is now working on design for a text message based version of the notifications with a target implementation date of late 2010. One problem with such an approach will be the length constraint for messages in this medium, and another is the per message fee charged to the TTC for this service.
What is needed is a mobile version of the current disruptions information with all sources of information — emergencies, diversions, recent route changes — available via a simple menu for one or more routes to which a rider could “subscribe” as a saved query (a “frequently used address” complete with parameters). Rather than receiving all alerts, a rider would call up their subscribed routes for any current alerts or notices. This would eliminate delivery delays, and would confine traffic between riders and the central system to ad hoc queries rather than an ongoing stream of messages.
For those whose mobile devices do not include a browser, the text message approach is an alternative, but the TTC should aim at the more advanced devices that will become commonplace in the future.
Narrowcasting
The TTC plans an internal system for information delivery to its own staff including transit service information (with more detail than in the public version) and notices. Displays will be added in staff waiting areas at garages and carhouses as well as in Collector booths in the subway. Some displays may also be added at station entrances for information to riders.
Next Train Arrival System
This system is currently active at all stations with video display screens. Based on information from the signal system, an expected arrival time for the next train is displayed at the bottom of the display. This information is usually accurate, but can be thrown off when trains hold either for crew changes or for schedule adjustments.
Unlike NextBus, this system does not attempt to predict arrival times based on historical traffic patterns, but simply on the physical position of a train.
According to the briefing, there are 52 stations with next train information and 10 more to come in 2010:
All of the Sheppard line by June; Lawrence West, Glencairn, Wilson, Rosedale and Davisville by December.
The SRT will receive “next train” as part of the LRT conversion project.
Some stations on the University line do not have video screens, but their status is unclear. These may be bound up in the Station Renaissance proposals, but it’s hard to justify not having information available to passengers at Museum just because this might be out of place among the faux-antique decorations.
Other Initiatives
Open data
There is an ongoing discussion at the TTC about whether and what data should be routinely made available via a public interface. Currently, via the City’s Portal, you can obtain information about TTC routes. This data is from October 2009 and is no longer of any value other than as a template to build applications or to discover problems with the data.
Among the datasets that would be useful are:
- Current schedules and stop locations, preferably with advance posting of new schedules so that those writing apps against this data can prepare for new schedule periods in advance
- Historical vehicle tracking data for all GPS-enabled routes, updated daily, with a revolving online acrhive of some reasonable period for ad-hoc retrieval (I and others get this data on an ad-hoc basis, but a standing feed would eliminate the need for special requests and would be of great use for ongoing monitoring and planning.)
- Real time vehicle location data (There is some resistance at TTC to making this feed available, although it is the data used by NextBus and is, in effect, available through that site in a digested format.)
Automated fare collection / Presto
We have not heard from either the TTC or Metrolinx on the status of the Presto smart card project beyond its continuing small-scale rollout through the 905 and in selected TTC locations. Among the issues yet to be discussed publicly are:
- Why did the estimate for TTC implementation rise from the original $150-million to over $450m?
- How much money has Metrolinx (or any other provincial agency) spent on the project on its own?
- To what extent is Presto compatible with current payment system standards and capable of being adapted to other “media” such as mobile phones, proximity reader capable credit cards, etc? Was any re-engineering of Presto required to accommodate newer payment media?
- What fare structures can the back-end system of Presto support, and does this system constrain future choices for a GTA-wide fare structure?
Mobile device coverage in the subway
At last report, the TTC was calling for proposals from mobile service vendors. The infrastructure required to support this service is considerable, and it is unlikely we will see mobile coverage until 2011.
TTC.ca mobile device support
Parts of ttc.ca are decidedly unfrienly to mobile devices because of the peculiarities of their browsers. Gradually this is changing, but it’s a long process.
Google Maps
The TTC plans to make its schedule information available to Google Maps so that the trip mapping feature will work for trips involving the TTC. One issue that has come up with Google is that the frequency of TTC schedule changes (every six weeks or so) poses a problem.
To what extent this is a Google problem, and to what extent this is a TTC problem (a new staff position must be created to massage internal schedule data into Google’s standard format) is unclear. Once this data format exists at TTC, it would make a good candidate for export via the Toronto Open initiative for use by other application developers.
At what point will more people use Google Maps rather than the TTC’s own trip planner? How much will the TTC invest in ongoing development of its own software to adapt to new computing platforms? Time will tell.
Steve Munro 
I can’t remember where I read this but according to the source: The NEXT TRAIN is not live
3 minutes = train leaving previous station
2 minutes = on the way
1 minute = about to arrive into station you are waiting at
Steve: No, the values are different depending on where you are. For example, westbound at Broadview, the 1-minute display means that the train has left Chester. 2 minutes shows it is between Pape and Chester. 3 minutes shows it is east of Pape. Add 1 minute for each station further down the line.
The funny thing is that I seen “train is in station” and train is getting into the station but then NEXT TRAIN xx shows up before the current train completely stops on the station.
Steve: The display changes from “train in station” to “next train” when the train is off of the track circuit at the station entrance plus a short allowance for the polling/update cycle. In a few locations, the approach circuit (and its associated signal) are a little ways down the tunnel, and so the tail end of a train can still be off the end of the platform when the display changes from “in the station”.
I think the next vehicle is based on schedule and not on gps/live locations.
The Spadina station streetcar 510 map is so horrible, the circle with directional arrow is too big of a symbol, they bunch up and you don’t know if the 510 symbol is NB or SB. The 510 NB and 510 SB lines should be slightly separated for clarification purposes.
We all know so many of the transit vehicles do not stick to schedule. The next vehicle in xx would then become useless. It HAS TO be based on the actual vehicle, I am sure the TTC would get a GPS unit far more “powerful” than the GPS unit that my mother got for her driving at BEST BUY or the ones on my Blackberry or your Blackberry.
Steve: Yes, the TTC uses a commercial grade GPS to avoid (as much as possible) problems with signal reflections in built-up areas. The next car info is all based on actual vehicle locations plus a predicted travel times based on historical behaviour of cars at the current locations and times. This information is “learned” over time by the NextBus software and is proprietary to that system. The actual vehicle locations are TTC data. If you look at the mapping system put up by George Bell for the GPS-based data I passed along to him, you will be able to watch routes for entire days to see how they behave. You will also see occasional data points where cars appear at weird locations due to GPS resolution errors.
Were you aware if you stand on the North side of Bloor station you get 2 bars on your blackberry?
Steve: You are close to the tunnel opening north to Rosedale and to a ventillation shaft. You can also get good signal in most places in Broadview Station.
If they get signal on the stations, will that be the tunnels only? the platforms only? mezzanines? bus bays?
I know Main Street station has signal on it’s bus bay (and so does Don Mills), will the mezzanine get signal or just the subway platform, both?
Steve: Don’t know. Places with signal now depend on whether you are at or close enough to the surface.
I was told the TTC spend 400,000 on the trip planner … that makes Miroslav cry.
I wonder if they contacted the myttc.ca & Brian Gilham(sp?) for input on the TTC’s “official” trip planner and updates/notices.
I don’t trust any of these e-initiatives that are based on schedules … The schedule on the bus stop pole and on the website on MANY locations are completely wrong.
Steve: Info on schedules at stops is notoriously out of date, especially where there is a large-scale change and they take forever to install new schedules (if ever). On the website, it seems to be spotty, and I suspect this is an internal process issue. I do know that they will need someone to manage the interface with Google Maps, and while they’re at it, they should also ensure that the internal info is up to date.
Their trip planner gave me regular friday schedule instead of holiday schedule (when I did the schedule, one of the routes involved is every 30 minutes).
I wonder if they have asked you for your input or they just ignore you.
Steve: I give them occasional suggestions, but it often takes a long time to see any movement.
LikeLike
I forgot to add this:
Eglinton Station last friday 23:01 Southbound
TTC documentation says 4-5 minutes outside rush hour. As far as I am aware friday 1 minute after 11pm, it is not rush hour and I could be wrong so please correct me on this if I am wrong.
I seen 8 minutes then 7 then cuts down to 3 minutes (thus 6,5,4 not showing up).
Yes, even this little “error”/boo boo/screw up matters. Actual location is better than based on schedule.
Steve: Yes, the times southbound to Eglinton do not behave properly. I have seen this often myself, and suspect it’s a question of how the system is programmed.
LikeLike
How useful are those NEXT TRAIN subway messages anyway? The trains are so frequent, who cares? And the text is so small you can barely read it from a distance. The only NEXT TRAIN indicators that made any sense were the old mechanical ones that would GONG from a hyphen when the 3-route system was in effect. These new ones are pretty useless given that all trains go to the same place. Do the new display signs identify the St. Clair W. AM short turns? … nope!
And, at Downsview, when both platforms are occupied, there is still no NEXT TRAIN flashing light or display to tell passengers which train is actually next. The only way to tell is to look at which train is more crowded.
Steve: Actually the next train times are handy for two reasons. First, they have a calming effect if the number is low. Your train is really nearby. Trust me. When the number is higher (especially when it’s not changing), then it’s time to consider alternatives. When the display says “Information not available” on a black bar, it’s time to start walking or figure out an alternate route before they make the announcement of a delay. To fool you, occasionally, this display will appear even though the trains are running.
LikeLike
Steve — has there been any discussion about integrating NextBus with the CIS upgrades as a means to address the “manual update” requirement when vehicles deviate from schedule?
Steve: As far as I know, the route supervisors and/or central CIS staff will have to manually update the system whenever a car goes off schedule. This is something I plan to talk about with NextBus as it will cause big problems with “lost cars” not showing up as part of a route’s service even though they are actually running on the line. Operator-initiated short-turns, or ad hoc changes at off hours when supervisory personnel are thin on the ground, will be a particular problem here, and yet this is exactly when people most need accurate info.
I can appreciate some of the complexities NextBus is facing with the TTC, but I think an open discussion of this is needed if only to “manage expectations” about the limits of the next vehicle info.
LikeLike
The TTC seem to regard schedule and geographic data as if they are trade secrets with commercial value. Or maybe they’re just embarrassed because the data reveal just how poor service really is on the 506.
It boggles my mind that they could’ve spent $400,000 on a trip planner that is years late and still unfinished and which could’ve been implemented with Google at a fraction of the price. But what’s even worse is the stubborn refusal to just release the data when it was clear that the internal version was so delayed and buggy.
I asked Brad Ross about this and he said they were purposely waiting until their own trip planner was ready. To protect egos? To justify the enormous waste of money? Is there any accountability on this stuff?
Why are they discussing “whether” to release data publicly? Why is there any hesitation at all? This is a publicly-funded service operated for the public. The data belong to us.
LikeLike
Some things I’ve noticed from working with the data … (and would love feedback on if people have more info, but present here mainly as a way of explaining some of the difficulties with the data)
1) ~10% of the data would qualify as “off-route” with probably 2-3% being “offroute-incorrect”, the other 7% being “offroute-deadhead” so it is important to clean this data…having accurate and up to date route information would help in this immensly … but given the number of routes (when buses are included) and the amount of construction/accidents/seasonal changes this would be a big job. Although I assume that the data being provided to google will also be provided to everyone else …
2) The amount of computation to accurately filter and make use of the data is not small … 12 million records for 2-3 lines for 4 months. Luckily the data can be split fairly easily by route to be processed on seperate machines if necessary …
3) I’ve yet to figure out a good way of showing direction on a map when vehicles are close together – if someone has an example …
4) I’d be interested in getting more data from other systems in the area as well as GO Transit … being able to compare service between systems would be interesting …
Also, wrt the subway, during Nuite Blanche I just missed the subway at Bay at 4am or so, and the TV said 37 minutes … which I thought was an extremely random number (needless to say I didn’t wait around to find out if it was accurate) … I’d be interested to find out what the maximum number is … 31 stations on the line …
I’m excited to hear from the nextbus guys!
LikeLike
Any progress to report on the Google Transit front? It would be nice to get all the Ontario and Quebec transit agencies on to Google in addition to GO Transit, AMT, VIA Rail, and Ontario Northland. A shared trip planner that all agencies can be on seems so much more powerful than a TTC only planner. Perhaps the Google Transit piece falls under the “almost one third (31.29%) of the responses were not related to the trip planner” and “Open Data”.
Steve: I have added a section about Google to the end of the article.
LikeLike
I fine Next Train somewhat useful. If it says 5 minutes to Next Train, I sometimes head back upstairs and grab a newspaper, etc. It’s also reassuring, particularily in the evening.
On one mid-day occasion on Danforth it said 11 minutes as the previous train pulled out. And though I figured it might be an error, it was about 9 minutes before the next train showed up – so it was very useful in indicating that there was some kind of delay.
The one frustration I have, is that I often get on Danforth westbound between 9 and 10 AM. And at that point many of the trains are out-of-service heading from Kennedy to Greenwood yards. However Next Train does a countdown to the out-of-service trains, even announcing it is in the station; when it just roars through without stopping. I’ve complained to TTC about this a few times, but they don’t seem to care about the issue.
Steve: This is a good example of the problems of a limited application of technology. The system knows a train is there (it might even be a work train), but not whether it is in service. We can only hope that they have taken such nuances into account for the new signal system on the YUS.
There is a related problem on the surface network where the NextBus system only knows where a vehicle is scheduled to go (or about updates that are manually entered in the system), not where it is actually going. No information about the destination is fed into the vehicle monitoring data stream (such as the code for the destination sign display), although this may be added as part of a future system upgrade.
LikeLike
“Some stations on the University line do not have video screens, but their status is unclear. These may be bound up in the Station Renaissance proposals, but it’s hard to justify not having information available to passengers at Museum just because this might be out of place among the faux-antique decorations.”
Perhaps they could make it appear like hieroglyphics in an Egyptian Cartouche.
LikeLike
Regarding Google Transit, I have I have heard from a number of sources recently that Google is not actually accepting data from new cities right now in any case — and that it is not clear when they will be doing so again. Perhaps that was just an excuse, perhaps not. But I thought it was worth mentioning, especially considering how many people think it would be perfectly acceptable to rely on Google’s good graces for a trip planner rather than have the TTC be in control of providing this functionality itself.
LikeLike
The whole process of predicting when the next vehicle will arrive is not far removed from predicting the weather – the further out it is, the more likely conditions will change before it gets here.
The key is that it can give a rough idea of what to expect, which is far better than only knowing what is happening in the few hundred metres of visibility from where one is waiting for a vehicle.
From using VIVA in York Region, one can see how the system is constantly recalculating the estimated time of arrival based on changing conditions. In one case, I was waiting for a bus and could see it at the next stop (about 300 metres away) while the display had just changed to a “2 minute” prediction. The bus then pulled away from the stop and made it through the tail end of a green light phase, causing the display to update to “1 minute” less than 15 seconds from first displaying “2 minutes”. It seemed to me that the software was assuming a red light phase as part of the 2 minute prediction, which is likely to occur in this situation, but when the GPS update indicated that the red light phase was not part of the picture, the prediction was revised downward.
The same holds true when the prediction has to be revised upward. Unfortunately, people do tend to think something is broken if it displays “X minutes” for more than 60 seconds, let alone when the number INCREASES as time moves forward. As I said above, this is not all that different than a Monday weather report saying that rain is likely on Thursday afternoon, and it ends up coming Wednesday evening or on Friday morning.
LikeLike
I have seen the effect of adding local transit information to the Google maps. A couple of months ago I used the GO Google service for a route from Bramalea to Union at a time when there was no direct service. I expected a Bramalea to York Mills, then subway to Union. What I got was Bramalea to Bramalea GO, 407 service to Pickering then wait for the first inbound train of the morning to Union (elapsed time 6.5 hours). Since then York transit has been added (but not TTC) and it suggests I take Brampton/York transit 77 from Bramalea to Yonge, then wait 1.5 hours for the GO Barrie-Union bus. When TTC is added it should then show 77 to Finch and subway to Union.
To work properly we need all of the available transit companies involved.
LikeLike
Re: excluding out of service trains on NTAS …
The trains would have to carry transponders to do that. Interestingly enough, the old signs with the bells could display PRIVATE and NOT IN SERVICE when a train whizzed by, although I never saw the private one used.
If anyone ever uses Islington Stn., there’s an old mimic board at the end of the platform for local tower control, and you can see where all the trains are on that segment. Much better than a “next train in 3 mins” message that stays that way for 10 mins.
Steve: The TTC once used the “indentra coil” system with wayside and onboard loops to identify trains.
LikeLike
“a new staff position must be created to massage internal schedule data into Google’s standard format”.
Is this a one-shot fixed term position to create a programme of some sort to convert from one format to the other (good), or a permament on-going position? (bad).
Steve: It’s a permanent position to handle the massaging of data into Google format.
Once TTC data is on Google Transit, then most users from outside Toronto will want to switch, so they can do multi-agency planning in one place.
As for the frequency of TTC schedule updates, my understanding is that Google “checks” for new data on the transit provider’s server about once a week. Therefore, if TTC gets their new data online at least a week before it takes effect, there won’t be any problems.
Steve: I cannot help thinking that the “explanation” given by the TTC is a bit shaky and self-serving. It does not square with other reports that the TTC was simply holding back on making info available to Google to avoid competition with their own planner.
LikeLike
This was clearly intended as a good-news presentation to show forward momentum. Good on them. They were pretty evasive about what they’re doing on the open data front. Lots of evaluation, not a lot of action. I don’t know why it’s so hard.
There are technology-related projects that are unfunded and dead in the water. The ecommerce project to let people purchases passes online and with their phones looks like it’s going to get cancelled unless funding magically shows up. I don’t know why it’s sitting on the sidelines when there’s so much attention over customer service problems. I guess they’d rather blow a half-billion on Presto?!
LikeLike
Even if the new signal system can’t, Transit Control surely must be able to distinguish between in service and out of service runs.
Steve: Yes, but they would still need an interface to tell the “next train” system what to display as the status such as “next train is not in service”.
LikeLike
Any word on when NextBus will return to the non-Spadina streetcars, or why they are holding back despite the fact that it obviously worked well enough?
Steve: Foot dragging at the TTC appears to be the main culprit here.
LikeLike
While the next train info is handy, and next bus is handy on heavily travelled routes, where there is a critical lack is on infrequent routes. The route page with the schedule is where the lack is, if a bus is missing or dead, then the wait times can be long enough to be dangerous in winter.
I think that most people would be happy if that page had a the next bus is xx minutes ahead or behind schedule.
As for Presto, I think they are spending tons of money to make it fit the TTC’s circa 1929 fare system, rather then looking at what new opportunities for fares such systems bring to the table.
Steve: There is no indication that the TTC’s fare system is particularly complex. It is fashionable these days to blame the TTC for everything, but the province and its agencies are just as capable of wasting huge amounts of money. Let’s get the real story.
LikeLike
For those who are interested … google’s site about the details of their transit feeds (there is also a message board if you are looking to find out more).
LikeLike
The cost of the Trapeze trip planner over 5 years is actually in the neighbourhood of $2,300,000 (according to TTC meeting minutes).
Nope. Though to be fair, by the time they awarded the contract we still didn’t have accessible routing, which was a requirement of the RFP. That said, they still don’t have good accessible routing.
Also: I find it a bit ridiculous that the time to deploy a 2.3 million dollar off-the-shelf trip planner was over two years.
On a somewhat related note, about a year after MyTTC.ca launched they started an email notification service called “MyTTC e-alerts”. Just thought that was funny 😉
LikeLike
Wogster: Get it right … It’s not a circa 1929 fare system, it’s a circa 1975 fare system.
I suspect Presto will be totally obsolete and out of date by the time it’s rolled out, just in time to spend more money to get a “more current” replacement, so this could go on for years.
LikeLike
I’m slightly confused about this GPS tracking initiative. I see lots of information regarding trains and streetcars…but is there any timeline as to when NextBus will start tracking…..um..buses? Since Transit City is being pushed further back, buses will remain a crucial part of the system particularly in the east end. The TTC really needs to get the scheduling of buses to be more reliable for riders out here.
I also agree with Wogsters post about the “infrequent routes” needing more attention when it come to live route information. I have always found it incredible that when the windchill is -30C, the city will publicly warn people not to be outside more than 10 minutes, yet a TTC customer could end up waiting 40 minutes in front of a building because a bus didn’t show up.
Steve: The TTC is working on installing GPS units in its bus fleet and integrating them with their vehicle tracking system through 2010 with a target for completion late this year. The intention is to turn on sections of the network on a rolling basis as the updates proceed. However, given the foot dragging about the rollout of NextBus for streetcars, I am not holding my breath.
LikeLike
But the next train displays CAN display “next train … is out of service” ! At least at some stations, I’ve seen it at upper St George when they’re shuttling trains around in the mid-afternoon. I’ve seen it often enough that it’s clearly a regular occurrence. It might be a special case because of the crossovers and various switches in the area, though in any case it seems highly illogical that they wouldn’t try to do something about deadheads on the Danforth line.
LikeLike
Robert Lubinski: “I suspect Presto will be totally obsolete and out of date by the time it’s rolled out, just in time to spend more money to get a “more current” replacement, so this could go on for years.”
Presto is a relatively new fare innovation, so unless it will take the TTC another 50 years to implement it, it won’t be “totally obsolete” – just look at how long TTC’s tickets and tokens have lasted. Besides, the initial costs of Presto may be high, but in the long run the TTC may very well save money. For one thing there’s no need for users to hoard Presto cards (as they did with tokens), meaning that it will be easier to streamline the fare production process, thus reducing costs.
Plus, smart fare cards like Presto are easier to use than tickets and tokens. For one thing, if these cards can be “reloaded” online, then people won’t have to wait in obnoxiously long lines at the collector booth to purchase tokens or metropasses. I’ve seen (and also experienced on several occasions) tokens getting stuck in turnstile slots, something that wouldn’t happen with fare cards. And in the end, a card is easier to handle than a pocket full of coins. In general I believe that if the usability and efficiency of the transit system can be improved in any significant way (e.g. with a more usable fare system, with an information system that delivers correct information to correct people, with a transit network that’s more effectively managed), then more people will be more willing to take public transit.
But to achieve all of this, small changes must be made to the system over time. It’s time to get over the fear that by the time the TTC implements a new technology, something better will be out. That may be inevitable but if the TTC holds that mentality for, say, the next 10 – 20 years, then the system will be even more outdated, less efficient, and less effective compared to other transit systems with a more progressive culture. And let’s not forget, a complete system overhaul is much much more costly and much harder to implement than small, incremental change.
LikeLike
Al T.
Look at bank cards even over the last few years, they used to not have chips, now they do … it’s likely that the chips will get more advanced as their security is broken … cards are a relatively new invention (compared to coins and bills) and I have no doubt that as we move towards smart-phone enabled pay devices, and further ahead to personal area network pay devices and further ahead to thought controlled pay devices we’ll be upgrading presto every 5-10 years.
The question is, do we get rid of a system that has worked fine for 100+ years … there is a lot of risk in electronic systems not working correctly (see Boston’s system) … there is little risk in the current system not working correctly (I guess if we run out of copper and zinc maybe there might be some problems).
Steve: I would be happy if someone at Metrolinx would actually publish a specification of what Presto can (and cannot) do, and the TTC would publish a comparison of this with its own preferences. Right now, it’s a “yes we can, no you can’t” schoolyard tiff with absolutely no definitive information.
I also suspect that just about any fare structure that Metrolinx proposes will involve TTC riders paying more to subsidize cross-border travel by those who now pay two fares. The locals will not be amused, and this would not play well for the coming elections.
LikeLike
Is the intention to have the vehicle information signs actually distinguish between branches? The 510 Spadina sign at Spadina station, last time I checked, does not distinguish between trains short-turning at King, Queens Quay, or going all the way to Union.
If you’re heading south of King, its kind of useless.
Steve: Yes, this is a shortcoming with NextBus. I understand that they are working on an interface for another city to pick up information from a vehicle about its destination (as shown on the digital display), rather than the “official” one on the schedule. That’s still in the works, but is not possible on the streetcar system today for two reasons.
First, they don’t have digital signs, and there is no way to know what exposure is actually up on car. As a lover of the old style roll signs, I will miss them, but once cars have digital displays like buses, the code for the current display should be picked up for central use.
Second, there is no room left in the data packets being transmitted by the vehicles for more info, according to my source. However, upgrades are planned. I would be willing to bet that the TTC has not included this in the spec for the GPS rollout on the bus fleet, and therefore we won’t have branch identification on bus routes when they go live.
LikeLike
Greg Smith says:
Link to Google Transit participation page
LikeLike
Despite what has been said, Next Train does give people the feeling that it can only say 1, 2, or 3 minutes based on some non-live data. A lot of times the number of minutes stays constant at 3 for a very long time (say 5 minutes) before it suddenly changes to 2. It would have been more helpful if it actually says, say, Next Train in 8 minutes instead of 3.
Steve: As i said, if a train is held somewhere, the next train time, based on its position, will not change until the train moves off. The next train system has no way of knowing when this will occur.
Another problem with Google Maps is that Google Maps is not very accurate. There are places (my workplace is one) where Google Maps is a whole block or more off. Since TTC stops can be less than a block, the inaccuracies can throw people off for more than a stop. I think Google Maps need some way to expedite the process of correcting its third-party data.
Steve: Well, you can take this up with Google. It’s not the TTC’s fault that Google gets addresses wrong.
LikeLike
NextBus uses fixed length packets??? How original. We should introduce them to key worded variable packets!!
Steve: No, it is the TTC’s own information system, designed two decades ago, that has the limitation. NextBus picks up the data from the central TTC system, but is constrained by whatever data the TTC transmits from its vehicles.
LikeLike
Although newer equipment will eventually phase out the requirement, the TTC’s CIS transceivers forced vast portions of the older analog cellphone network to remain active when Bell cut off all their ‘legacy’ public phone users. Bell seemed to be caught off-guard at the time. ‘Brick’ cellphones live on in your local neighbourhood bus!
LikeLike
My March Metropass had a problem with its magnetic stripe. Most of the time it would not let me through the turnstiles. TTC collectors told me “you can go to Davisville and get it dealt with”. Needless to say, during business hours….fortunately not being able to use automated turnstiles was only a minor inconvenience that I could live with.
Metropasses can be used “manually”, and there’s not much that can go wrong with tokens.
The point for Presto is, what if there’s a problem with the card? The TTC will have to set up a whole system to deal with Presto card issues. It will have to be ubiquitous and available pretty much 24/7 — what’s the alternative, stranding someone on Steeles at 3 AM because their card won’t work? Making everyone with a faulty card make a stop during “bankers’ hours” at Davisville? Won’t be acceptable to riders!
That’s going to be a fairly large expense right there, to set up a faulty-card system that won’t be a horrid imposition on the public.
LikeLike
Presto media distribution and troubleshooting should be operated by Metrolinx and merely accepted by TTC, GO, YRT etc. If nothing else, that should mean a Union Station Fare Media Office rather than at Davisville HQ which is hardly a convenient location for most TTC users such as those on the Spadina or Bloor-Danforth lines who commute downtown.
The failure to promote day/week/month passes over tokens because of obsession with “free riding pass holders” has already cost the TTC substantial amounts – the replacement of the old tokens, the refit of the token machines and barriers, the reinforcement of the counting rooms and the hiring of more fare handling staff.
LikeLike