Metrolinx: Presto Fare Card

[amnesiajune]

The TTC's transfer policy can only be automated with mandatory tap on and tap offs at every vehicle/station.

The TTC is extremely opposed to any sort of tap-off for local bus and streetcar service - probably much more so than they are to formally or informally loosening the transfer policy. So is Metrolinx for that matter (note the use of "local", as opposed to regional GO bus service where stops are infrequent and not as heavily used).

 

[ssiguy2]

It definitely looks like Metrolinx want a distance based fare system and as long as it applies to every mode available including RER and GO commuter, then I think it is the fairest way to go and with Presto, it is very doable.

The thing that I don't get is what would happen {and it will happen all the time} is what if you forget to tap out or in a rush to get off the bus your "tap" doesn't go thru, the bus' Presto system has a glitch or breaks down, or the entire system has a glitch.........how much does the user get charged on the Presto card?

 

[Megaton327]

I don't believe this is true.

This was published as a future policy in a commission report for post-Presto implementation at the same time you start tapping out of stations.

But I've never seen indication it's been implemented.

Brad Ross has tweeted it many, many times to many different people asking, and I think that Heather MacMillan Brown and TTCHelps have also said it. Of course, that doesn't make it a ticketable offense in and of itself if you don't do it--like you and another user said, there is absolutely zero indication to the average rider that they should do this. However, in the specific case I was replying to, riding all the way from a Lawrence East bus without tapping, you'd be expected to tap, at the very latest, when boarding the 509 in the fare paid zone at Union.

 

[crs1026]

Does anyone know how much data busses need to transfer over every night? Is it in the 100s of GBs or less? I wonder what kind of data connection it would take to update live.

Well, for the upbound data - suppose the typical bus boards 100 customers per hour. That's 1800 customers per day, assuming it's not an all-night bus. An individual transaction would be perhaps 100 bytes: Bus ID, Card ID, location, time, route, purse balance, plus overhead data, check sums, etc. So the bus transmits maybe 2-3 MB per day.

Receiving data - suppose the entire load of all valid Presto cards is downloaded nightly. Ten million customers at the same 100 bytes per customer. Plus a transfer table of maybe 10,000 data points. So 1GB per bus.

If my speculative numbers are sketchy, double them, or even multiply by ten. It's a very small amount of data per bus.

- Paul

 

[TheTigerMaster]

PRESTO at its best! (From TTC page listing all bus routes)

PRESTO card customers require a paper transfer on the following routes. Transfers must be shown to station staff when entering Union or Royal York stations and to operators when boarding these buses. Please make sure you obtain a paper transfer at the start of your trip.

• 15 Evans
• 121 Fort York
• 72 Pape

• 48 Rathburn
• 73 Royal York
• 76 Royal York South

Clearly PRESTO cannot deal with the TTCs crazy transfer rules. There is a simple solution - timed transfers!

With all these various rules and exceptions to rules on Presto, the TTC oughta send all Presto users a quarterly 15-page instruction manual on how to use the system.

Does the TTC seriously expect people to remember that on the 15, 121, 72, 48, 73 and 76 in particular, you can't use Presto for transfers. This is getting quite a bit ridiculous...

 

[W. K. Lis]

With all these various rules and exceptions to rules on Presto, the TTC oughta send all Presto users a quarterly 15-page instruction manual on how to use the system.

Does the TTC seriously expect people to remember that on the 15, 121, 72, 48, 73 and 76 in particular, you can't use Presto for transfers. This is getting quite a bit ridiculous...

Maybe a direct line to one of those lawyers they advertise on the side of the buses and streetcars.

 

[nfitz]

The 72B and 121 have been operating with a connection to Union Station for over a year. There's no excuse.

Neither route has been running to Union for a year yet!

 

[nfitz]

The TTC's problem is that they have a transfer policy that can't be automated. It can only be enforced by a human's judgement.

That's not really TTC's problem though; it's Metrolinx's.

Metrolinx signed a contract saying they could implement it under the current pricing. TTC has placed a value of $20 million/year on a policy change to avoid doing it.

It's win-win for TTC.

Ultimately they should be able to deal with all the regular issues. It's diversions etc. that are the issue.

However the vehicles all have GPS. I'm not sure you could do this in realtime, But you should be able to run a batch every few hours and identify all the offroute runs. Then to identify passengers that could have been on. Then check to see if they tapped near the detour route and reverse any extra charges.

That kind of process, which is entirely backoffice, doesn't even sound that difficult to program. With the only real issue being volume. Obviously you need some processes to deal with GPS errors, etc.

Honestly though, I consistently see more free trips for transfers that were really new trips than extra charges.

 

[amnesiajune]

Metrolinx signed a contract saying they could implement it under the current pricing.

I'd like to see the specifics of that contract, because in all likelihood Presto is only required to support this no-false-negatives implementation of the transfer policy. Without a tap-off requirement, which the TTC strongly opposes, you can not create any system that would distinguish "valid" trips that got a bit delayed from stopovers that are invalid transfers.

The GPS implementation you talk about can't work under Presto because everyone would be charged for multiple trips - potentially being locked out of their transfer because of a negative balance - on transfers that are invalid. Or alternatively, people could go farther into a negative balance than Presto allows when the system figures out that a transfer is invalid.

Anyways, the TTC's transfer policy is really, really dumb. Let's at least agree on that.

 

[johntauren]

Neither route has been running to Union for a year yet!

Well, the 72 did used to run to Union, and then was split into two routes (72/172) during years of construction at Union, and only recently restored.

The 121 is just coming up on one year, being implemented during the bus roll-out of Presto readers. They could have at least considered it's weird implementation.

 

[nfitz]

Brad Ross has tweeted it many, many times to many different people asking, and I think that Heather MacMillan Brown and TTCHelps have also said it.

I don't think they have. Always possible in error. Can you point to a few examples?

I had one like this the other day, when tapped on at Broadview station, took 504, and charged on 506 - and they said that was an error and phone for refund. Not should have tapped on streetcar after already tapping on entrance.

 

[nfitz]

I'd like to see the specifics of that contract, because in all likelihood Presto is only required to support this no-false-negatives implementation of the transfer policy. Without a tap-off requirement, which the TTC strongly opposes, you can not create any system that would distinguish "valid" trips that got a bit delayed from stopovers that are invalid transfers.

Look at it then. We've linked to it and talked about it enough times, surely.

Edit - I had a chance to pull it. It's the November 28, 2012 Master E-Far Collection Outsourcing Agreement between TTC and Metrolinx and can be found at www.metrolinx.com/en/projectsandprograms/presto/Executed_PRESTO-TTC_-_Master_Agreement.pdf - beware it's 5 MB and 650 pages.

A careful read does make it clear that Metrolinx is very weak on legal abilities - once again evidenced in their disastrous legal issues with Bombardier.

The GPS implementation you talk about can't work under Presto because everyone would be charged for multiple trips - potentially being locked out of their transfer because of a negative balance - on transfers that are invalid. Or alternatively, people could go farther into a negative balance than Presto allows when the system figures out that a transfer is invalid.

So occasionally there is an extra charge that is reversed. How is this worse than for some people GO charges double their fare, then refunds up to half of it when they tap out. Heck, for those doing the free quick returns, they get a $5.30 refund. That's more than $3.00. I've never heard a complaint about frozen cards, etc. I think you are looking for unlikely problems.

Anyways, the TTC's transfer policy is really, really dumb. Let's at least agree on that.

Sure it is. I've said so for years. That's not the point though. The point though that TTC got Metrolinx to sign a contract saying it would be implemented. If they can't, they can sure for $20 million a year. That's about $160 million or so for the rest of the contract.

 

[nfitz]

Well, the 72 did used to run to Union, and then was split into two routes (72/172) during years of construction at Union, and only recently restored.

Oh, it's changed several times over the years. Also, before the recent recreation of 172 in 2014, the 72 route was changed from Union to Wellington/King serving King station in 2012. This was well before Presto was added to buses. And of course 172 also ran from 2004 to 2008.

The 121 is just coming up on one year, being implemented during the bus roll-out of Presto readers. They could have at least considered it's weird implementation.

No doubt it's a mistake. Not sure why they didn't notice earlier.

 

[DSC]

Oh, it's changed several times over the years. Also, before the recent recreation of 172 in 2014, the 72 route was changed from Union to Wellington/King serving King station in 2012. This was well before Presto was added to buses. And of course 172 also ran from 2004 to 2008.

No doubt it's a mistake. Not sure why they didn't notice earlier.

Possibly and even understandably. What is not understandable is why they did not immediately get the PRESTO programming fixed and had to tell PRESTO users to get paper transfers. This leads me to think that re-programing this kind of simple small change into PRESTO is not easy and makes me ask, again, whether it wouldn't be cheaper to go for timed tickets. I think it is generally agreed that timed tickets would be easier to understand and offer better customer service.

 

[EastYorkTTCFan]

Does anyone know how much data busses need to transfer over every night? Is it in the 100s of GBs or less? I wonder what kind of data connection it would take to update live.

As far as I know the TTC does not offload all of the Data from buse and streetcars at night as many of them don't go back to the yard every night. All surface vehicles have cell phone antennas and I believe they can also connect to the internet in sations as well. If you check your Presto card after tapping onto a bus or streetcar it apers much sooner then taping on a fare gate or even a go transit reader.