[steveintoronto]

I think that pushing Transportation Services to allow the new-and-improved priority to actually be turned on could be the difference between success and failure for the pilot.

Glad you picked up on this. I'd thought of our prior conversations on this, and how it was left dangling as to what is in effect where, if at all. I absolutely agree! Why is this pilot being put to the test with hands tied behind its back?

Contrary to all the rah-rah on what a great success this is, it's going to be judged a failure unless it can actually show what it should be doing, not what it is doing now. The present status is saturated unless more radical changes are made, and demand is poised to swamp the status quo.

I also find it somewhat unfair that the effectiveness of the pilot is being evaluated without signal priority, whereas the 'before' condition did have priority at signals.

Whether or not that is a zero sum product is probably immaterial. What is completely germane is that *even if* there's an advantage being shown at this time, because the base line of the comparison is so skewed, it lends itself to being trashed by the naysayers.

I'm being pretty harsh in my critiques, not because I want this to fail, but because *it has to succeed*. But it won't at this rate. And people are blindly and blandly overlooking the original intent of the exercise. Freakin' picnic tables of virgin yellow plastic pseudo milk crates (which is a very poor choice in terms of eco design, I might add) aren't going to make this project any more successful. In fact, as much as I like the idea of bringing more people to King, it could just as easily kill this as help. Pedestrian congestion is the number one problem for Melbourne's Bourke Street Mall. How fast do the trams travel through the pedestrian core section? 5 kmh...with lights flashing and bells clanging. That's even slower than King was in the worst of times! Add drunk patrons wandering willy-nilly, being encouraged to doing so, and see how fast the King cars will travel.

The City is making this up as they go along. And transit priority appears to be the lowest rung on the ladder at this point.

I got another reply to a follow-on question from the Project Team, I wasn't going to bother posting it, so few posters here realize how tenuous this whole exercise is:
Q:
XXX:

Many thanks for your reply. Is there a website you could link or point to detailing the nature of the present TSP parameters?

Thank you

A:
Hi Stephen,

TSP updates and information on signal timing changes are not available in www.toronto.ca/kingstreetpilot. Nonetheless, if this information is made available, it will be published in this website.


Regards,
XXXX

I highly suspect he knows what I'm sniffing for, (Edit: In all fairness to someone so gracious and well-mannered, I wasn't about to put him on the spot with a question the politicians should be answering, he's probably tortured by that realization) and the answer is as Reaper states:

but according to the City's Open Data the system is actually installed at 7 other intersections in the pilot area but is sitting idle (it was turned off at the start of the pilot to update the system to take advantage of the new far-side stops).

WTF? It's like covering the air-intake on a high-performance engine to make it look better.

 

[reaperexpress]

I highly suspect he knows what I'm sniffing for, (Edit: In all fairness to someone so gracious and well-mannered, I wasn't about to put him on the spot with a question the politicians should be answering, he's probably tortured by that realization) and the answer is as Reaper states

I think this is a key point. Although City staff provide recommendations, City Council has the power to overrule them based on what they think citizens want. So in addition to emailing staff to ask that the transit priority system be turned back on in the 'transit priority' project area (via 311@toronto.ca), transit advocates could increase their strength by bringing councillors into the loop as well (the pilot area being in Ward 20 - Joe Cressy and Ward 28 - Lucy Troisi).

WTF? It's like covering the air-intake on a high-performance engine to make it look better.

I think it's more like removing a turbocharger on an an engine and doing 95% of the work to install a new more-efficient one, but then never actually connecting it because someone told you that turbochargers make noise (notwithstanding the fact that your new turbocharger will make a lot less noise than the old one you used for years without issue).

 

[Streety McCarface]

From link.

Why do some people think that the least efficient use of road space should be catered to along King Street? Even the bicycle is a better use of road space than the automobile.

That graphic has so many things wrong with it...Especially the fact that humans don't contribute to climate change by walking (food uses a lot of resources. Yes it's much less than any form of transit, but it's not that negligible), the fact that all things diesel are more efficient than anything electric, or that heavy rail can carry 80K PPHPD.

 

[TheKingEast]

My commute is taking longer. Once again cars going North/South on Yonge, Bay, University, etc are blocking the intersections and slowing everything down.

 

[dowlingm]

@steveintoronto the TTC CEO makes mention of “firmware issues” with the TSP rollout - my recollection from the KSP launch was that TSP go-live on King was supposed to have been done in February. Even allowing for usual underestimating and the effects of the winter, this is now behind to the extent of impacting the study conditions.

 

[steveintoronto]

my recollection from the KSP launch was that TSP go-live on King was supposed to have been done in February.

I recollect similar. In fact, it may have been mentioned a number of times by a number of persons in the project...mentioned in passing, not in commitment to actually get it up and running, let alone improving it.

There's no doubt that to improve the rudimentary 'extended green' aspect to something far more interactive would require an investment, and it's probably not even the TTC's domain, it's probably the City's.

From the City's website:

Traffic Signal Systems
Computerized traffic control signal systems are used to view and manage current traffic conditions, diagnose signal system problems and implement or modify signal timings remotely.

The existing Split Cycle Offset Optimization Technique (SCOOT) system is close to the end of its useful life – the equipment is aging, it is hard to get replacement parts, the intrusive SCOOT (loop) detectors are susceptible to road work and repairs are not keeping up, and the old communications infrastructure makes it difficult to communicate with the signals in the field. New technologies are now available that will help the City to overcome these problems. The City will be testing two technologies this year to determine which works best for Toronto.

At 10 locations on Yonge Street between Yonge Boulevard and Castlefield Avenue, the City will pilot a technology called InSync, which is used in the United States. This technology makes decisions based on video-analysis camera detection that measures vehicle delays and queue lengths on the approaches to the signalized intersection and relays that data to the intersection computer which then determines and implements the best timing plan in real time.

At 12 locations on Sheppard Avenue East between Neilson Road and Meadowvale Road, the City will pilot a technology called Sydney Coordinated Adaptive Traffic System (SCATS), which is used in Australia, Asia and the United States. This technology makes decisions using radar detection to measure traffic flow up and downstream of the intersection and then uses an algorithm to determine and implement the best timing plan in real time.

The performance and effectiveness on InSync and SCATS will be measured by comparing before-and-after conditions relating to traffic volumes, travel times, pedestrian delays, stops and side street delays. In addition to newly installed vehicle count stations and Bluetooth detectors, City staff will also use commercial GPS data in the evaluation. The output of the pilot study will allow the City to identify the technological solution that offers the best cost and benefits for the City.

https://www.toronto.ca/services-pay...nals-street-signs/traffic-signals-in-toronto/

No matter who is responsible for the poor state of Toronto signal management, it comes back to promises being made for the King Project that through no *intrinsic* fault of the concept, it's already at a point that is as good as it can get with the present limitations.

And that's not good enough. Unless this improves further, it can't prove the worth of the concept. And Council is living in a dream, and those cheering as to what a great thing it is are not doing any favours to the outcome. It needs constant pressure to improve further.

Painting racing stripes on vehicles doesn't make them go any faster.

 

[TransitBart]

Painting racing stripes on vehicles doesn't make them go any faster.

Yes it does. Just like talking and planning builds subways. Fund a TPAP and it’s practically open. Schedule a news conference with Steve Del Duca and it opens the next day. Fairy dust and unicorns.

 

[steveintoronto]

Yes it does. Just like talking and planning builds subways. Fund a TPAP and it’s practically open. Schedule a news conference with Steve Del Duca and it opens the next day. Fairy dust and unicorns.

I feel badly sometimes being so cynical, but Toronto is doing what you list in so many ways, as you point out. I got to wondering how much of the 'traffic congestion' in this city is down to antiquated traffic control? In other words, is the present limitation of the King Project symptomatic of the greater failings of intersection signalling and traffic control?

The answer for the King car may require specific attention for signalling, vis a vis priority and other aspects, certainly intuitive control, but it alone can only do so much in a city that has fallen behind many others in terms of intelligent and intuitive signalling and control of traffic.

Reaper has a specialty in this area, I look forward to hearing more from him. The TTC is certainly worth a lot of criticism, but in this instance, it may be well beyond them.

Toronto used to be world leading in 'computerizing' traffic control...four decades or so back. Now we're a laggard.

Here's some retrospect, on *two* issues we've been promised time and again:

[...]
Tory says this initiative is one that makes sense and will have a tangible effect.

“We all know the experience of sitting at a light that is red, noticing that traffic going the other direction is non-existent, and saying, ‘Why is this light red? Why can’t it be green because I’m sitting here waiting to go and maybe a lot of people lined up behind me.’ Well, this technology is going to finally allow us to have an answer to that question. We won’t be sitting at a red light when there’s no traffic.”

One of the two types of new signals will be tested over the next year at 10 intersections on Yonge Street, while the other will be tested at 12 intersections on Sheppard Avenue East.

READ MORE: Mayor Tory wants special constable status for Toronto’s new traffic wardens

Toronto was the first city in North America to use a computerized traffic control system, back in the 1960s. Some 2,400 of the city’s traffic signals are computer-controlled.

However, the existing system is aging and as a result of communication breakdowns and difficulty getting replacement parts, the city says it needs to be modernized.

https://globalnews.ca/news/3878879/toronto-to-test-new-smart-traffic-signals/

And the CTV headline:
Most Toronto traffic lights to be retimed by 2017
https://toronto.ctvnews.ca/most-toronto-traffic-lights-to-be-retimed-by-2017-1.2958369

 

[TransitBart]

Time for a new thread. If I recall correctly, the capital was allocated for a new traffic signal control computer system. The current one is something like two decades old. The upgrade is in progress.

 

[reaperexpress]

@steveintoronto the TTC CEO makes mention of “firmware issues” with the TSP rollout - my recollection from the KSP launch was that TSP go-live on King was supposed to have been done in February. Even allowing for usual underestimating and the effects of the winter, this is now behind to the extent of impacting the study conditions.

When did the CEO say that the firmware issues are hampering the TSP rollout? Any chance it's in writing so I can follow up on it?

 

[reaperexpress]

Time for a new thread. If I recall correctly, the capital was allocated for a new traffic signal control computer system. The current one is something like two decades old. The upgrade is in progress.

We have a thread for this, it's here: Roads: Traffic Signals.

I may provide some background once I do some research to see what information is publicly available, but long story short the City already replaced that decades-old MTSS central system which runs almost all of the city's 2000+ signals. What is being replaced now is the SCOOT adaptive control system which runs the signals on a handful of highly-variable traffic routes such as Lakeshore Blvd, The Queensway and Don Mills.

There's no doubt that to improve the rudimentary 'extended green' aspect to something far more interactive would require an investment, and it's probably not even the TTC's domain, it's probably the City's.

The City makes use of virtually every available strategy to prioritize transit vehicles, though a given intersection doesn't necessarily use every tool available - that's a matter of policy and debate regarding the level to which transit vehicles should be prioritized at that intersection. The system is by no means limited to just extending the green, it can do pretty much anything you can think of.

But in the case of King Street, with simple two-phase intersections running fixed-time, green extensions (and sometimes red truncations) are all that really makes sense anyway.

At minor intersections, it is not possible to shorten the red light when a streetcar is approaching, because the north-south green is already equal to the minimum pedestrian crossing time.

For example, look at King & John. Given its nature as a minor cross street, it's almost certain the north-south green will be as short as possible, which according to the City Traffic Signal Operations Policy is:

7s Walk
13s Flashing Don't Walk (15m @ 1.2 m/s)
3s Amber
3s All-Red
Total: 26 sec

But it's actually not a big deal that truncation is not possible here, because you can get very good results just with 'rudimentary' extended greens.

Assuming a 70-sec cycle length (standard for downtown), here is the chart of streetcar delay throughout the cycle with no TSP:

The worst case scenario is if the streetcar arrives just at the end of the green, in which case it sits through all the clearance and red time*. Each second later that the streetcar arrives, it would have to wait one second less until the next green, until eventually the streetcar arriving just at the start of green has a delay of zero.

The average delay over the 70-second cycle is the total delay (area under the graph, [Max Delay]² /2) divided by the cycle length, which here works out to 7.3 seconds.

With TSP
The City allows up to 30 seconds of green extension at minor intersections. So before the light changes to yellow, it checks whether there is a streetcar estimated to be less than 30 seconds away and if there is, it will hold the light green until it passes through. The problem is that if the streetcar actually ends up taking longer than 30 seconds, the light would extend to the max and then change to yellow before the streetcar made it through. In that case, TSP has actually increased the delay to the streetcar by 30 seconds because if the green hadn't been extended the light would have been about to turn back to green by then, and instead the streetcar needs to sit through the entire red (this is called a "failed extension").

So to accommodate variability, you need to leave a margin of error. With a near-side stop, there is a huge amount of variability from one streetcar to another, so you may for example leave a 14-second margin of error to minimize failed extensions. So instead of extending for vehicles that are estimated to be less than 30 seconds from the intersection, you would only extend for vehicles estimated to be less than 16 seconds away (in case they actually take longer):

Moving the stops to far-side as has been done with the King Pilot can bring a big improvement by removing the variability of the stop, allowing you to use a much smaller margin of error, and therefore a longer horizon for approaching vehicles. Within the same 30-second maximum, one might now use a 6-second margin of error, allowing the signal to extend for vehicles estimated to be within 24 seconds of the intersection.

THE BOTTOM LINE:

Just using the City's current standard of 30-second maximum green extension along with the new stop layouts, TSP could reduce signal delays by a whopping 93% at John St to an average delay of only 0.5 seconds. I seriously challenge anyone to come up with a different way of prioritizing streetcars that can achieve those kinds of savings without massively screwing over everyone else at the intersection.

__

*Actually streetcars can proceed during the yellow, but there is also a couple seconds lost at the beginning of the green before vehicles actually start moving which mostly cancels that out. Convention is to assume that the effective green is 1 sec greater than the displayed green, but I haven't accounted for that here to keep the illustration more intuitive.

 

[mdrejhon]

If you have added intelligence for multiple cycles, one could theoretically extend greens over 2 cycles instead of 1.

That requires very reliable streetcar arrival prediction times, but if you know a streetcar is already accidentally "stuck" behind a long red light (45 seconds) at an important artery like University further down the road, then you have time to do a 2-cycle minor green extension (instead of a 1-cycle major green extension) to realign the timing of green to a predicted arrival of streetcar. This can help the streetcar catch up from its accidentally getting stuck behind an earlier red light.

Basically, you try to never have long red lights for a streetcar, but if a streetcar does get stuck (light goes red the moment the streetcar approaches one) for any reason, then the downstream lights can theoretically reliably predictively adjust their cycles over a 2-cycle period if there's no conflict with a streetcar in the opposite direction.

 

[reaperexpress]

If you have added intelligence for multiple cycles, one could theoretically extend greens over 2 cycles instead of 1.

That requires very reliable streetcar arrival prediction times, but if you know a streetcar is already accidentally "stuck" behind a long red light (45 seconds) at an important artery like University further down the road, then you have time to do a 2-cycle minor green extension (instead of a 1-cycle major green extension) to realign the timing of green to a predicted arrival of streetcar. This can help the streetcar catch up from its accidentally getting stuck behind an earlier red light.

Basically, you try to never have long red lights for a streetcar, but if a streetcar does get stuck (light goes red the moment the streetcar approaches one) for any reason, then the downstream lights can theoretically reliably predictively adjust their cycles over a 2-cycle period if there's no conflict with a streetcar in the opposite direction.

Yes, this is called predictive priority, and can work really well where there are no stops between signals and priority requests are not frequent (typically at least 10 minute headways for service).

But in the King Pilot area there are stops at almost every signal, which makes travel times unpredictable from more than a block away. And there is on average a streetcar every 55 seconds during rush hour (every 110 seconds in each direction), which makes it impossible to look more than a cycle ahead given that each cycle is 70-110 seconds long. Even if only the streetcars with above-average headways get priority, that's still a TSP request every 110 seconds on average.

 

[steveintoronto]

Excellent posts! To which I wonder: "Why could the King Pilot Project Team supply this sort of answer?" And that makes a massive point in itself. The left hand doesn't know what the right one is doing when it comes to integrating and *intuitive prediction* of Toronto traffic flows.

Reaper has supplied an excellent post, in fact UT should offer to have him write a feature on this.

Without poring over the minutiae yet, this claim has to be stepped up a good notch:

The system is by no means limited to just extending the green, it can do pretty much anything you can think of.

But can it/does it?

What layers of parameter are the TTC supplying real-time from their vehicles to the control functions of the intersection lights? Either directly, or through a central control system that integrates in real-time two way vehicle position, speed, acceleration, deceleration and the approaching light cycle parameters?

In other words, a fully integrated CBTC system also encompassing the intersection lights. This would by definition assume PTO of the streetcars. This is a decision the City is wholly unprepared to take, and thus the King route never progressing past where it is now.

This might be what @dowlingm meant by "firmware" albeit the term infers a proprietary system is already up and running, or at least in place, but not actuated. Without having even closely examined Reaper's excellent post in detail, something that has been noted in other systems as per "green light priority" is that if it doesn't take account the oncoming tram/streetcar traffic, it spites Peter to pay Paul, even if intersecting vehicular traffic be damned (edit: Which is exactly what is done in a number of US and other nation's cities)....thus the emphasis on the need for PTO/PTC to co-ordinate those 'priority' lights to maximize benefit to what is prioritized, while minimizing the imposition on all other traffic affected, which must include pedestrians!

That requires very reliable streetcar arrival prediction times,

Basically, you try to never have long red lights for a streetcar, but if a streetcar does get stuck (light goes red the moment the streetcar approaches one) for any reason, then the downstream lights can theoretically reliably predictively adjust their cycles over a 2-cycle period if there's no conflict with a streetcar in the opposite direction.

Which all indicates the need for an overall reactive dispatch system integrated with the signal lights, not only controlling the light cycles and parameters, but also the arrival and departure times of streetcars including velocity control to optimize the performance of that loop.

Which brings me back to the "King Balooza Karnival". The City had better make up its mind on this. Either the tracks are going to have to be controlled access from pedestrians too, or King just becomes an amusement park, not a Transit Mall. And the third most heavily used transit route in Toronto has now reached its peak, and can only slide backwards.

 

[BMO]

We have a thread for this, it's here: Roads: Traffic Signals.

I may provide some background once I do some research to see what information is publicly available, but long story short the City already replaced that decades-old MTSS central system which runs almost all of the city's 2000+ signals. What is being replaced now is the SCOOT adaptive control system which runs the signals on a handful of highly-variable traffic routes such as Lakeshore Blvd, The Queensway and Don Mills.



The City makes use of virtually every available strategy to prioritize transit vehicles, though a given intersection doesn't necessarily use every tool available - that's a matter of policy and debate regarding the level to which transit vehicles should be prioritized at that intersection. The system is by no means limited to just extending the green, it can do pretty much anything you can think of.

But in the case of King Street, with simple two-phase intersections running fixed-time, green extensions (and sometimes red truncations) are all that really makes sense anyway.

At minor intersections, it is not possible to shorten the red light when a streetcar is approaching, because the north-south green is already equal to the minimum pedestrian crossing time.

For example, look at King & John. Given its nature as a minor cross street, it's almost certain the north-south green will be as short as possible, which according to the City Traffic Signal Operations Policy is:

7s Walk
13s Flashing Don't Walk (15m @ 1.2 m/s)
3s Amber
3s All-Red
Total: 26 sec

But it's actually not a big deal that truncation is not possible here, because you can get very good results just with 'rudimentary' extended greens.

Assuming a 70-sec cycle length (standard for downtown), here is the chart of streetcar delay throughout the cycle with no TSP:

The worst case scenario is if the streetcar arrives just at the end of the green, in which case it sits through all the clearance and red time*. Each second later that the streetcar arrives, it would have to wait one second less until the next green, until eventually the streetcar arriving just at the start of green has a delay of zero.
View attachment 142420
The average delay over the 70-second cycle is the total delay (area under the graph, [Max Delay]² /2) divided by the cycle length, which here works out to 7.3 seconds.

With TSP
The City allows up to 30 seconds of green extension at minor intersections. So before the light changes to yellow, it checks whether there is a streetcar estimated to be less than 30 seconds away and if there is, it will hold the light green until it passes through. The problem is that if the streetcar actually ends up taking longer than 30 seconds, the light would extend to the max and then change to yellow before the streetcar made it through. In that case, TSP has actually increased the delay to the streetcar by 30 seconds because if the green hadn't been extended the light would have been about to turn back to green by then, and instead the streetcar needs to sit through the entire red (this is called a "failed extension").

So to accommodate variability, you need to leave a margin of error. With a near-side stop, there is a huge amount of variability from one streetcar to another, so you may for example leave a 14-second margin of error to minimize failed extensions. So instead of extending for vehicles that are estimated to be less than 30 seconds from the intersection, you would only extend for vehicles estimated to be less than 16 seconds away (in case they actually take longer):
View attachment 142421

Moving the stops to far-side as has been done with the King Pilot can bring a big improvement by removing the variability of the stop, allowing you to use a much smaller margin of error, and therefore a longer horizon for approaching vehicles. Within the same 30-second maximum, one might now use a 6-second margin of error, allowing the signal to extend for vehicles estimated to be within 24 seconds of the intersection.

View attachment 142422

THE BOTTOM LINE:

Just using the City's current standard of 30-second maximum green extension along with the new stop layouts, TSP could reduce signal delays by a whopping 93% at John St to an average delay of only 0.5 seconds. I seriously challenge anyone to come up with a different way of prioritizing streetcars that can achieve those kinds of savings without massively screwing over everyone else at the intersection.

__

*Actually streetcars can proceed during the yellow, but there is also a couple seconds lost at the beginning of the green before vehicles actually start moving which mostly cancels that out. Convention is to assume that the effective green is 1 sec greater than the displayed green, but I haven't accounted for that here to keep the illustration more intuitive.

While this may work in theory, typically TSP uses subsequent cycles to go back to the original coordinated signal plan. When you have a high frequency line like King it leaves the signal in a perpetual state of playing catch up, especially at major intersections which is where the highest delays are. Many would argue the signals work great at John already, the issue is the major intersections, compounded by their large walk time requirements since intersections like Spadina and University don't have a median for pedestriana to complete only part of the crossing.