|
|
|
I agree 100%, those are really great points!
Aaron Paquette says that administration looked into those, but the increase in fare recovery they'd bring wouldn't displace the costs involved. It just goes to show that, like you said, it's better to improve service delivery than trying to squeeze every penny out of riders.
Curious why you say thankfully?
Vancouver thought the same before they got them and realized fare evasion was a lot worse than expected
Partly this:
The cap thing is definitely a bug, and the first one probably is as well; please make sure you report them on the online platform they gave pilot participants! Regarding caps: Other participants I heard from have tried transferring between systems, and their caps have been applied correctly - applying only to the local/commuter systems that they tapped for.
There was an issue with some scanners where when the doors opened, they'd remain on the "Door closed, do not scan" screen. I think this is their workaround, because it's more important to make tapping convenient than it is to stop the odd person from tapping off early (IE to avoid a commuter fare).
Fantastic. All that's left now is to cut down on the 1-2 second delay when you tap.
I know one area that makes it more complicated is the regional aspect of this. There's seven participating municipalities I believe, and each one has their own local + commuter fare structures. So the system needs to be able to dynamically calculate a lot of different fares for you if you're travelling throughout the region, and my friend who works as a transit planner in the region says it's really complicated under the hood. I don't know whether it's contributing to the problems they're facing though.
The software side can be tricky, but wholly solvable since they aren't integrating with existing legacy payment systems. They are building from scratch.
Agreed, it's a big shame. They partly fixed it by keeping the scanners on even when the buses are moving, so there's no delay to board/alight while waiting for the machine to register the doors opening. But that delay between scans is a pain. I wonder how they can find a balance between letting people know that their scans worked (and if they did not work, why they didn't) while quickly letting the next person scan as well. It could be a time delay they manually set? If so, perhaps they can keep the delay, but allow it to be overridden by the next person who scans. That could allow things to happen organically, where someone has the message if they need it, but if the next person scans, that probably means the first person's scan went through and they moved on from the scanner.
