King Street (Streetcar Transit Priority)

[Rainforest]

Interesting question, are we more interested in increasing the speed of King streetcar, or in improving its consistency? Those are two related but not identical goals.

I would think that for short trips, consistency is more important than increased speed. Inconsistency causes bunching, and bunching can be self-maintaining because the leading car in the pair spends more times at stops and cannot restore the proper gap, at least not before it arrives to the terminus.

On the other hand, consistently low speed through a short central section will have only minor negative impact on the travel times, but will not cause bunching. All gaps will shrink as the streetcars enter the slow central section, and expand back to normal as they go past that section.

If so, then the interference from jaywalking pedestrians that force a consistently lower speed limit but do not hold any streetcar for long, is less of the problem than interference from cars that compete for the lane space.

 

[steveintoronto]

Interesting question, are we more interested in increasing the speed of King streetcar, or in improving its consistency? Those are two related but not identical goals.

This is a point that Steve Munro espouses, but I disagree on. Surprisingly, he's an engineer by training.

This involves what's called "turn-around time", and the faster the route travels (presuming the rest of the route permits, not just the King Corridor, and that's a safe assumption, as it's the corridor part that's claimed to be the 'bottleneck'), the sooner the same car is ready to 'refresh' its availability. Also throughput *is* increased, contrary to what Munro claims. (Think revolutions in an engine, and power v. torque, power is torque X speed) Munro states that unless more units are added, the waiting time is the major determinant of frequency of service. Again, I digress, although not completely. If more units are added, throughput and *potential* efficiency both increase even more.

*IF* the 'availability' of units is increased to the amount the rest of the route is capable of delivering, then yes, then for the same number of units, availability (inverse of wait time) is increased. So is efficiency, as it takes less time to complete the task. Increasing speed alone may not be the ultimate goal, but it's a good part of it, and if conditions exist to allow that increase in speed, the factors that cause bunching are also reduced.

A further point on 'turn-around time' and how the ends of the route can cause that to lag: That is *precisely* the cause d'etre of the 514, to increase the density, and thus 'availability' to the central part of the route. To model this mentally, visualize the ends not moving at all, but central portion is. This is the value of 'short-turning', although the modeling gets a little more complicated (mostly for the better) when start and finish points are from more places, presuming the insertion of units is quick and efficient. (The switching is smooth, fast and consistent)

 

[EastYorkTTCFan]

t's my preference that the tunnel under Queen be GO RER connected through each end to extant GO lines (Georgetown Corridor and Lakeshore West one end, Don Valley (Bala Sub) and Lakeshore East the other.

Um why would go tarist run a line underneath the streets of Toronto it makes much more sense for it to be a subway line.

 

[W. K. Lis]

This is a point that Steve Munro espouses, but I disagree on. Surprisingly, he's an engineer by training.

...

Steve Munro was a computer systems manager (retired). See link.

 

[steveintoronto]

Um why would go tarist run a line underneath the streets of Toronto it makes much more sense for it to be a subway line.

To get to the other side. Literally, so a transfer to the GO system isn't necessary. RER in through-running tunnels under city cores is now the preferred way of handling the loads, cheaper per passenger moved, vastly faster, more convenient for most and in Toronto's case, funded by the provincial government as part of the GO RER network. See East Side Access, Crossrail, Paris RER and many other examples to find out why. Huge amounts on-line about this, three examples:

https://en.wikipedia.org/wiki/Gateway_Program_(Northeast_Corridor)
http://blog.tstc.org/2015/07/08/thr...s-the-key-to-a-unified-regional-rail-network/
www.crossrail.co.uk/

Steve Munro was a computer systems manager (retired). See link.

He claimed to have an engineering background in one of his blogs a week or so back. That explains to an extent why the concept of revolutions per time wasn't fully understood by him. I should have stated it in bits per second.

 

[Rainforest]

This is a point that Steve Munro espouses, but I disagree on. Surprisingly, he's an engineer by training.

This involves what's called "turn-around time", and the faster the route travels (presuming the rest of the route permits, not just the King Corridor, and that's a safe assumption, as it's the corridor part that's claimed to be the 'bottleneck'), the sooner the same car is ready to 'refresh' its availability. Also throughput *is* increased, contrary to what Munro claims. (Think revolutions in an engine, and power v. torque, power is torque X speed) Munro states that unless more units are added, the waiting time is the major determinant of frequency of service. Again, I digress, although not completely. If more units are added, throughput and *potential* efficiency both increase even more.

*IF* the 'availability' of units is increased to the amount the rest of the route is capable of delivering, then yes, then for the same number of units, availability (inverse of wait time) is increased. So is efficiency, as it takes less time to complete the task. Increasing speed alone may not be the ultimate goal, but it's a good part of it, and if conditions exist to allow that increase in speed, the factors that cause bunching are also reduced.

1) I feel that both him and you are right, and the disagreement was mostly about definitions. If we find a way to accelerate the route, then indeed each car completes the two-way run sooner and is available for the next run sooner. If this translates into more frequent service, then the throughput will increase.

On the other hand, if the frequency is limited by factors other than the car availability (such as traffic light cycles), then the faster service will not change the throughput (although still useful as the labor costs will go down).

Note that the effect will be small if the improvements affect only a short section of the whole route.

Say if the route is 15 km in length and runs at 15 kph, then each round-trip takes 120 min. If we manage to accelerate the whole route to 20 kph, the round trip will take 90 min; that's a 33% increase in frequency, or a 25% reduction in labor costs.

Now let's consider a route that makes 10 kph in the congested central 3 km, and 15 kph in the remaining 12 km. The round-trip takes 132 min. If we improve the speed in the central section from 10 to 15 kph, and make no changes elsewhere, we get the round trip down to 120 min. That's a 10% difference only for the whole round-trip.

2) There is no definite correllation between higher speed and lower occurence of bunching.

That's why I am thinking that bunching might be worse than low speed that's consistently low. The bunching may begin in the congested short 3-km section, but then the pair of cars will travel along the whole route, resulting in overcrowded first car and barely used second car. The average frequency may be almost unchanged, but the the wait time for the unlicky riders will increase almost by a factor of 2.

 

[steveintoronto]

2) There is no definite correllation between higher speed and lower occurence of bunching.

Good analysis, but there's certainly an *indirect one* as they share (mostly) the same factors working for or against. Bunching is most often the consequence of congestion on a line that doesn't have controlled traffic (by that I mean dispatch control interval). This brings in the 'short-turn' factors, which aren't as corrective as some would believe. It's like patching ripped jeans, it just moves the tear in the fabric.

The question is whether traffic control on the line will exist for this project or not. Whether the communications data system is fully upgraded on the ALRVs and CLRVs is a good question. Due to impending withdrawal of the stock, I suspect not. I think time is ticking on the analog radio communications and the Rogers analog network it operates on.

I know some streetcars use proximity transponders for the Presto readers to determine geo-positioning, whether any dispatch info is piggybacked on that I don't know. The Flexities would be equipped with the next generation of system that could and would.

Edit to Add: Just got a chance to delve on literature related to "bunching". Here's a good synopsis:

[...]
In public transport, bus bunching, clumping, convoying, or platooning refers to a group of two or more transit vehicles (such as buses or trains), which were scheduled to be evenly spaced running along the same route, instead running in the same place at the same time. This occurs when at least one of the vehicles is unable to keep to its schedule and therefore ends up in the same location as one or more other vehicles of the same route at the same time. [...]

https://en.wikipedia.org/wiki/Bus_bunching

"unable to keep to its schedule" = Mostly due to *congestion* in the case of the King Corridor.

Article continues:

[...]
Corrective measures
When a transit vehicle becomes overcrowded as well as delayed, the transit operator may choose to designate the vehicle as a temporary "express" trip. This means that the expedited vehicle will bypass many of its usual stops, operating on a limited stop basis, or heading non-stop directly to the route terminus. This usually entails some additional delay, needed to notify passengers already on board, and to let some of them to disembark to avoid being taken past their intended destinations.
[...]
Other corrective measures include adding more vehicle trips or higher-capacity equipment. Aside from possible extra costs, the chief difficulty is in responding quickly enough to delays and overcrowding before they spontaneously dissipate. It is preferable to closely monitor transit headways and take immediate corrective measures, rather than allowing delays to "snowball", causing a near-complete breakdown of service.

Clumping can be prevented or reduced as follows:

• Scheduling minimum and maximum amounts of time at each stop[3]
• Scheduling some crowded runs to skip certain stops[2]
• If, on a popular route with frequent service, a crowded vehicle arrives, passengers can be urged to wait for the next vehicle, which may be less crowded[2]

A different approach is to abandon the idea of a schedule and keep buses equally spaced by strategically delaying them at designated stops.[5] This is used to control the buses on the campus of Georgia Institute of Technology, where it outperforms the previously scheduled system.

More efficient on-board fare collection, or preferably prepaid fare collection can reduce dwell time at stops and greatly speed up service. Multiple-door, level-boarding setups can also greatly reduce stop durations, as demonstrated by the best Bus Rapid Transit (BRT) services.

Heavy ridership caused by special events (such as sporting events, large concerts, inaugurations, or holiday celebrations) is even more likely to cause problems with bunching and delays. Extra service may be added, and special rules (such as waiving of fare collection) may be used to improve service.

Merely adding more vehicles to the schedule without making other changes has been proven not to be a reliable solution to the problem of bunching.[3]

https://en.wikipedia.org/wiki/Bus_bunching

Late Edit: Just scanning through some of the excellent references to that article, and it occurred to me one of the *massive* problems of both this pilot as planned, and long-term success or not of the project (and other posters have already raised this, it has immense bearing on 'bunching'): Unfavourable traffic lights! It will come as no surprise to some that one of the largest foils for making this work will be the lack of traffic light prioritization. Perhaps a compromise could be configured that lights are left to their own rhythms to change until TTC control is necessary to intervene due to schedule glitching? Then priority is assigned to the streetcars until normal line flow is restored. Frankly, it should be fixed full time, but that would be too radical for Council.

But the big bugaboo remains the lack of data communication and cross-connected systems traffic and road sensing systems, and what some papers refer to as "positive feedback"...which is in fact completely wrong. A servo loop is *negative feedback*, but I digress. Neg fdbk senses and controls to restore a stable norm, like a thermostat. The best the TTC can do w/o the data systems is station an inspector or spotter at every intersection to feed info by walkie-talkie (or digital input via an iPhone) to whomever/whatever controls the traffic lights.

And they want to give exceptions to taxis? (Even partial time of day exceptions) Tell you what, every councillor who votes for an exception should serve duty at those intersections to enter data to correct the anomalies as they occur. That'll knock some sense into them. (Conditional on their having the mental capacity to begin with)

 

[aquateam]

Increasing speed would increase frequency... if the same number of operators/vehicles was used and schedules were modified to account for the faster speeds.

The real-world impact of speed increases might not be as beneficial as this though, if it just results in more layover time or if the TTC uses it as a way to cut costs by using fewer vehicles. Or if there is some delay and the faster vehicles just catch up to the delayed one in order to bunch sooner.

I think a schedule-based system is a mistake, especially when streetcars run so frequently. A headway-based system, where each operator has an indication of how much faster/slower than the car in front/behind and consequently whether they need to speed up/dwell longer would be a better way of managing the route. If an operator is running more than headway behind the car in front of them, they should be able to request additional signal priority at lights to speed up. None of this would be technically difficulty to implement.

 

[JasonParis]

Regarding the Toronto Transit file - its not fair to shift blame on the Fords. They were consistent and clear on wanting subways but failed to convince others. We can all agree that great cities deserve subways.

Dangling it out there for votes, but then not coming up with any consistent or clear ways to pay for them? Moreover, they were completely politicizing the process and arguing for subways where they were the least needed and often wouldn't even help the people they were saying it would.

 

[steveintoronto]

A headway-based system, where each operator has an indication of how much faster/slower than the car in front/behind and consequently whether they need to speed up/dwell longer would be a better way of managing the route. If an operator is running more than headway behind the car in front of them, they should be able to request additional signal priority at lights to speed up. None of this would be technically difficulty to implement.

If the systems are in place on the UTDC stock, and controls interfaced with the traffic lights. Where is this done at present in Toronto, and how?

The new configuration has the potential to force streetcars to stop twice at each intersection — once on the near side if the car encounters a red light, and again at the far side to pick up riders. Gulati said the possibility of installing transit-priority traffic lights was “under review.”

https://www.thestar.com/news/gta/20...k-seat-in-proposed-king-st-pilot-project.html

No time to search right now, anyone have more on that? It's an absolutely crucial point when the likes of Minnan-Wong demand (gist...I can't remember his catch-phrase) 'benchmarks of progress' on a trial already hobbled by compromise and weasel words.

 

[reaperexpress]

If the systems are in place on the UTDC stock, and controls interfaced with the traffic lights. Where is this done at present in Toronto, and how?

https://www.thestar.com/news/gta/20...k-seat-in-proposed-king-st-pilot-project.html

The new configuration has the potential to force streetcars to stop twice at each intersection — once on the near side if the car encounters a red light, and again at the far side to pick up riders. Gulati said the possibility of installing transit-priority traffic lights was “under review.”

No time to search right now, anyone have more on that? It's an absolutely crucial point when the likes of Minnan-Wong demand (gist...I can't remember his catch-phrase) 'benchmarks of progress' on a trial already hobbled by compromise and weasel words.

There are currently about 350 intersections in the City equipped with Transit Signal Priority mostly along downtown streetcar routes. The City's Open Data lists the signals which are equipped with some form of transit action, but unfortunately it doesn't say what each signal is allowed to do. In some cases, streetcars get very strong priority to the point that they are pretty much guaranteed a green (for example Queens Quay & The Crossover, St. Clair & Ferndale, Spadina & Russel, Lakeshore & Humber Loop), while on the other extreme the transit detection may be just to insert a transit phase without actually making any effort to make said phase occur any time soon (Queens Quay & Dan Leckie for example).

According to mirasan.ca (which displays the City's Open Data) here's the priority status for the signals along King pilot area.

Some form of Signal Priority
Bathurst, Portland, Spadina*, Peter, John, Simcoe, York, Church, Jarvis

No signal priority
[Spadina*], University, Bay, Yonge

*King & Spadina is listed as having Transit Priority in the open data because streetcars turning off Spadina (i.e. during a 501 diversion) can insert a streetcar turning phase. There is no priority for King.

They are not investigating "installing" transit-priority along King. Transit Priority is already installed and operating at most signals within the pilot area. The investigation is about whether they should disable the existing system, or update the programming to reflect the changed stop locations (moving the stops to far side changes the travel time within the detection zone, so the estimated arrival times need to be updated to reflect that).
My guess is that Jacquelyn H-G said something like "we are investigating having Transit Priority", and the Star misinterpreted that to mean that it would be installed, as opposed to simply not abandoning the equipment that is already installed.

The reason the current priority doesn't work that well is that it is not possible to effectively predict when streetcars will wish to proceed through the intersection. Mostly this is due to the near-side stops, which introduce a vast spread of possible travel times through the transit detection zone approaching the signal. So sometimes streetcars spend less time at the signal than estimated, so they're ready to go earlier than the system expects (and so it does nothing), while in other cases streetcars spend more time than expected, in which case the system holds the signal green until its maximum allowable amount, but even then the streetcar is still not ready to go. In this case, the 'priority' system has actually increased the delay to the streetcar because the next green will start later than it would have normally. Relocating the stops to the far-side of the intersections as planned would allow the priority to be more reliably effective than today, since it would become possible predict streetcars' arrival time at the intersection to within a couple seconds. But we can only get that benefit if the City allows the TTC to adjust its priority equipment to reflect the new conditions, rather than insisting it be disabled.

I think a schedule-based system is a mistake, especially when streetcars run so frequently. A headway-based system, where each operator has an indication of how much faster/slower than the car in front/behind and consequently whether they need to speed up/dwell longer would be a better way of managing the route. If an operator is running more than headway behind the car in front of them, they should be able to request additional signal priority at lights to speed up. None of this would be technically difficulty to implement.

It would be pretty simple to get the signals to only provide priority to streetcars which are operating above the scheduled headway, by keeping a record of when the last streetcar passed by in each direction. But the problem on King Street is that there are 3 different streetcar routes, which all have different headways. So we may not necessarily want the streetcar service to be perfectly even within the pilot area.

In the longer term, when ridership has grown along Cherry Street and the 504 is fully-equipped with Flexities, I wonder if we could equalize the frequencies on the 514 and the 504 to provide a blended alternating service along King Street.

 

[steveintoronto]

The reason the current priority doesn't work that well is that it is not possible to effectively predict when streetcars will wish to proceed through the intersection.

Excellent details. It appears (although haven't had time to ponder and research yet) that any priority is in a fixed frame of recurring sequence, much like a pedestrian cross request at an intersection.

Without a dynamic multi-input system, I see this being programmed for mediocre results at best. Just as Minnan-Wong likes, so it becomes a self-fulfilling prophecy to not outperform. More comment later when I can study this.

Many thanks.

 

[reaperexpress]

Excellent details. It appears (although haven't had time to ponder and research yet) that any priority is in a fixed frame of recurring sequence, much like a pedestrian cross request at an intersection.

Without a dynamic multi-input system, I see this being programmed for mediocre results at best. Just as Minnan-Wong likes, so it becomes a self-fulfilling prophecy to not outperform. More comment later when I can study this.

Many thanks.

Sorry, what do you mean by a 'fixed frame of recurring sequence'? And 'dynamic multi-input system'?

If you're doing research on effective signal priority, I recommend starting with presentations by professor Peter Furth of Northeastern University. He's spent some time in the Netherlands learning how to design signal operations from a transit-first perspective. This is in contrast to the American version of Transit Signal Priority, which is to make very minor adjustments to the car-based signal timings to make them suck slightly less for transit.

Here's a paper on conditional priority (based on schedule adherence in this case, due to the lower frequencies involved):
http://www1.coe.neu.edu/~pfurth/Furth papers/2000 Conditional priority, Furth & Muller TRR.pdf

 

[dowlingm]

I may have missed this previously, but I assume the navy blue private shuttle along King St I see at PM rush is gone too when pilot happens?

 

[steveintoronto]

Sorry, what do you mean by a 'fixed frame of recurring sequence'? And 'dynamic multi-input system'?

I'm using general phrases for any batch processing.

What the City now has (at least for King Street) is a *fixed time frame sequence* as best as I can gather, the intersection signal times are fixed in duration, with any 'priority; having to be a further time division within that fixed parameter. Not considering other dynamic and real-time needs.

Best I quote Munro:

This pilot is a big change from the more timid approach to traffic management we usually see in Toronto. There is only so much to be achieved by tweaking traffic signal timings and adjusting regulated hours for parking and left turns. At some point, the more fundamental discussion – who is the road space for – must come forward.

[Full disclosure: I have worked on aspects of this project both on a paid and a pro bono basis providing analyses of TTC vehicle movements.]

https://stevemunro.ca/2017/06/12/king-street-redesign-project-goes-to-ttccity-for-approval/

I'll try and find the City's actual details and methodology for their King pilot area intersections. There may be magnetic loop sensors that have some input, whether that is time division within fixed frames or actually a dynamic elasticity to stretch and shrink those frames on an input sensing basis is a good question, and layered on that: What input does the TTC now have save for a priority (keyed or not) in the light sequence?

Let me project farther from that: To affect optimal flow and efficiency of the King streetcars will necessitate *over-riding* entire assigned sequences at intersections. This may only be needed for the occasional need to get an interrupted or otherwise out of synch King schedule/headway/interval back onto what is deemed 'optimal'. That would be a dynamic correction, and it adds another depth of control to otherwise limited proactive abilities on King at present, or during the pilot.

Let me quote Wiki, since I might be using more general engineering terms (and I wasn't far off)

[...]
Fixed time control


Pedestrian traffic signal in Taiwan, featuring a "Walking green man" below a countdown display where the "Red Man" once stood.
In traffic control, simple and old forms of signal controllers are what are known as electro-mechanical signal controllers. Unlike computerized signal controllers, electro-mechanical signal controllers are mainly composed of movable parts (cams, dials, and shafts) that control signals that are wired to them correctly. Aside from movable parts, electrical relays are also used. In general, electro-mechanical signal controllers use dial timers that have fixed, signalized intersection time plans. Cycle lengths of signalized intersections are determined by small gears that are located within dial timers. Cycle gears, as they are commonly known, range from 35 seconds to 120 seconds. If a cycle gear in a dial timer results in a failure, it can be replaced with another cycle gear that would be appropriate to use. Since a dial timer has only one signalized intersection time plan, it can control phases at a signalized intersection in only one way. Many old signalized intersections still use electro-mechanical signal controllers, and signals that are controlled by them are effective in one way grids where it is often possible to coordinate the signals to the posted speed limit. They are however disadvantageous when the signal timing of an intersection would benefit from being adapted to the dominant flows changing over the time of the day.[7]

Dynamic control
See also: Traffic signal preemption
The controller uses input from detectors, which are sensors that inform the controller processor whether vehicles or other road users are present, to adjust signal timing and phasing within the limits set by the controller's programming. It can give more time to an intersection approach that is experiencing heavy traffic, or shorten or even skip a phase that has little or no traffic waiting for a green light. Detectors can be grouped into three classes: in-pavement detectors, non-intrusive detectors, and detection for non-motorized road users.

[...]

https://en.wikipedia.org/wiki/Traffic_light_control_and_coordination

I leave it at that until I can get more info on what is extant and what is needed to bring this pilot into the here and now...