News   Jan 15, 2026
 894     1 
News   Jan 15, 2026
 527     1 
News   Jan 15, 2026
 637     2 

Roads: Traffic Signals

The thing is, how exactly would this work? Would "no right on red" signs have to be placed at each downtown intersection, or would it be within a specific boundary that drivers are expected to know? If I'm not mistaken, Montreal bans RTOR, but it's on an island, so it's obvious when you've entered the NTOR region.
Yes, on Montreal, there's signs on the bridges. But in New York City the Bronx isn't an island. And I believe only parts of Long Island are no right on red. I'm sure there's signage there somewhere, but as a non-local driver, who has enough signage to read and not get lost, offhand, I don't remember ever seeing a sign there.
 
The thing is, how exactly would this work? Would "no right on red" signs have to be placed at each downtown intersection, or would it be within a specific boundary that drivers are expected to know? If I'm not mistaken, Montreal bans RTOR, but it's on an island, so it's obvious when you've entered the NTOR region.
It could be implemented similarly to Montreal. Downtown Ottawa might as well be an island given how many barriers surround it, such as the Ottawa River, Rideau River, Rideau Canal, Hwy 417 and O-Train Line 2 Trillium.

Many of the bridges into the area are bicycle/pedestrian only, and I'm assuming that bicycles would have an exemption to the area RTOR ban, so there wouldn't need to be any signs on those bridges.
Capture2.JPG

Capture1.JPG


The area could be potentially be signed similarly to speed limit areas:
No RTOR Area.png


Similar to Montreal, there could be oversized signs at the entries:
No RTOR Ottawa.png
 
Last edited:
It could be implemented similarly to Montreal. Downtown Ottawa might as well be an island given how many barriers surround it, such as the Ottawa River, Rideau River, Rideau Canal, Hwy 417 and O-Train Line 2 Trillium.

Many of the bridges into the area are bicycle/pedestrian only, and I'm assuming that bicycles would have an exemption to the area RTOR ban, so there wouldn't need to be any signs on those bridges.
View attachment 708086
View attachment 708087

The area could be potentially be signed similarly to speed limit areas:
View attachment 708088

Similar to Montreal, there could be oversized signs at the entries:
View attachment 708090
I like this idea. What you have in mind for other places, such as Toronto? Maybe Humber River for the West side, the 401 for the North side, and Rouge River for the East side?
 
Last edited:
It could be implemented similarly to Montreal. Downtown Ottawa might as well be an island given how many barriers surround it, such as the Ottawa River, Rideau River, Rideau Canal, Hwy 417 and O-Train Line 2 Trillium.

Many of the bridges into the area are bicycle/pedestrian only, and I'm assuming that bicycles would have an exemption to the area RTOR ban, so there wouldn't need to be any signs on those bridges.
View attachment 708086
View attachment 708087

The area could be potentially be signed similarly to speed limit areas:
View attachment 708088

Similar to Montreal, there could be oversized signs at the entries:
View attachment 708090
Unfortunately, I can see the automobile disciple Doug Ford vetoing such a broad city-wide "no right turn on red" by-law.
 
I have a traffic signal question related to bike signals. There are 2 locations in Hamilton I've been interested in the logic behind the bike signal timing and whether it can be changed:

1. Bay at King and Bay at Main (https://maps.app.goo.gl/v7xTTRukTtdeGT5g6?g_st=ac)
Here the bike signal doesn't go green during the LPI and instead waits for main green light for cars. Is this just a simple programming change or would there be a reason why they would keep the bike signal red?

2. Cannon at Sherman travelling East(https://maps.app.goo.gl/AUTH6DqmJD8iCuVo8?g_st=ac)
This is the transition of Cannon from one way to two way so the bike lane splits. The issue is that the crossing of Cannon at the East side of the intersection is 2-stage, so the eastbound bike signal has to wait an additional 20-30 seconds after the westbound green until the pedestrian phase of the 2-stage crossing is complete. There is then a relatively short green for the bike light before it goes back to red to allow for the Sherman traffic phase. This is one I'm quite curious about, as ideally you could have a bike green with some signal to yield to pedestrians. They are currently rebuilding this interesting and converting Sherman fully to 2-way traffic, so I am hoping signal changes can help the long bike delay.
 
I have a traffic signal question related to bike signals. There are 2 locations in Hamilton I've been interested in the logic behind the bike signal timing and whether it can be changed:

1. Bay at King and Bay at Main (https://maps.app.goo.gl/v7xTTRukTtdeGT5g6?g_st=ac)
Here the bike signal doesn't go green during the LPI and instead waits for main green light for cars. Is this just a simple programming change or would there be a reason why they would keep the bike signal red?
The typical way to control a bike signal is as an "overlap" of the vehicle signal. So basically it just copies what the vehicle signal is doing (potentially with some additional logic conditions). When you implement an LPI using the basic LPI setting in the controller, it just adds 5(?) seconds of red at the start of the phase. Since the bike signal is copying the vehicle signal it gets those 5 seconds of red as well. I doubt that's what the city wants, but it would be a decent amount of work to change the setup to avoid adding that red time to the bike signal. One way to get the bike signal to start with the ped phase instead of programming a 5(?) second green delay in the vehicle phase, they could add a 5-second dummy phase before the vehicle pahse and have the bicycle phase and pedestrian phase overlap with both it and the vehicle phase. The challenge is that the pedestrian phase is typically not wired as an overlap, so implementing this would require redoing the input/output mapping, which is a major change that can't just be implemented on the fly like timing changes.

2. Cannon at Sherman travelling East(https://maps.app.goo.gl/AUTH6DqmJD8iCuVo8?g_st=ac)
This is the transition of Cannon from one way to two way so the bike lane splits. The issue is that the crossing of Cannon at the East side of the intersection is 2-stage, so the eastbound bike signal has to wait an additional 20-30 seconds after the westbound green until the pedestrian phase of the 2-stage crossing is complete. There is then a relatively short green for the bike light before it goes back to red to allow for the Sherman traffic phase. This is one I'm quite curious about, as ideally you could have a bike green with some signal to yield to pedestrians. They are currently rebuilding this interesting and converting Sherman fully to 2-way traffic, so I am hoping signal changes can help the long bike delay.
It is possible to let bikes proceed while yielding to pedestrians but you need to be careful with the design to make sure it's clear to cyclists that the green light doesn't apply to the pedestrian crossing. This is becoming increasingly common at protected intersections, where the crosswalk across the bike path is not included in the signalized crossing.

Here's an example on Laurier St at Waller St in Ottawa. The pedestrians are standing in the absolute worst spot to wait for the light to change - this is common on bike paths that lack any height difference with the sidewalk. More recent designs usually have a 5-6 cm curb (with wheelchair ramp) to make the cycling path more obvious to pedestrians.
Screenshot 2026-01-13 at 16.48.33.png


Northbound on Bathurst at Adelaide cyclists also have an unsignalized crossing of a signalized crosswalk, but in that case there's no northbound bike signal so there's less chance of cyclist confusion.
Screenshot 2026-01-13 at 16.46.08.png
 
Last edited:
The pedestrians are standing in the absolute worst spot to wait for the light to change -
View attachment 708582

Oh, have you seen Queens Quay where oblivious pedestrians stand in the middle of the streetcar ROW waiting for the light on the tracks where streetcars are usually barrelling down the corridor?

Screenshot 2026-01-13 at 9.04.54 PM.png
 
The typical way to control a bike signal is as an "overlap" of the vehicle signal. So basically it just copies what the vehicle signal is doing (potentially with some additional logic conditions). When you implement an LPI using the basic LPI setting in the controller, it just adds 5(?) seconds of red at the start of the phase. Since the bike signal is copying the vehicle signal it gets those 5 seconds of red as well. I doubt that's what the city wants, but it would be a decent amount of work to change the setup to avoid adding that red time to the bike signal. One way to get the bike signal to start with the ped phase instead of programming a 5(?) second green delay in the vehicle phase, they could add a 5-second dummy phase before the vehicle pahse and have the bicycle phase and pedestrian phase overlap with both it and the vehicle phase. The challenge is that the pedestrian phase is typically not wired as an overlap, so implementing this would require some rewiring, which is a fair bit of work.
Honestly this seems like an incredibly cumbersome and archaic system. How is it possible that traffic light phases not fully programmable? Is what you're describing true for even the latest traffic light controllers? What is the actual technical implementation of an 'overlap', do you need a technician to literally hard wire the lights together in parallel or something?
 
Honestly this seems like an incredibly cumbersome and archaic system. How is it possible that traffic light phases not fully programmable? Is what you're describing true for even the latest traffic light controllers? What is the actual technical implementation of an 'overlap', do you need a technician to literally hard wire the lights together in parallel or something?
Yes North American controllers are incredibly cumbersome and archaic. You cannot comprehend how frustrating it is to deal with this kind of nonsense after having worked on traffic signals in the Netherlands that actually work in a logical way.

An overlap is a signal group that is not actually included in the phase structure, it sort of exists separately and you need to define its state relative to other phases that are actually in the phase structure. It is an absurd solution to the self-inflicted constraints created by the "ring and barrier" phase structure. which usually only includes 8 phases at a standard intersection.
Capture1.PNG

For example if you wanted to add a northbound right turn phase, you'd create an "overlap" of phase 7, telling the right turn signal to turn green whenever the westbound left turn phase does. Or if you're really fancy you'd tell it to overlap with both phase 6 and phase 7, but only if the pedestrian phase for phase 6 isn't on (because the ped phase conflicts with the right turn).

The ring and barrier structure is how they used to control signals when there was a literal ring with metal strips on it that would rotate and complete different circuits as different parts passed by the electrical contactor. So different lights get connected to power at different points in the ring's cycle. The barriers connected rings together at certain points in the cycle to prevent them from getting out of sync with each other.

In the Netherlands in the 1990's they realized that computers exist so there's no need for this arbitrary organization of signal groups. You can just tell the computer which movements can go at the same time as each other using a conflict matrix. (Which is something North American controllers also have!) A computer is perfectly capable of figuring out which signal groups are valid to combine based on the constrants the engineer has specified.

To this day North American controller manufacturers still use the ring-barrier structure, now offering four-ring controllers! Which still doesn't solve the probem because there is no way to arrange right turn phases in a ring-barrier structure that allows them to turn green at all of the moments when they should logically be able to!

In the Netherlands there's no such thing as an overlap. Every signal group is controlled directly and is included separately in the conflict matrix. If you want a predefined relationship between specific signal groups you can program that, but it's not baked into the control structure. So the Dutch standard numbering scheme includes a separate number for each movement. 1-12 are the usual vehicle movements, 21-28 are the usual bike movements (each leg accommodates 2-stage crossing with a green wave between them), 31-38 are the typical ped movements (again two-stage crossings), 41-52 are the 12 vehicle movements for transit signals, 61-72 are the 12 movements for vehicles if there's a second stage within the intersection (or a pre-signal), 81-88 are the usual bike movements in the contraflow direction (e.g. for two-way paths), again assuming two-stage crossings, and 91-98 are in case you need to use different signal groups for different directions on the same crosswalk (e.g. to enforce a pedestrian green wave). Here's a hypothetical intersection with its signal phases numbered. You'll note that every movement has a different number because they're controlled separately.

Capture4.png

Image from wegenwiki

Meanwhile in simple old America, here's the standard numbering for signal phases at intersections. They give you 8 numbers. The pedestrian phase is the same phase as the adjacent vehicle phase.
Capture2.PNG

You can always make up numbers for whatever you want, but the fact that the standard doesn't even consider the possibility of a right turn signal says a lot.

The pedestrian signal and the parallel vehicle signal are separate signal groups in the Netherlands because combining them into the same signal group would be stupid. A right turn phase along a street conflicts with the pedestrian phase to its right but not the vehicle phase to its left so of course those need to be controlled differently to each other.

Meanwhile the ring-barrier structure prevents valid combinations such as Phase 6 Pedestrian with Phase 3 Vehicle, because the signal thinks those two phases conflict. But in fact it's only the vehicle portion of phase 6 that conflicts with phase 3, not the pedestrians. And lord help you if you want to control the right turn signal based on the actual amount of traffic in the right turn lane, instead of just copying the signal states from a different movement.
 
Last edited:
Oh, have you seen Queens Quay where oblivious pedestrians stand in the middle of the streetcar ROW waiting for the light on the tracks where streetcars are usually barrelling down the corridor?

View attachment 708603
To be fair, there aint no streetcars barrelling through this intersection....they crawl at a snails pace.
 
Oh, have you seen Queens Quay where oblivious pedestrians stand in the middle of the streetcar ROW waiting for the light on the tracks where streetcars are usually barrelling down the corridor?
In both cases - where the trump is the (red and green) paint? That would go a long way to making it very clear to pedestrians where they are standing, and at least which direction(s) to watch.
 
Yes North American controllers are incredibly cumbersome and archaic. You cannot comprehend how frustrating it is to deal with this kind of nonsense after having worked on traffic signals in the Netherlands that actually work in a logical way.

An overlap is a signal group that is not actually included in the phase structure, it sort of exists separately and you need to define its state relative to other phases that are actually in the phase structure. It is an absurd solution to the self-inflicted constraints created by the "ring and barrier" phase structure. which usually only includes 8 phases at a standard intersection.
View attachment 708612
For example if you wanted to add a northbound right turn phase, you'd create an "overlap" of phase 7, telling the right turn signal to turn green whenever the westbound left turn phase does. Or if you're really fancy you'd tell it to overlap with both phase 6 and phase 7, but only if the pedestrian phase for phase 6 isn't on (because the ped phase conflicts with the right turn).

The ring and barrier structure is how they used to control signals when there was a literal ring with metal strips on it that would rotate and complete different circuits as different parts passed by the electrical contactor. So different lights get connected to power at different points in the ring's cycle. The barriers connected rings together at certain points in the cycle to prevent them from getting out of sync with each other.

In the Netherlands in the 1990's they realized that computers exist so there's no need for this arbitrary organization of signal groups. You can just tell the computer which movements can go at the same time as each other using a conflict matrix. (Which is something North American controllers also have!) A computer is perfectly capable of figuring out which signal groups are valid to combine based on the constrants the engineer has specified.

To this day North American controller manufacturers still use the ring-barrier structure, now offering four-ring controllers! Which still doesn't solve the probem because there is no way to arrange right turn phases in a ring-barrier structure that allows them to turn green at all of the moments when they should logically be able to!

In the Netherlands there's no such thing as an overlap. Every signal group is controlled directly and is included separately in the conflict matrix. If you want a predefined relationship between specific signal groups you can program that, but it's not baked into the control structure. So the Dutch standard numbering scheme includes a separate number for each movement. 1-12 are the usual vehicle movements, 21-28 are the usual bike movements (each leg accommodates 2-stage crossing with a green wave between them), 31-38 are the typical ped movements (again two-stage crossings), 41-52 are the 12 vehicle movements for transit signals, 61-72 are the 12 movements for vehicles if there's a second stage within the intersection (or a pre-signal), 81-88 are the usual bike movements in the contraflow direction (e.g. for two-way paths), again assuming two-stage crossings, and 91-98 are in case you need to use different signal groups for different directions on the same crosswalk (e.g. to enforce a pedestrian green wave). Here's a hypothetical intersection with its signal phases numbered. You'll note that every movement has a different number because they're controlled separately.

View attachment 708623
Image from wegenwiki

Meanwhile in simple old America, here's the standard numbering for signal phases at intersections. They give you 8 numbers. The pedestrian phase is the same phase as the adjacent vehicle phase.
View attachment 708624
You can always make up numbers for whatever you want, but the fact that the standard doesn't even consider the possibility of a right turn signal says a lot.

The pedestrian signal and the parallel vehicle signal are separate signal groups in the Netherlands because combining them into the same signal group would be stupid. A right turn phase along a street conflicts with the pedestrian phase to its right but not the vehicle phase to its left so of course those need to be controlled differently to each other.

Meanwhile the ring-barrier structure prevents valid combinations such as Phase 6 Pedestrian with Phase 3 Vehicle, because the signal thinks those two phases conflict. But in fact it's only the vehicle portion of phase 6 that conflicts with phase 3, not the pedestrians. And lord help you if you want to control the right turn signal based on the actual amount of traffic in the right turn lane, instead of just copying the signal states from a different movement.
Wow, thanks for the detailed explanation! This is so crazy to me - so much unnecessary complexity and inflexibility that makes so little sense. From reading your post it took me like 15 seconds to more or less understand how a Dutch controller works whereas this whole ring and barrier thing just adds so many unnecessary and baffling constructs.

Is there any regulatory/bureaucratic reason why we keep using this, or is it just industry inertia? Is anyone in the North American industry even trying to move away from this archaic stuff to something more sensible? Is it possible to import controllers from NL for example?
 
Last edited:
Yes North American controllers are incredibly cumbersome and archaic. You cannot comprehend how frustrating it is to deal with this kind of nonsense after having worked on traffic signals in the Netherlands that actually work in a logical way.

An overlap is a signal group that is not actually included in the phase structure, it sort of exists separately and you need to define its state relative to other phases that are actually in the phase structure. It is an absurd solution to the self-inflicted constraints created by the "ring and barrier" phase structure. which usually only includes 8 phases at a standard intersection.
View attachment 708612
For example if you wanted to add a northbound right turn phase, you'd create an "overlap" of phase 7, telling the right turn signal to turn green whenever the westbound left turn phase does. Or if you're really fancy you'd tell it to overlap with both phase 6 and phase 7, but only if the pedestrian phase for phase 6 isn't on (because the ped phase conflicts with the right turn).

The ring and barrier structure is how they used to control signals when there was a literal ring with metal strips on it that would rotate and complete different circuits as different parts passed by the electrical contactor. So different lights get connected to power at different points in the ring's cycle. The barriers connected rings together at certain points in the cycle to prevent them from getting out of sync with each other.

In the Netherlands in the 1990's they realized that computers exist so there's no need for this arbitrary organization of signal groups. You can just tell the computer which movements can go at the same time as each other using a conflict matrix. (Which is something North American controllers also have!) A computer is perfectly capable of figuring out which signal groups are valid to combine based on the constrants the engineer has specified.

To this day North American controller manufacturers still use the ring-barrier structure, now offering four-ring controllers! Which still doesn't solve the probem because there is no way to arrange right turn phases in a ring-barrier structure that allows them to turn green at all of the moments when they should logically be able to!

In the Netherlands there's no such thing as an overlap. Every signal group is controlled directly and is included separately in the conflict matrix. If you want a predefined relationship between specific signal groups you can program that, but it's not baked into the control structure. So the Dutch standard numbering scheme includes a separate number for each movement. 1-12 are the usual vehicle movements, 21-28 are the usual bike movements (each leg accommodates 2-stage crossing with a green wave between them), 31-38 are the typical ped movements (again two-stage crossings), 41-52 are the 12 vehicle movements for transit signals, 61-72 are the 12 movements for vehicles if there's a second stage within the intersection (or a pre-signal), 81-88 are the usual bike movements in the contraflow direction (e.g. for two-way paths), again assuming two-stage crossings, and 91-98 are in case you need to use different signal groups for different directions on the same crosswalk (e.g. to enforce a pedestrian green wave). Here's a hypothetical intersection with its signal phases numbered. You'll note that every movement has a different number because they're controlled separately.

View attachment 708623
Image from wegenwiki

Meanwhile in simple old America, here's the standard numbering for signal phases at intersections. They give you 8 numbers. The pedestrian phase is the same phase as the adjacent vehicle phase.
View attachment 708624
You can always make up numbers for whatever you want, but the fact that the standard doesn't even consider the possibility of a right turn signal says a lot.

The pedestrian signal and the parallel vehicle signal are separate signal groups in the Netherlands because combining them into the same signal group would be stupid. A right turn phase along a street conflicts with the pedestrian phase to its right but not the vehicle phase to its left so of course those need to be controlled differently to each other.

Meanwhile the ring-barrier structure prevents valid combinations such as Phase 6 Pedestrian with Phase 3 Vehicle, because the signal thinks those two phases conflict. But in fact it's only the vehicle portion of phase 6 that conflicts with phase 3, not the pedestrians. And lord help you if you want to control the right turn signal based on the actual amount of traffic in the right turn lane, instead of just copying the signal states from a different movement.
Good heavens! That's a very comprehensive and (fairly) clear explanation. Thanks.

Question: You say this bizarre system is used in "North America" - is there any reason why we went for this and would to be possible/permissable for Toronto (or Ontario) to just 'move on"? Have other Cities/Provinces/States done so?
 
The typical way to control a bike signal is as an "overlap" of the vehicle signal. So basically it just copies what the vehicle signal is doing (potentially with some additional logic conditions). When you implement an LPI using the basic LPI setting in the controller, it just adds 5(?) seconds of red at the start of the phase. Since the bike signal is copying the vehicle signal it gets those 5 seconds of red as well. I doubt that's what the city wants, but it would be a decent amount of work to change the setup to avoid adding that red time to the bike signal. One way to get the bike signal to start with the ped phase instead of programming a 5(?) second green delay in the vehicle phase, they could add a 5-second dummy phase before the vehicle pahse and have the bicycle phase and pedestrian phase overlap with both it and the vehicle phase. The challenge is that the pedestrian phase is typically not wired as an overlap, so implementing this would require redoing the input/output mapping, which is a major change that can't just be implemented on the fly like timing changes.


It is possible to let bikes proceed while yielding to pedestrians but you need to be careful with the design to make sure it's clear to cyclists that the green light doesn't apply to the pedestrian crossing. This is becoming increasingly common at protected intersections, where the crosswalk across the bike path is not included in the signalized crossing.

Here's an example on Laurier St at Waller St in Ottawa. The pedestrians are standing in the absolute worst spot to wait for the light to change - this is common on bike paths that lack any height difference with the sidewalk. More recent designs usually have a 5-6 cm curb (with wheelchair ramp) to make the cycling path more obvious to pedestrians.
View attachment 708582

Northbound on Bathurst at Adelaide cyclists also have an unsignalized crossing of a signalized crosswalk, but in that case there's no northbound bike signal so there's less chance of cyclist confusion.
View attachment 708581

Thanks for the detailed response. Gives me some more background before emailing the city about it. Hamilton has a lot of signal changes going on right now with roads being transitioned to 2-way, LPIs becoming standard, and Cycle tracks with dedicated signals, so I'm sure the transportation department is busy and may not have time to re-think any details until someone mentions it.
 

Back
Top