Jump to content

RR503

Veteran Member
  • Posts

    3,108
  • Joined

  • Last visited

  • Days Won

    109

Everything posted by RR503

  1. Pretty much all of these issues boil down to "we'd need to run more trains to implement plan x." That isn't always true! Let's run through the common proposals: - / swap: you really should bump up service by 1-2tph given how popular the connection at Lex-63 has become with the , but you don't have to, and the running time differences btwn the two routes are like 1 minute. - CPW: again, you should increase service, but it's totally feasible without that. Assuming - 168 local, - BPB local, - 207 exp and - 205 exp, essentially swap and service levels for the CPW peaks (so s/b AM and n/b PM). The is about 10 mins shorter than the (comparing 59-EUC to 59-STL), but some of that is made up for by the fact that s relay and s don't. Either way, minimal changes in overall service-hours spent - Dekalb: all of the S. Brooklyn Manhattan Bridge routes have, to a first approximation, the same service profile in the Brooklyn peaks. So that's an easy one. Now for the harder ones: - 34 St: you basically need to add 7.5tph of service to make up for lost s. Some of the service-hours you need for that can come from the fact that 96 St is 11 mins closer to 34 than Astoria, but you'll end up spending money there. - Rogers: Peak hour service levels are close enough to the that you could probably get away with not adding service here, but the whole point of this investment is that the IRT express routes run well below need, especially for Brooklyn peaks and on the West Side. - Something more extensive in Queens: I think the need to add service when you do and to Astoria is pretty self evident? Also note: for most merges, you'll likely achieve some running time savings through merge elimination. Nothing earth shattering, but with knock on effects in reduced OT, dispatcher workload, switch maintenance...it's money!
  2. FWIW: in the world where we don't have 10 car s or an express station at 36 St, I think the best QBL deinterlining plan is the light touch / swap. Lex-63 is an awful place to merge services -- you're making a 34 St copy at the beginning of the 30+ tph QBL trunk -- and you can realize a good bit of reliability and speed benefits by fixing CPW and Dekalb while you wait.
  3. 179 is likely to be limited by the same problems that afflict Forest Hills: train clearing, and poor coordination of recrewings. It'll likely run a bit better because there's no diverging move immediately after the inbound platform (and CBTC is still something of an X factor in all of this) but we're talking about the difference between 20 and 22 or 23, not 20 and 30. Also: take those terminal capacity estimates with a (small) grain of salt. A lot of them look about right, but, for example, Utica sees hours where it turns 15tph on its two relay tracks. Really the best way to figure out this sort of question is to go and time train movements during peak hours...
  4. You actually do get sped up! The NTTs come programmed with two acceleration curves: the "cold curve" for use on fixed block portions of the system, and the "hot curve," for use in CBTC territory. During peak hours, you're going to be gaining as much from higher quality close-in operations as you are from faster speeds, but the difference is significant.
  5. To the curvature point: I think the precedent that most thoroughly puts the lie to the whole "curvature and length compromises OPTO" argument is Paris's RER. Many of its lines have been OPTO since the 1990s, and some run ten car trains of bilevel EMUs through stations which are packed and often quite curvy. Successful implementation obviously requires good investments in CCTV infrastructure (some of which the L already has), but it's really not impossible. (London's Thameslink is another good one)
  6. This is a good question. The reason s are sent up Culver is because the weakest link in the entire "everything up the wall after 7:30" GO is Dekalb. North of 36 St, there isn't any way of getting s and s back onto the express tracks, so you have a few hours every evening where the are all sharing A2 track through Dekalb Avenue station. That can get *quite* messy quite quickly, so reducing train volumes there is a must -- hence Culver. My big question about the via Culver, fwiw, is why those intervals don't run via B4 track. Sending them up the local -- which seems to be the norm -- seems a waste of time and money, to say nothing of delay around Church. Not going to touch the Wally proposal, because ✨self care summer✨
  7. This, IMO, speaks more to a need for advocates to get better at speaking the pols' language rather than just quitting. Totally agree that it's a hill (and a half) to climb, but there are some spots of hope in recent history. The way Oddo worked _in coalition_ with MTA to push the SI Exp redesign through, for example, seems a great precedent -- albeit one from a rather marginal political figure in the grand scheme of NYC politics. Anyway, my point in posting was more to inform the technical conversations.
  8. Gonna leave this here https://homesignalblog.wordpress.com/2021/06/15/deinterlining-some-quantitative-evidence/
  9. 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)
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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?
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...

Important Information

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