Another Sign that the TTC Presto System is Broken

[jsburbidge]

For the next few months, the Wellesley buses which normally have a connection inside the Wellesley subway station are stopping on the street, due to construction in the station.

They have notices that Presto card users need to transfer using a paper transfer - supposed to be rendered obsolete by Presto - to avoid being charged twice (i. e. a tap on to the bus will be counted as a new trip rather than a continuation of a trip).

This in turn indicates that their system is inflexible and probably unmaintainable.

Comments

[graydon]

I'm pretty sure someone who is better at graph theory than I am could prove that you cannot do what they claim to do without connecting the fare readers to some central node.

[jsburbidge]

The TTC has committed to moving to a two-hour time limit model for its use of Presto beginning in August. Although this is being positioned as a plus for customers (which it is) I suspect that it is really driven by somebody getting into their heads how unworkable and unmaintainable (and therefore how expensive) the full implementation of their transfer rules in software would be: in any unusual situation (breakdowns, bad weather, rerouting of routes, etc.) a great deal of traditional functionality relies on the informed judgement of the driver.

[graydon]

I wonder how they're going to handle the cases where the trip takes longer than two hours?

(surprisingly easy to do on Blue Light bus routes....)

Single-continuous-trip is hard on the drivers, so I hope you're right TTC policy has had a rush of sense to the head.

If a transit trip is a bunch of segments and nodes where you change vehicle (and we can model "transit system" through types of vehicles), I'm pretty sure you can't make pay-on-exit work for a multi-segment trip because there's no way to detect exit other than tapping. "I am continuing my trip" has to be a different physical sensor from "leaving now" and Presto hasn't got that and I am fairly sure can't have that; the mechanism they've got is pretty much strictly flipping a bit.

Some sort of NFC phone-app-or-fob would be a much better bet for really doing what Presto is supposed to do. But what Presto is supposed to do is really ambitious.

[dewline]

I worry about the consequences of OC Transpo signing up with Presto here in Ottawa.

[chickenfeet]

The problem isn't Presto, it's the TTC implementation of it. It works fine on GO, UPX and the suburban transit systems.

[graydon]

Nope.

If your GO bus has a mechanical and you have to switch, Presto cannot cope whatsoever. If your train has a mechanical, same.

Presto can handle figuring out which stop you get off at and doing zone billing on a single segment trip if nothing goes wrong. That's ALL Presto can do. Which is almost enough for the GO train service but hopeless with any kind of bus routing involving multi-segment trips.

[jsburbidge]

Yup.

GO is a problem because of the charge by zones model which requires tsp-off as well as tsp-on. The suburban services work, because they rely on a simple timed validity model. (Not sure about the fact that YRT has two zones, because I've never travelled between them.)

[chickenfeet]

No idea about what happens with a breakdown though I can't imagine why it would matter with a train as the readers are at the station not on the train. But, Presto copes all the time with multi-segment, multi modal trips. It even copes with, for example, a trip involving two different transit authorities so if one takes a GO train then an Oakville bus it calculates the lower combined fare regardless of which comes first. I have been using it for three years and have not had a single problem other than TTC buses showing up with no reader or the reader not working.

[graydon]

Breakdowns matter with trains at, for example, Union Station; you have to tap out and tap back in because of where the dead train unloads and the live train loads being different sets of tracks. Presto can't cope with this at all, and its default for not coping is to assume rider fraud and charge two maximum fares. (This has happened to me, recently. This is not a hypothesis.)

Presto SAYS it copes with multi-segment, multi-modal trips. It doesn't; what it does is have you pay a fare to the TTC, then a fare to GO, and so on. You couldn't support a multi-carrier single fare trip with Presto.

All Presto has for state is "on" and "off" and the ID of your card and the id of the readers. It hasn't got any notion of "participating in a route" or "headed in the general direction of thus-and-such destination". It's got a line, not a graph.

Until it gets a lot more state and a signalling mechanism, it CANNOT have a graph, too, which is a big problem because busses will break down and Presto's response to being confused is to charge you two maximum fares. (This is policy; this has happened to me recently.)

It looks for all the world like the point was to assign some transit revenue to a political client and never mind if it worked. (So far as I can tell, Region of Waterloo is getting zero help with Bombardier because they had the effrontery to issue an RFP (to which Presto didn't submit) rather than dictate Presto use. Presto really doesn't want to have to deal with anybody technically ept.)

I think the whole snarl greatly confuses the issue around "why are we charging transit fares at all?"