News   Jun 11, 2024
 686     0 
News   Jun 11, 2024
 529     0 
News   Jun 11, 2024
 939     0 

King Street (Streetcar Transit Priority)

A few weeks back I recall someone at Traffiz Services say that they were waiting to collect more reference data until they enable TSP. Has there been more news since then?

I'm guessing that Traffic Services was conveniently vague about what this "data" entails, so that no matter what data is collected they can always say they need more? There has been literally non-stop data collection for the past six weeks, which is well beyond the time required for things to settle down and then have a solid "before" data set to compare with the "after" dataset with TSP.
 
When you say 'opposing' do you mean the light for the streetcar? If so then you'd be requiring the streetcar to sit through whatever the minimum red duration is, which would far exceed the time spent at a typical stop.

According to the Toronto signal timing document @steveintoronto linked earlier, the minimum north-south phase along King Street would be roughly:
7s minimum walk
12s Flashing Don't Walk (14m @ 1.2m/s)
4s Amber
2s All-Red
__
= 25 seconds

Add in the 6 seconds of amber+all-red along King street and you're looking at a minimum of 31 seconds at a standstill before the light turns back to green. Based on my experience timing stops while riding the streetcar, a typical minor stop takes about 16 seconds, so this method would seriously increase the delays if applied there. However, at very major stops the dwell time can approach 30 seconds in which case it might be worth considering.

Also keep in mind that you can't just change the King Street light to red instantly, you need to wait for the Flashing Don't Walk first, which is pretty massive at some intersections. Depending on when the streetcar arrives during the cycle, there will be times when it is impossible to achieve your desired operation.

So while this strategy would probably be an improvement over the current setup at certain major near-side stops, it would still provide worse delays than priority optimized with a far-side stop.

I don't know the timings, but here is how it works.

Except for major intersections:
Lights are timed to match the movements of the streetcar such that the cross traffic lights are green and the streetcar lights are red when the streetcar approaches the stop. When the streetcar comes to the stop, the lights begin their change from green/walk, to red/don't walk. At this point, the streetcar should be loaded and ready to go. They can now move due to it being green for them.

Major intersections would need better timing to take in consideration the traffic patterns and the streetcar passenger load.
 
I don't know the timings, but here is how it works.

Except for major intersections:
Lights are timed to match the movements of the streetcar such that the cross traffic lights are green and the streetcar lights are red when the streetcar approaches the stop. When the streetcar comes to the stop, the lights begin their change from green/walk, to red/don't walk. At this point, the streetcar should be loaded and ready to go. They can now move due to it being green for them.

Major intersections would need better timing to take in consideration the traffic patterns and the streetcar passenger load.

Responded on Roads:Traffic Signals thread
 

Continued from King Pilot thread



A couple problems at minor intersections:
- You can't ensure the light is already red and resting in north-south green/walk when the streetcar approaches. Sometimes it will already be green for the streetcar.
- If the light is red when the streetcar approaches it may not be possible for the streetcar to reach the stop due to other cars in the way

At major intersections:
- How exactly do you propose to 'take into consideration' the traffic patterns and streetcar passenger load? Real-time sensors or a back-of-the-envelope calculation?

There is something called a computer. There is something called trending. There is something called PRESTO.

Combine these 3 together and you can get a pretty close approximation to the real world situation.

For example, the passengers at a stop at 5pm as apposed to 3am are not the same. They will never be the same. A computer can learn and work the signals accordingly. PRESTO is already tracking where you tap it. It knows how many people tap each stop and at what time.

This technology has been around for 10-20 years.
 
There is something called a computer. There is something called trending. There is something called PRESTO.

Combine these 3 together and you can get a pretty close approximation to the real world situation.

For example, the passengers at a stop at 5pm as apposed to 3am are not the same. They will never be the same. A computer can learn and work the signals accordingly. PRESTO is already tracking where you tap it. It knows how many people tap each stop and at what time.

This technology has been around for 10-20 years.

The city is starting to test different implementations of it. But it takes time to get right and it's wildly expensive.
 
The city is starting to test different implementations of it. But it takes time to get right and it's wildly expensive.

There are no cheap solutions to make this pilot work. Light signalling is the best money spent.

Hopefully they use what they learn on this to improve Habourfront, Spadina, and St. Clair. Hopefully when the EC comes online, this is put in place also. RT should be rapid, and waiting for lights to change is not helping them.
 
There is something called a computer. There is something called trending. There is something called PRESTO.

Combine these 3 together and you can get a pretty close approximation to the real world situation.

For example, the passengers at a stop at 5pm as apposed to 3am are not the same. They will never be the same. A computer can learn and work the signals accordingly. PRESTO is already tracking where you tap it. It knows how many people tap each stop and at what time.

This technology has been around for 10-20 years.

Yes, and for each stop this technology will spit out one number for the dwell time at each time of day, with a variation on either side of it. Each individual streetcar will vary from that number by a certain amount. Some will take less time than the estimate (therefore making the signals sub-optimal for them) while others will take more time than the estimate (therefore making the signals sub-optimal for them). Regardless of how good your estimate is, reducing the variability (i.e. avoiding having a stop immediately before the intersection) will allow you to achieve a much more optimal operation in the real world.
 
Yes, and this fabulous technology will spit out one number for each time of day, with a variation on either side of it. Each individual streetcar will vary from that number by a certain amount. Some will take less time than the estimate (therefore making the signals sub-optimal for them) while others will take more time than the estimate (therefore making the signals sub-optimal for them). Regardless of how good your estimate is, reducing the variability (i.e. avoiding having a stop immediately before the intersection) will allow you to achieve a much more optimal operation in the real world.

Then the light needs to always be green on the approach.
 
Then the light needs to always be green on the approach.

Okay so what happens when the light is green and about to change to red, you're 31 seconds away (including some assumed dwell time which may end up being completely wrong) and you're not allowed to extend the green by more than 30 seconds?
 
Okay so what happens when the light is green and about to change to red, you're 40 seconds away (including some assumed dwell time which may end up being completely wrong) and you're not allowed to extend the green by more than 30 seconds?

The light gets held.

The streetcar routes should be set up that they are streetcar routes first, and cars can travel, but have no priority. Once the mentality that the car is king has been deflated, real traffic changes can occur.
 
The light gets held.

Okay so now you've extended the light by 30 seconds at which point the light has to change to yellow because it can't say green forever, and the streetcar is still sitting at the near-side stop. Now your streetcar will need to sit through an extra 30 seconds of red compared to if the priority system hadn't done anything, because otherwise it would already have been 30 seconds into the next phase by now.

P.S. Just so you're aware, what's happening here is that you're describing exactly the way signals already work in downtown, and I'm describing the things that cause them to have less-than-stellar performance for streetcars, even though in theory streetcars should barely ever get red lights.
 
A slightly off-subject, but related comment: What was really frustrating to see was when the light was being held green for a streetcar at an intersection (e.g. King and Bathurst, near where we live), but the pedestrian signals had gone red, and the street car driver would just sit there, in anticipation that the light was going to go red at any instant. It feels like I saw more drivers just stop and wait out the entire extended portion of the light cycle, than would take the opportunity to cross Bathurst while the light was still green.

Training, and possibly TTC work rules are obviously an issue which would need to be addressed in any traffic light prioritization implementation for the pilot.
 
A slightly off-subject, but related comment: What was really frustrating to see was when the light was being held green for a streetcar at an intersection (e.g. King and Bathurst, near where we live), but the pedestrian signals had gone red, and the street car driver would just sit there, in anticipation that the light was going to go red at any instant. It feels like I saw more drivers just stop and wait out the entire extended portion of the light cycle, than would take the opportunity to cross Bathurst while the light was still green.

Training, and possibly TTC work rules are obviously an issue which would need to be addressed in any traffic light prioritization implementation for the pilot.

Then the pedestrian light needs to also be in sync, or, drivers need to be made aware of that situation and what to do.
 
Those are the benefits of that option, but there were a lot of drawbacks too. Most notably, the far-side stops wouldn't work like they do now because cars would be using the curb lane. There's a reason why the city's experts -- who, unlike us, are actually qualified to make these decisions -- chose the current option. You might disagree with them but you can't just declare that it's the superior option because you disagree.

And frankly, you're wrong. Even with the one-way option just as many people would end up driving through the intersections.


Either you didn’t read my post in full or you’re not making an effort to think it through.

With alternating one ways, there would be no green light ahead because no car would ever be allowed straight since it’s the wrong way. There’d never be a green. You’re suggesting that cars would be constantly running red lights? The alternating loops proposal also makes the streetcar lanes exclusive to streetcars so because they wouldn’t need to accomodate cars, they could be made separate and hostile to cars with humps and/or flexiposts creating a narrow corridor. There wouldn’t be any opportunity to merge into the streetcar lane.

Look at the Alternating Loops diagram again because you’re comments don’t fit with what was proposed.
 
How do red light cameras work with tracker-trailers and the long articulated streetcars? They could be on the far-side of an intersection and on the near-side (before the stop line) at the same time. Do they count the front of those vehicles as still "clearing" the intersection so they get no candid snapshots in the mail? (BTW. The streetcars have no license plates.)
 
Last edited:

Back
Top