News   Jul 15, 2024
 282     0 
News   Jul 15, 2024
 430     0 
News   Jul 12, 2024
 1.9K     1 

Metrolinx: Presto Fare Card

Subway-to-surface: Always

Subway-to-subway: Never

Surface-to-surface: Always

Surface-to-surface-to-surface: Never

Surface-to-subway: Only at valid transfer points.
I've done surface-to-surface-to-surface a bunch of times and it's always recorded as transfers. Pretty easy way to do a return trip on one fare if you have the right connections.
 
I've done surface-to-surface-to-surface a bunch of times and it's always recorded as transfers. Pretty easy way to do a return trip on one fare if you have the right connections.
I have too, sometimes there's no choice in the matter. Other times I've done a transfer from the subway onto a streetcar, and got dinged. Usually things work they way they're supposed, but it's like getting short-changed at your local supermarket, even if only occasionally, it's infuriating. If you knew you were going to have to pay twice, you would have walked or passed on it from the get go.
 
My sixth sense tingles. Check your Pesto transaction on-line if you've done that, and please post what you find.

Just re-reading what you posted:

"Passes"...not Presto Cards?

OK. Maybe I will take one of the team for only $2.90 :)

Yes passes. As in Metropasses.

To board the bus they would just show their passes to the bus driver, exit, and swipe their passes on the revolving doors turnstiles.
With the new fare gates they can do the same except the gates are different.
 
Maybe a bit off topic here, but feel free to repost this in a more apt string if there's one:
Transport for London (TfL) has announced a pilot program which will track commuters' travel routes through free Wi-Fi services.

The trial, which lasts four weeks from Monday, "will help give TfL a more accurate understanding of how people move through stations, interchange between services and how crowding develops," according to the transport agency.

As noted by The Telegraph, the pilot program's operators hope the data gleaned from commuter devices will create a repository of valuable data on how modern commuters use the transport network -- which often suffers under the burden of crowding, especially in peak times.

At present, TfL is only able to track commuter locations and times of use through the Oyster card program, which is limited to when people enter and exit the underground network. However, by using Wi-Fi requests, the agency may be able to determine the most-used routes and interchanges, where the advertising hotspots are, and determine where investment would be best placed.

When a commuter uses their smartphone or tablet to connect to free Wi-Fi, available at certain stations, Wi-Fi enabling automatically searches for available hotspots. The seeking device's Media Access Control (MAC) address will now automatically be detected by the tracking system, grabbed, and analyzed to determine commuter paths.

To placate travelers worried about their privacy, TfL says this data is "automatically de-personalised" and anonymized before being used for analysis and will not be shared or sold to third-parties. In addition, posters will inform commuters when they enter one of the 45 trial stations where tracking is active.


"This short trial will help us understand whether Wi-Fi connection data could help us plan and operate our transport network more effectively for customers," Shashi Verma, chief technology officer at TfL said. " Historically, if we wanted to know how people travelled we would have to rely on paper surveys and manual counting, which is expensive, time consuming and limited in detail and reliability."

"We hope the results of this trial will enable us to provide customers with even better information for journey planning and avoiding congestion," Verma added.

If you do not want to be tracked or to be part of the program, you simply need to turn off your device's Wi-Fi while on the move. The trial is due to last for four weeks, but if successful, could become a permanent fixture in London stations.
http://www.zdnet.com/article/transport-for-london-to-track-commuters-through-wi-fi/

Beyond privacy issues, (this tracking ability has been known for years, including the GPS co-ordinates) this ability bodes well for distance based fares, albeit the default would be having a tracking device, and failing that, paying full fare possible as is now done with 'failing to tap-off' with Presto.

This will be interesting to watch.

On the TTC transfers, other than the St Clair time-based ones, which are two hours, my understanding was 90 mins. Reality is such a morphic thing...if it has been raised to two hours, then my transfers have been going stale at 90 mins using the Presto transfer machine to check.

Edit to Add:
[If you do not want to be tracked or to be part of the program, you simply need to turn off your device's Wi-Fi while on the move.]

The more I think about that, something's odd. That may be a purposeful piece of disinformation.

However:
Smartphone location tracking via Wi-Fi signals, motion sensors for subway riders
Two different research papers show a 90% or above accuracy in tracking people's location via their phones' Wi-Fi connections or tracking subway riders via their phones' motion sensors.


Here are two research papers about tracking people via their smartphones that might momentarily make you want to toss your phone into a lake. Both show a 90% or above accuracy in tracking people via their phones' Wi-Fi connections or motion sensors.

Tracking you using Wi-Fi signals

Tracking Human Mobility using WiFi signals (pdf) makes the case for Wi-Fi scans to be considered "a highly sensitive type of data" that "should be considered location data."

Using just one GPS observation per day per person allows us to estimate the location of, and subsequently use, Wi-Fi access points to account for 80% of mobility across a population. These results reveal a great opportunity for using ubiquitous Wi-Fi routers for high-resolution outdoor positioning, but also significant privacy implications of such side-channel location tracking.

Researchers Piotr Sapiezynski, Arkadiusz Stopczynski, Radu Gatej and Sune Lehmann point out that "large companies such as Google, Apple, Microsoft, or Skyhook, combine Wi-Fi access points with GPS data to improve positioning, a practice known as 'wardriving'." The actual "how" is "proprietary to large companies." They added, "Predictability and stability of human mobility are also exploited by commercial applications such as intelligent assistants." They used Google Now as an example of an app "which learns users' habits to, among other services, conveniently provide directions to the next inferred location."

In the Android ecosystem, location permission is separate from the permission for "Wi-Fi connection information." Yet the researchers found that inferring location can be accomplished using only a small percentage of Wi-Fi access points (AP) seen by a device; it's one way an app can inexpensively convert the APs into users' locations. "The impact is amplified by the fact that apps may passively obtain results of scans routinely performed by Android system every 15-60 seconds. Such routine scans are even run when the user disables Wi-Fi."

Developers whose applications declare both location and Wi-Fi permissions are able to use Wi-Fi information to boost the temporal resolution of any collected location information. We have shown that even if the location permission is revoked by the user, or removed by the app developers, an initial collection of both GPS and Wi-Fi data is sufficient to continue high-resolution tracking of the user mobility for subsequent months. Many top applications in the Play Store request Wi-Fi connection information but not explicit location permission. Examples from the top charts include prominent apps with more than 100 million users each, such as Candy Crush Saga, Pandora, and Angry Birds, among others. We are not suggesting that these or other applications collect Wi-Fi data for location tracking. These apps, however, do have a de facto capability to track location, effectively circumventing Android permission model and general public understanding.

The researchers argue that data collection and handling practices need to change to include Wi-Fi data as location data. "A third party with access to records of Wi-Fi scans and no access to location data, can effectively determine the location of each individual 90% of time by sending less than 20 queries to commercial services such as Google Geolocation API or Skyhook."

Tracking you on the subway

If you dislike having your privacy "stolen," then the second paper will likely irk you as researchers show how they can secretly steal motion sensor readings in smartphones to track subway riders. That's not just theory; after conducting real-world experiments by tracking subway riders in Nanjing, China, researchers discovered that the tracking "accuracy can reach 92% if the user takes the metro for six stations."

We Can Track You If You Take the Metro: Tracking Metro Riders Using Accelerometers on Smartphones (pdf), the researchers wrote, "Our scheme does not rely on GPS or other positioning systems, which gives it a high level of concealment and considerable efficiency. It may disguise itself into normal smartphone software when it steals the information on the users' trace."

They proposed two attacks; the first had two phases. "In the training phases, the attacker collects motion sensor readings for each station interval and then uses a supervised learning scheme to build an interval classifier. In the recognition phase, the attacker analyzes the sensor readings collected by the malware from infected smartphones and then utilizes the interval classifier to identify the station intervals that users pass by."
[...]

http://www.networkworld.com/article...and-via-motion-sensors-for-subway-riders.html
 
Last edited:
On the TTC transfers, other than the St Clair time-based ones, which are two hours, my understanding was 90 mins. Reality is such a morphic thing...if it has been raised to two hours, then my transfers have been going stale at 90 mins using the Presto transfer machine to check.

Are you talking about the machines on the new streetcars? Those don't recognize transfers from other vehicles. You have to tap your card on the streetcar and then it'll print a transfer, even if your tap on the streetcar was a transfer itself.
 
Are you talking about the machines on the new streetcars? Those don't recognize transfers from other vehicles. You have to tap your card on the streetcar and then it'll print a transfer, even if your tap on the streetcar was a transfer itself.
I'm talking about tapping your Presto Card at the transfer issuing machine to see if there's still a window to print a transfer. The info on the screen tells you whether your time is still valid or not. After 90 mins of issuance, it is no longer valid.
 
The transfer window is definitely 120 minutes.
Can you provide a link/reference for this?

I have to retract my claim for "90 minutes"...as I've searched at length, and the TTC has now redacted any reference to *any* set length of time for transfers. (St Clair streetcar excepted) I've read two different types of recent transfer, and on-line. All that is stated is (and this streetcar transfer is sic) "Must be used at time of purchase within reasonable time allowance to the transfer point". Obviously the "at" is a dangling reference. It should be 'from'. But the key word is "reasonable". That both helps and hinders an operator, for whom it's left to be discretionary, not fixed.

However, I stand by my observation of the on-board transfer machine, even after asking an inspector before boarding. There was a diversion in that instance of the Spadina streetcar on Queen, and I'd failed to get a transfer when paying. Inspector stated (gist) "No problem, you can still get a transfer on-board with your Presto card if you paid that way". There's still a lot of disinformation afoot. So please reference your claim.
 
Can you provide a link/reference for this?

My own transit usage: (Second one was on a bus at the Yonge/Wilson stop)

H5qfnps.png

hQaHT2w.png
 
My own transit usage: (Second one was on a bus at the Yonge/Wilson stop)
That is one instance. That's not a reference. I've also had that experience. And I've had experiences where that didn't happen.

That's why I'm asking for a reference. From the TTC, in print. You rather miss the point by making it.

Edit to Add: It raises questioning the reason for the TTC to now remove any published or printed reference to a fixed time limit. Is it altruism on their part? (Highly unlikely, or they'd promote a two hour transfer), or is it to cover their sore arses from being dragged around on their transitory petard since they know there's large inconsistencies in what they've been stating and what is actual?
 
Last edited:
That's why I'm asking for a reference. From the TTC, in print. You rather miss the point by making it.
As you are well aware, TTC has not published a number for the current implementation. The current programming can only be deduced by looking at examples.

And it's clearly 120 minutes or greater, given the example shown, at that transfer location.
 
As you are well aware, TTC has not published a number for the current implementation. The current programming can only be deduced by looking at examples.
LOL! And others' examples state differently from Amnesia's experience.

What is it you don't understand about the need for printed, *reference*? Tell me, is this how you determine your income tax rate? The speed you drive?

You certainly both make a point, just not the one you intend. And you, Fitz, have a short memory it seems. You were the one talking about the "transfer rules" just a few months back, and how one shouldn't cheat the system by doing round trips with a transfer. You posted reference to the *printed rules*.

Oh how the wind changes when it blows out of crevices...
You also took me to task for believing "there's a two hour window" on a transfer. You claimed (gist) "that was then, it's ninety minutes now".

That is *exactly* why I wanted a printed reference.
 
LOL! And others' examples state differently from Amnesia's experience.
At that transfer location? I think not! Clearly the programmed implementation currently isn't just a simple time-limited transfer anywhere.

Presumably there is somewhere a maximum value - in addition to a myriad of other route-specific restrictions.

What is it you don't understand about the need for printed, *reference*?
What is it that you don't understand about "don't be rude"?
 

Back
Top