Metrolinx: Presto Fare Card

[steveintoronto]

Billing by backend (rather than the card reader) makes this issue pretty trivial. Both transit control and the bus operator know they're short turning. Someone needs to tell the billing system that bus 123 with readers A/B/C has short-turned. Since the line manager sends the order, the line manager is ultimately responsible for this. The backend biller would adjust the price of the continuation tap on the new route.

Or do what many other progressive transit systems do now and have done for years (this is the norm in the SW US)
You buy *time* on the system. Doesn't matter if you do get on and off that same route for two hours, or which direction. You bought *time*.

It will save a whole lot of grief when the system inevitably glitches or gets gamed doing it any other way.

 

[Napoleon]

Or do what many other progressive transit systems do now and have done for years (this is the norm in the SW US)
You buy *time* on the system. Doesn't matter if you do get on and off that same route for two hours, or which direction. You bought *time*.

It will save a whole lot of grief when the system inevitably glitches or gets gamed doing it any other way.

Yep: fare by time or fare by distance. That eliminates many, many complexities.

 

[nfitz]

Fare by time is easy. Fare by distance creates massive complexities on the TTC bus and streetcar network.

 

[steveintoronto]

Yep: fare by time or fare by distance. That eliminates many, many complexities.

And it makes the trip *so much more relaxed*. Just like a pass, except it lasts only two hours. Get on or off wherever you want. In a number of jurisdictions I was in in SoCal, you could also 'refresh' your transfer by paying a small sum (perhaps a quarter of the fare) when it expired. The thinking is that is *keeps* people using transit, and it does.

 

[rbt]

Yep: fare by time ... That eliminates many, many complexities.

While true, that's not what the contractor agreed to and if TTC is forced to accept that solution, penalties should be applied against the contractor.

In fact, taking politics out of it, not hitting current fare rules seems like a pretty substantial breach of contract (I think courts would agree) and the contractor would most likely be required to pay for a 3rd party to implement it in the contract specified way.

In short, if Metrolinx can't make the contract work, TTC should be getting compensation year after year after year for the change.

 

[steveintoronto]

While true, that's not what the contractor agreed to and if TTC is forced to accept that solution, penalties should be applied against the contractor.

I think the point was missed. TTC, whether using Presto or not, would have *far fewer problems* by time basing the fare. Already drivers are instructed to not challenge fare evaders. So why not go with the flow? Make it *conducive* to use transit, rather than erect barriers? That it would streamline things with Presto is just the cherry on the ticket.

 

[nfitz]

In short, if Metrolinx can't make the contract work, TTC should be getting compensation year after year after year for the change.

Yes, I hope someone at TTC is astute enough to play this game.

 

[Catenary]

Kind of bizarre to schedule the feature rollout after the device installation. IMO, the TTC has two choices until they get this working:

• Accept the payment from the Presto card whether right or wrong and be done with it.
• Turn off the readers and notify everyone that Presto will no longer be accepted at all on express routes.

The TTC is replacing the existing onboard CAD/AVL system with one from Clever Devices, the same vendor OC Transpo uses that integrates the PRESTO functions into the driver's screen. It makes sense to wait until this system is installed to integrate it, rather than try and hack the readers into the existing CAD/AVL system that will be replaced soon.

 

[Steve X]

The TTC is replacing the existing onboard CAD/AVL system with one from Clever Devices, the same vendor OC Transpo uses that integrates the PRESTO functions into the driver's screen. It makes sense to wait until this system is installed to integrate it, rather than try and hack the readers into the existing CAD/AVL system that will be replaced soon.

That's not even possible. That thing is ancient.

 

[W. K. Lis]

That's not even possible. That thing is ancient.

Maybe not this ancient!

 

[TransitBart]

And the TTC Presto circus continues: https://twitter.com/caraaahoustyx/status/739927501858689024 "@bradTTC this morning many riders were asked to put in an additional token on 145 when using a presto ...?"

This individual included a screenshot of my own tweet to TTCHelps on June 1 asking if tapping Presto on a bus, including an express route despite it not deducting an extra fare, is valid fare payment, and they replied yes, i.e. you don't have to deposit a token when paying with Presto. Brad Ross has also replied to this individual that he agrees, i.e. the bus driver asking for a token when Presto has been tapped is wrong. But yet, another TTC driver going against the rules, and there's really nothing passengers can do except pay the extra fare or not ride the bus...of course it's against TTC policy now for drivers to challenge passengers on fare in any case, not just with this.

It's ridiculous to deploy Presto on a bus, put a Presto placard on the window, have a passenger board and tap their card, then tell them they need to deposit a token or cash fare too. And it's ridiculous for drivers to be permitted, time and time again, to violate policy and go against management decisions...but every time it happens, the TTC "will investigate what happened, and discuss the situation with the driver as needed - thank you for bringing this matter to our attention". Sigh...

Why can't an Express route be programmed to take two fares from a tap?

 

[rbt]

Why can't an Express route be programmed to take two fares from a tap?

It definitely can. The issue is the Presto machine can't be told it's on an express route at the moment.

 

[Steve X]

Why can't an Express route be programmed to take two fares from a tap?

Everything is guess work right now. The machine is automated and guesses what direction and what route it's on based on GPS location. It's only programmed to either deduct regular fare or accept a transfer. The driver has no idea if you paid or transferred. It makes short stop overs possible. You can't control to pay another fare either (for the honest folk that doesn't want to violate the transfer rule).

 

[nfitz]

It's guessing what route it's from the from GPS? That explains some of the bizarre transfer fails I've seen - they are a combination of the GPS not knowing where it is, the vehicle turning into service just before it gets to you, or being on a detour.

It will be interesting to see how (if) they clean this up for the elimination of paper transfers.

 

[Napoleon]

Everything is guess work right now. The machine is automated and guesses what direction and what route it's on based on GPS location. It's only programmed to either deduct regular fare or accept a transfer. The driver has no idea if you paid or transferred. It makes short stop overs possible. You can't control to pay another fare either (for the honest folk that doesn't want to violate the transfer rule).

Is that really how it works? I can't believe that's the best they could do. I presume the system that does the automated stop announcements knows what route it is...that must talk to the Presto system one would hope.