Jump to content

Attention: In order to reply to messages, create topics, have access to other features of the community you must sign up for an account.


Veteran Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by RR503

  1. Great post, TM5. Despite all the signal mods made since your time, the "don't risk flying into a red home @ 108-ball" is still the cause of much slowing at the Astor Curve. If I may make one little correction, though: the "C" signs are now gone, and if you're operating totally textbook you're good for MAS from the "R10" sign beyond the curve leaving BB to the 35mph sign entering Spring, and then from when clear of those curves to wherever you choose to slow for Astor (there is no sign there, so you're not technically doing anything wrong if you go MAS)
  2. This is how it's operating *now*, not how it's planned to operate forever. AWS on QBL will not support much more than a 5 min headway (like the ), speeds will increase, etc. And FWIW, the did tons of off peak section-level testing until full cutover -- not unlike the overnight periods seen on QBL. There wasn't such an extended mingling period, yes, but it wasn't a hard transition either.
  3. Amusingly, some on that list were ones from years ago (ex: the and changes mentioned). They've made new changes, but for whatever reason decided to highlight old ones.
  4. Not to state the obvious here, but: congestion pricing is most fundamentally a means of internalizing an externality. When car n + 1 enters the Manhattan highway network, it imposes costs on other drivers (congestion) and society (increased traffic accidents, emissions, road wear), which it does not have to pay for. Extremely for this serving broader goals of road capacity and VMT reduction -- which are critical to keeping Manhattan, much less the Rockaways above sea level by the end of the century -- but you need not go far beyond basic economics to prove the worth of the cordon pricing scheme.
  5. I think modern day transit planners are all too aware of the dangers associated with interlining. Just because we don’t hear deinterlining proposals doesn’t mean that the agency doesn’t want them — politics are a critically important mediating force here. And at any rate “this is how it’s always been done” =/= “this is how it should be done,” with the qualification that you need to be cognizant of adaptive infrastructure changes when shifting paradigms.
  6. Yeah, all credit to Vanshnook for that idea (which is great and I still support) I see the fundamental issue with SAS 3/4 as being that they cement interlining across the entire B division and don't actually add any core capacity. Any comprehensive route simplification scheme requires routing the to 96; there is not space for the and to run up SAS today at full service levels. Similarly, there is no way to fill lower SAS (assuming continues to upper SAS) without interlining a train onto 63 St -- which blocks an reroute there. This is all a fancy way of making the capacity point. Today, there are 6 B division track pairs in Manhattan's core (8th local/express, Bway local/express, 6th local/express), and 6 track pairs leaving the core to the north (CPW local/express, 53, 60, 63, SAS). Thus, any addition of capacity in the core without addition of other northern routes constitutes a redistribution of capacity away from tracks which already exist -- this is what SAS does today. I have yet to find a fix for this problem which I really love, but I think it's fair to say that as proposed, SAS 3/4 have low-to-negative network ops value.
  7. You only need that flexibility when you make major fleet planning mistakes. Shortages of late have been the result of the aberrantly tortured introduction of the R179 class in conjunction with the R44's early retirement. Better planning and better contract management can make up much of the difference here -- and what it can't can be solved by relinking sets if you absolutely must. As the saying goes, organization > electronics > concrete.
  8. I wish I knew. I imagine the 255s are being spec'd with provisions for conversion given that the 156s were, but not sure whether we have firm info on that front. @Union Tpke?
  9. Yeah, I think the most likely outcome is that they just use the 160 seated capacity figure for the 211s as if there's no difference. Point being: there may be peak cuts, but I would be quite surprised to see the 211s causing off-peak reductions.
  10. Worth noting that while the additional square footage is going to mean R211s will have more peak capacity than previous fleets, the reduced seating capacity (bc wider doors) should actually net out to increased headways based on a strict interpretation of NYCT loading guidelines. Whereas peak service is calculated on a seated capacity + passengers/available sq ft basis, off peak service is adjusted up from 10 min headways where loads exceed seating capacity +25%, a figure which will be lower on the 211s than on (say) the 160s.
  11. I think you're overestimating the degree to which the is a flexible operation. It just has a really complicated schedule! Here's a string chart of scheduled southbound 5 service in the AM and PM rushes. Utica, Bowling Green and Flatbush all get trains, and there's not much of a pattern to it (or rather, the pattern is difficult to see without looking at schedules simultaneously). Changing a train's terminal can be done, but is avoided wherever possible. Remember, most of transit service management is crew management rather than equipment management. A train is a train and can basically run wherever you want whenever you want it, but moving crews around a lot can rapidly lead to service issues as the fabric of the timetable comes apart and you end up with intervals on the stand with no available crew to take the train out, crews missing lunches, crews deadheading everywhere, or the like. There are ways to deal with these things, but there's a reason we have timetables and work programs, and it's not to generate performance metrics.
  12. The runs every 20 on 2 Av when they need to do single tracking. A shuttle will not help there, for obvious reasons. There are some rush hour trips to/from 96 to provide additional service to the corridor + to slightly reduce the load on 60 St and Astoria. It's a common rerouting terminal as well (for everything, really), so it may be you saw an incident diversion.
  13. As a general rule, I try to stay out of rolling stock discussions on here, but some quick points: - Having married pairs or single units actually decreases reliability. Because you can't spread systems across the set, and because you have more coupling points, you end up with significant duplication and more points of failure. In isolation, the flexibility is nice, but NYCT's experience with the fleet in recent years -- to say nothing of the experiences of other countries -- should vindicate the perspectives of those who see linked sets as the way to go here. - The "more capacity" point is one that I think is getting too little stress here. More standing room/car will obviously help smooth peaks, but OGs likely will also shorten dwells. If you're more able to move throughout the train, the chronic end-loading seen on some lines should moderate. Even if this affect is only slight, it counts for something.
  14. It's about 10 minutes slower to go via tunnel from Canal to Dekalb. That's a 20 minutes of additional train cycle time, which means you need as many as two additional equipment sets (and crews) to run service, assuming 10 min headways. That's real $$$, to say nothing of real time losses for riders. The added merges are annoying and certainly do contribute to this system's chronic weekend reliability issues, but I think they made the right choice. Not necessarily. You could have run the plan they have now ( to Delancey, to Brooklyn via Cranberry) with the swap taking place at West 4 rather than at 36 St. Two issues, though: - A W4 swap would have created a relatively complex junction operation there. On 8th local, you'd have s, s and s all trading places. At 5tph apiece, it's certainly possible to schedule this to work, but weekend junction ops need to be basically bulletproof given the generally variable operating environment + NYCT's reluctance to trust operators to punch correctly when operating GO routes. This latter problem is, in fact, one which disadvantages this service plan above and beyond the potential for delay: GOs which require diverges northbound at W4 generally are staffed with a 'spotter' whose job it is to confirm train identities to Tw/Os who then issue routes. - 8th Avenue CBTC is already creating a number of GOs, which would further complicate the W4 operation. On weekends where s are local, you'd be dealing with an additional 6tph through the merge at W4. On weekends when the local is out of service, you'd have to compose some alternate service plan, as neither A3 nor A4 track has direct access to 6th Avenue at W4. So to make the service plan more resilient to GOs, it's better to swap at 36.
  15. Sorta. If you lose comms between ATS and the interlocking, you'll lose your fleeted routes => all signals within interlocking limits will drop to red, compromising the railroad. This is exceedingly rare. The fix is to man each tower, which requires a) qualified TSSes and Tw/Os to be present and b) for them to know what they're doing. Twice monthly versus a few times per decade is probably a more accurate comparison of the risks that you get caught up in x type of signal failure, once CBTC is fully cut in on a line. As bulk88 notes, it's really quite a reliable system. To the broader point: thank you for illustrating how mediocre institutional ops competency increases capital costs! Don't design for bad organizational practices. Fix those, and design your system to a higher standard. And regardless, the primary reason NYCT designs auxiliary waysides is for work train movements, not CBTC failure recovery. Equipping work trains is a solved problem, and is something we should absolutely be aiming to do in the medium term.
  16. On the and QB, there exist auxiliary wayside signals which allow some basic service to be run when CBTC is down, or when you have non-equipped trains. The 's allow about a 10-12 min headway, the 's and QB's allow about a 5. Thing is, those waysides are expensive to install and maintain, and really aren't that useful if CBTC shits the bed in the middle of rush hour -- it's not like you can magically thin out and service by 60% to make service operable with AWS. So, IMO at least, they really should be engineered out of future designs. CBTC failures are operationally catastrophic but exceedingly rare, and actually the additional complexity introduced by auxiliary waysides can reduce overall system reliability. Everything is about tradeoffs, and the one most well-operated subway systems make is cheaper/more simple signals with fewer backups.
  17. Normatively, we should be able to turn up to 15 tph on a single pocket -- HY does 29 on two, after all. However, the slow entrance speeds at Whitehall + the inconvenience of the narrow platforms for crew movements + the operations risk that comes with a single point of failure on that high frequency of a pipeline means we don't and probably shouldn't. The , fwiw, maxes out at 6tph turning. Some of that is a function of upstream scheduling constraints that make it impossible to take turn headways down from, say, 10 to 8, but some of it is just the limitations of the operation there. And even now, that terminal operation sucks.
  18. And you're going to put the 120ish trains you just took out of service where, exactly? Politics aside, the fact of the matter is that NYCT was not _designed_ to be closed overnight. Doing so would mean an immense number of mainline layups, whose placement would entail significant disruptions to evening service and cost. I actually doubt that an overnight closure would actually net out to less $$$ than running service.
  19. The overwhelming majority of research on transit demand shows frequency being hugely more determinative of ridership than the size or shape of transit vehicles. Reliability is indeed important, but the is a generally well-run route, and its schedule could actually become much more regular if it ran at frequencies closer to those of the ; the 8tph of peak service has to be slotted in between 11-12tph of , making for uneven scheduled headways.
  20. Because of the >300'/two person crews rule, adding cars comes at a nontrivial cost (at least for weekend service). One important fact to keep in mind here is that riders have the highest transfer propensity of any non-shuttle route, so wait times between trains matter disproportionately much. I'd strongly suggest starting with service increases because of this (and Court Square can handle 15tph, so not an issue for a while yet).
  21. I too would love more weekend service, but with current flagging and junction operation practices it's ~impossible to regularly schedule more than 15-16 tph (B div) or 17-18tph (A div) per trunk on weekends. Whenever it is that we make some progress on those fronts, I would first bump frequencies on existing services rather than add more. Two infrequent services doing slightly different things is, generally, less helpful from a network perspective than a single, high-qual service.
  22. There are real long term maintenance savings, too. There'd be more if we were less into AWS overlay, but it's still nontrivial.
  23. A lot of the Gun Hilling has to do with congestion around Nereid. Discharging s on the mainline can get nasty, especially if the railroad is already running behind or bunched. It's a tradeoff, but putting those s up the middle and discharging at Gun Hill does prevent delays for riders later on -- whether they be people on northbound s who'd get bogged down waiting for the to clear, or people waiting for a southbound late out of the terminal because it got delayed by discharging s.
  24. Towards Canarsie has dense AWS to support non-equipped mvmts to and from the wash at Canarsie Yard. Towards 8th Avenue has AWS, but the AWS there is low qual -- during Canarise Tube work, a work train north of BWJ => 20 min headway. (Just to be clear, I do not endorse more AWS. Less AWS is actually better for CBTC reliability and lifetime maintenance costs; we should just equip our work trains)
  25. The supplement that was lifted was one which thinned out the pre-CBTC 27 to 25, IIRC, to support switch work. Net increase was 27 => 29. FWIW, the way the pre-CBTC schedule worked (going back at least to 2003, if not earlier) was alternating 120 and 150 second headways, making for an average headway of 135 seconds, or 27tph. I would give it a few weeks/months before coming to any conclusions about the status and direction of the QBL cutover. What's going on at the moment is just that -- a cutover! There have, to my knowledge, not been any changes to the end plan.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.