The CBC reports a problem from two Presto users who were billed wrongly for trips miles from their actual location on a different transit system. Specifically, riders who boarded the subway at Wilson Station, and then transferred to the 52 Lawrence West bus using Presto cards with TTC monthly passes were billed for a MiWay trip at Westwood Mall.
Problems with Presto placing a rider or charging wrongly for trips have been known for quite some time. Some cases are due to GPS errors, and others due to limitations of a rule-based system for calculating fares.
Before the TTC moved to the two-hour fare in August 2018, riders could find they were billed for a new fare in cases where they made a legitimate transfer connection. This could occur for two reasons:
- The connection occurred at a location that was not defined as a valid transfer point between routes within the Presto system. Typically this happened when vehicles were short-turned or diverted and the transfer happened at a location Presto was not programmed to recognize. Transfers between cars of the same route could trigger a new fare charge.
- The vehicle did not accurately “know” where it was at the time a card was tapped because of a GPS error, and so Presto misinterpreted the transfer as a new trip.
Riders using passes on their Presto card were not affected by these problems because they paid a fixed charge, but pay-as-you-go riders would be charged a fare they should not have paid. Unless riders checked their transaction history, they would never notice the problem.
With the two-hour fare, the controlling factor is the time, not the location of the tap, and so the whole transfer point issue disappeared.
However, recently Presto extended its functionality so that TTC riders could use their card on neighbouring systems such as York Region Transit and MiWay, and this created a new way that Presto could fail. If a TTC bus reports its location in a “foreign” location, Presto could assume that they were on a different transit system, and charge for a trip there.
The specific case reported by the CBC is particularly interesting because Westwood Mall is a legitimate location on the 52 Lawrence West route. TTC buses run outside of the City of Toronto on some routes and riders can use their Presto cards to pay the outside-city fare on a TTC vehicle. However, it is clearly impossible that someone could get from Wilson Station to Westwood Mall in 6 minutes.
This brings us to the problem of how Presto deals with bad GPS data.
The plot below shows GPS data from the 52 Lawrence route taken from the TTC’s vehicle tracking system. There are 10,000 vehicle data points included here, and they clearly show the geography of the route, its branches, and the garage trips to and from Mount Dennis Garage. The blue dot at the northwest end of the route is at Westwood Mall.
However, the plot looks somewhat different if we zoom out to include all data. The cluster of dots in the lower central part of the plot is the main part of the route, but there are many dots far away from the route. When these are plotted on a map, locations range from Wasaga Beach to the middle of Lake Ontario. What does Presto do when it “sees” a tap at such a location? Does it try to map this to the nearest point that is legitimate for the route? Would a tap far northwest of Toronto be mapped to Westwood Mall, the nearest point on the 52 Lawrence West route?
There are two major issues for Metrolinx here, and this is not the trivial problem the agency presents.
First, GPS errors happen and Presto needs to deal with them. This is not a problem with the TTC, a favourite whipping boy for Metrolinx, but with GPS systems generally. This will become more important as riders whose “home” systems with local fare discounts such as monthly passes or two-hour fares regularly cross boundaries to other systems. Even with some sort of fare integration (a rat’s nest of policy and funding problems in its own right), there will be challenges if the tariff involves zones or some distance-based charge. There must be a reasonableness check built into the system to detect travel patterns that don’t make sense for a rider. Even so, things will go wrong.
The second problem is that Presto needs to acknowledge that these problems do occur and clean up its Customer Service practices. Only after this incident became a media issue did Presto actually do something, three months after it occurred. Indeed, their original advice to the riders was that they should contact MiWay to get a refund even though (a) they were on a TTC bus and (b) the fare system is Presto’s, not MiWay’s. Evading responsibility should not be the first response to a customer complaint.
Transit has a hard enough time fighting for riders. It should not be hobbled by systems and procedures that work against good service.
I see an overreliance on GPS here. At a minimum, each tap should record, and show on the account statement, both the road number of the vehicle and its route and trip number (which implies that which transit authority is involved would also be recorded). Then billing should be on the basis of starting a trip on that route at that time, with the GPS used only to determine where on the route the vehicle is.
Furthermore, on a typical bus route, the set of possible locations now, given the location of the bus over the last few minutes, is very tightly constrained. I’m not sure exactly how this part should work, but in effect the GPS location should not be used “raw” but rather as an update on the vehicle’s progress along the route.
I’m assuming of course that the computer knows about all diversions, but in the modern context it is insane to run a transit service on any other basis.
For rail vehicles (with the possible exception of streetcars), I’m not sure it makes sense to use GPS at all. Given that the vehicles are absolutely constrained to stay on the tracks, which are full of equipment and sensors, why not just rely on sensors that are part of the signalling system to track the location? Does GPS even work in tunnels? I can’t imagine that GPS is considered reliable enough to decide whether or not an automatic emergency brake application is required.
Steve: In the subway, the turnstiles handle fares, not the trains, and the turnstiles don’t move. Also, where streetcars are in tunnels, they are in paid areas and so riders are not tapping at these locations.
As always, an excellent post from Steve. It has resonance with other ‘oddities’ with Presto, the Metrolinx Bylaws, and just a plain lack of rationale.
Let’s flip that over for the sake of logical examination. Is it possible/probable that the TTC, at least in part, realized that the chances of so many glitches happening could be addressed by applying a simple parameter to a system prone to glitching, but the ‘fix’ sold to the public in gift wrapping rather than bandages? It could well be, albeit kudos to the TTC for doing what everyone feels has been a huge plus.
Steve: No. TTC staff had planned on the two-hour fare years before it was implemented, but this was put on hold thanks to a concern about lost revenue. Then John Tory got to announce it as a major improvement when he needed something to look good about on the transit policy front. All of the mess with transfer point tables could have been avoided from day one.
TorStar’s Ben Spurr writes today on the UPX fare evasion fiasco:
Finally the ‘wide open’ Metrolinx Bylaw, as it relates to UPX, is a media story. I don’t have a link for the bylaw handy, but wrote about it in another forum roughly a year back, after discovering that by that bylaw’s wording, GO fare policy (and UPX was still merged into that at the time) stated (gist)
Legally this means that travel into and out of the northwest area of Toronto, say via Brampton, and through Pearson Airport and using UPX, must be honoured as the same fare as the alternatives, which in my case of travelling to/from Guelph would take me either via Union Station and north on UPX (at the time it was under the GO fare regime) or via York Mills station, and then the TTC to get to Bloor station.
Obviously the options were absurd. I often mused as to ‘testing’ the law on the matter, but since I was always travelling with a rare and classic bike that could be a casualty if hassled, I never did test it. The bike is my prime form of transportation half of the year.
So again, as with the TTC’s ‘two hour transfer’…one wonders if the hiving of UPX back out of the GO fare regime is as much about covering a gaping hole in the law, and Presto geo-location challenges and the lack of integral logic to correct the absurdities the paying public is skewered with?
Spurr’s article is a ‘must-read’. Kafka’s characters appear many times in the guise of Anne Marie Aikins and attendant Metrolinx minions.
I posit that by default, the existing Metrolinx GO fare schedule *does* (or did) apply to UPX at the time the GO fare was honoured. I only wish I’d had the chance to test it.
Btw: Metrolinx: Those not paying their ‘fare-share’ on UPX technically aren’t ‘cheats’. The problem is with Metrolinx, not those acting legally. I question many of Aikens’ claims on the matter.
I mentioned the GO fare conditions of tariff in a prior post.
Here is the clause to which I referred [By-Law 2A]:
That clause, *as the fare structure stood until UPX was removed again from honouring GO ticketing* was (and possibly still is) a trainload of trepidation for Metrolinx.
I invite readers to pore over the above appendix as well as By-Law 2.
You don’t have to be a lawyer to find a number of serious glitches.
When did the TTC get a fleet of TARDIS (or is it TARDISES?)? The chameleon circuits that make them look like buses are working fine. Now if they could fix the time circuits?
Steve: Would you really want to trust your travel through time and space to the folks at TTC who cook up statistics to prove how good their service is when we all know better? There would always be problems that your TARDIS was never there when you needed it, two or three would materialize at once, and none of them might actually go where and when you wanted them to.
LikeLiked by 1 person
GPS error notwithstanding, I’m struggling how Presto can assess a MiWay fare when tapped on a device on a TTC vehicle. Surely there should be a filter to detect device owner.
I’ve also noted Presto location errors when tapping subway station fare gates which are not subject to GPS positioning.
For example, College Station is notorious for reporting it is someplace else.
There is something rotten in the Presto code.
Of course, I’ve never experienced a GPS or location error when travelling on GO rail or surface vehicles.
Steve: The College Station problem sounds like a unit got changed out from another station and was not reprogrammed.
Ah, that’s a new twist. I’ve been wondering if we’ll start seeing errors caused by erroneous identification of riding downtown express buses.
I suspect this will mostly plague people who ride the few routes that leave Toronto. Much (20%?) of the time, I see, especially on buses, Presto mis-identifying the boarding station, often showing the terminus, or the garage.
How do riders who only ride in Mississauga or York Region on TTC do things? Do they both tap on and off? I’m not quite sure how they’ve implemented it, as I only ever seem to use MiWay or YRT when I travel that way.
Thanks for the post Steve. I haven’t had experiences where I get charged extra, but I have had many occasions where the initial payment doesn’t show up in the Presto card usage history and only the transfer shows up. For example if I go from Queen Station to College Station then onto the 506, only the transfer onto the 506 will show up. Not sure if others have had similar experiences.
My main question here is regarding the GPS tracking. Are the Presto machines associated with the vehicle itself and the GPS tracking regarding the vehicle or do they contain their own GPS units? Furthermore, depending on the answer to that question, does Presto depend on NextBus tracking and who actually foots the bill for the facilitation and maintenance of the GPS system (Metrolinx or the TTC)?
Steve: Presto uses the GPS information supplied by the vehicle, as does NextBus. The GPS is part of the old CIS tracking system on streetcars and of the new Vision system on buses.
It boggles the sensors (apologies to ‘senses’) doesn’t it?
Is the next headline going to be ‘Mississauga stealing Toronto’s Metrolinx moola’?
Steve: The bus is a TTC bus running in Mississauga territory. The problem is that the bus was not really there when the riders tapped while transferring at Lawrence West Station.
I would think the problem lies more with the Presto unit than simply with the TTC GPS unit.
The chances a bus is incorrectly tracking at a location is very low. I usually check when the next bus is arriving and wouldn’t see the bus fly all over the map. Afterwards, sometimes the location where I tapped turns out to be “0” (meaning no data) or at the bus garage.
I would think the problem lies within the presto reader. The GPS unit could be function but the presto reader which freezes all the time is having trouble updating itself with the current location while continuously accepting fare. Since these readers freezes all the time, semi-freezing could be a very likely issue.
I regularly use the 52 and never seen this issue. I believe this issue only affects the 52B and 52D trips that travel outside the 416 border which I rarely take. The presto units are updated with specific branch. Riders of the 52F and 52G branches wouldn’t be affected. The 52A are sometimes interlined with 52B so there’s a possibility of getting mischarged. I assume the same with go for routes with branches going into York Region.
I don’t think the problem could be solved if the operator cannot control which fare to charge. Clearly the presto software could be written better for the customer by not charging when the location haven’t update itself in a long time. A bus have to move to offer transit services after all but who knows if that’s possible. These presto readers are junk.
It happens constantly with my TTC tap-ons, It’s infuriating, as if reading the fares charged itinerary isn’t difficult enough as it is. You now have to use a ‘memory cache’ of your own just to figure out where your money went.
If this were federally regulated, as per The Office of the Superintendent of Financial Institutions, this would be shut-down immediately. Could you imagine your bank or credit card company trying to use this type of an accounting ledger?
But Presto is the ‘clearing house’ in effect for collected fares. If that charge is assigned to Miway, then they get credited with it, not the TTC, as well as the passenger(s) also getting dinged.
Steve: But TTC service outside the 416 is a contract operation for the local municipalities. Presto charges a Miway fare as explained on the TTC’s website:
This would be a perfectly legitimate charge if the tap actually took place where Presto thought it did.
Even in the subway turnstile it’s not perfect. I was overcharged once, as a tap registered as 6xxAM rather than 6xxPM. If it correctly recognized the PM, I would have been within a two transfer. Though I was reimbursed within one week, this shows it’s not just the GPS units.
Presto is the best thing that has happened to the TTC. Before Presto, the TTC was still using a fare collection system from the stone age but Presto brings it to the 21st century. You are most welcome.
Steve: No, Presto is still working on stone tablets compared to the capabilities of truly up to date fare payment systems. The whole idea of having no back-end central accounting system, and of putting all responsibility for fare calculation on the card-to-reader interface, dates back to the early days of Presto and GO Transit when cell service in the outlying areas GO served was spotty at best. Metrolinx still has no concrete plans to move to a central accounting system, and the “Open Payment” scheme now in the planning stage will only support full adult fares with none of the concessions or loyalty programs. Those will still require proprietary Presto cards or apps. The problem of one-day delays on loads actually getting to a card will remain.
This functionality – full acceptance of any card with NFC capability and central account management – was part of the 2012 specification agreed to by Presto (among many functions that have not been delivered seven years later), and it is increasingly obvious that Presto has no intention of delivering on what it contracted to do.
If you really work for Presto, you have a future in media relations spinning a story that fewer and fewer people will believe.
It should be noted (again, and as often as necessary) that Presto was originally designed for a time-based fare. When it was first rolled out with other GTHA agencies, most (if not all) of them already had a time-based fare of two hours. GO even uses a time-based component (of 2.5 hours) to determine if a trip was a new ride or an extension of a preceding trip.
Had the TTC already implemented the 2-hour transfer when the full Presto roll out came along, it would have cost the TTC nothing.
Instead, Metrolinx charged the TTC to implement its messy transfer point tables. Worse, when the TTC moved to 2-hour transfers, Metrolinx charged the TTC again to switch them to an implementation that had been available for years.
Steve: Metrolinx is good at charging for stuff that is already in their contract, and assuming that the client is politically powerless to object. Quite recently, Metrolinx simply held back TTC revenue to collect on a bill for services the TTC feels it should not have to pay for.
Metrolinx is an arrogant organization that is desperately in need of housecleaning and public accountability to someone other than the fools in the Premier’s and Minister’s offices.
If you are looking for some incompetence to blame, look no further than the employees at the Bombardier’s Thunder Bay plant which made third quality streetcars delivered years late the vast majority of which brand new streetcars having to be recalled. Finally, the incompetent Bombardier Thunder Bay plant is closing for good. Finally, stop blaming Presto and Metrolinx for everything.
Steve: If you really do work for Metrolinx, then you show how hopelessly out of touch that organization is. The problems with Presto predate the new streetcars, and existed on the old cars too. This is the last comment of yours I will publish. Get a new name (to add to the many you are probably already using here).
Now piss off.
So when the TTC bus is in Mississauga or York region, those municipalities are paying for the bus operation to the TTC (in effect chartering them), but then collecting the fare revenue as if it was their own bus?
Steve: It appears that the arrangement is different for Presto fares versus the “legacy” fares. There was a time when buses running outside of Toronto carried two fareboxes and payments went into the one appropriate to the location. With the shift to a single farebox, I suspect that things changed and the revenue stayed in the TTC’s hands with an estimate of the credit due to the outside system. Now that Presto can distinguish where a fare is paid, it can allocate the money directly.
That was my point on misallocating the fare to Miway instead of the TTC, although it might be a case of both systems charging, one of them obviously being a phantom.
Someone somewhere is getting monies not owed to them, and this might be more common than Metrolinx will ever admit.
As pointed out by a number of posters, it appears unwise to to allow an automatic top-up from your bank account, as it lends itself to overcharging being missed.
I’ve long ago learned to check my card account online every few days.
Re ‘Presto does not have any means to issue receipts’:
On Brampton Transit buses Presto is used by most people and the 2 hour transfer is carried on the card. Where the original fare is cash, all the buses have a Presto transfer printer that issues a two hour paper transfer. The TTC did not go for this option.
Steve: The problem on the TTC is that the paper transfer cannot be read by a fare gate. TTC wants buses to be able to issue Presto tickets for cash fares.
There is a related problem with fare machines on streetcars that issue tickets that fare gates cannot handle, but at least there is a machine in place that could be converted to spit out a Presto ticket rather than the paper receipts they now print.
Re Stephen Saines: ‘Initial payment does not show up’:
I had that problem where a fare was deducted on a MiWay bus but did not show up on the Presto report. A second fare was charged for a subsequent transfer and it did show up on the report. I had my Presto card read and the MiWay tap was on the card with a date in 2006 sandwiched between a TTC tap and a Brampton Transit tap in 2018. It was not included in the report because it was more than 3 months old. It also violated the 2 hour transfer window.
If one is unable to do mental caching of figures, trying to read the ledger is nigh impossible.
Is there anyone reading this who’d dare to provide a charge sheet to a customer in this manner? It’s like submitting hours to determine the final bill, but minus the daily stamp in and out, and just the times taken for breaks. The presumption is the customer has to figure out the rest.
I’m aging, and not as sharp as I used to be, and at times it’s an impossible chore trying to figure out whether I’ve been overcharged or not. Have had to try again the next day, and the day after that only to find that the reason it didn’t make sense is…you guessed it…there’s been a glitch.
To be very honest, even though I have every right to make an issue of it, and spend half an hour dicking around on the phone, I’d just as soon cheat back what is owed.
For an ‘honour system” to work, it requires honour. And that has to be mutual.
Kafka walks amongst us…
Steve: Last year, I was tracking my use on Presto to figure out my “trip count” by the new two-hour transfer rules versus the old rules. I use a monthly pass, and so what I was really doing was verifying whether it still made sense to buy one. Among the things I noticed were that many stops only have numbers instead of location names. These were mainly the relocated King car stops downtown, and two years later, Presto still hasn’t updated their tables to map these correctly. Another problem was that taps in subway stations showed up days after they occurred, whereas surface vehicle taps were in my log right away. It turns out this is due to the architecture of the Presto network in the subway which does not immediately forward transactions to the central system.
In both cases, a less adept rider might be baffled about their travel logs on Presto, and especially would not have all the info needed to detect and contest an erroneous charge until a few days after the fact.
Starting in Dec the TTC Woodbine station centre turnstyle Prestocard machine has a timestamp that is more than 2 hours early. I had trips both started after 6 am but the presto timestamp says on Dec. 4 4:08 am & Dec.3 4:39 am. This time discrepancy resulted in an extra fare being charged when my trips included transfers outside of a TTC station. After tweeting TTC helps I will be reimbursed by Presto but wonder when/if the Presto fare machine will be fixed? How many other machines malfunction in this way? How many other people have been overcharged since this malfunction started in December?