RR503

Trying to imagine running express-on-local with the 's tendency to run pairwise during PM rushes...

As mentioned in my post, there are provisions that exist for switches south of 36 — you’d use that. 38th would certainly help facilitate an Astoria-Bay Ridge , but the merge interaction creates between yard runs and s presents a non trivial constraint in service. Whether or not that justifies a different service pattern is somewhat a subjective question given our inability to quantify the issue, but it’s definitely worth considering. Also would be interested to know how much space we could get in 38th, what with MOW’s presence always expanding. West End riders would certainly not like losing direct Bridge access, but this isn’t something where they just lose. 2-3 minute peak headways would be appreciated by riders, as would the potential for express service. Part of the reason that this plan has some merit is because you can create this very tradeoff: they lose bridge access, but they gain something else. And as noted above, this is just adding a cross platform transfer.

There’s one in the pipeline, IINM. Unsure whether it’ll be made public.

This report, which came out yesterday, has some really interesting discussion of a lot of the issues we've discussed here previously. Highly recommend giving it a read. https://new.mta.info/sites/default/files/2019-12/MTA NYCT Subway Speed and Capacity Review_Final Report.pdf Some key takeaways in my eyes: - NYCT acknowledges the operational issues at Nostrand/142/149, and acknowledges the need to make investments/routing changes - NYCT acknowledges R68 propulsion issues (and also gives a bunch of really interesting data on pre- and post-field shunting elimination acceleration profiles for various car classes) - Lots of good stuff on timer/speed sign visibility - Disappointing lack of analysis of dwell time issues and off peak service problems - Super interesting applications of axle counters to shorten fixed dwells at force and lock controlled interlockings

With you up to the extension. I totally agree that Bay Ridge needs more service, but unless we can demonstrate that would, say, reduce crowding significantly, I'd prefer a conflict-eliminating extension rather than a conflict-creating . One interesting suggestion I've seen is using the switch provisions south of 36th to route express trains to Bay Ridge, with all locals to West End. You'd get rid of 4th Express-Bridge service to West End, but would make up for the loss in massively increased service frequencies and a simpler, less geometrically fraught merge at 36 St. This'd also provide you with the frequency required to do some sort of West End express from 9th to Bay Parkway, provided you work out the scheduling and switch issues there (don't want another Parkchester!). I personally prioritize getting rid of operations through the 11 St cut out of proportion to that track's service impact because getting rid of it allows you to unlock the full potential of 63, and thus increase capacity to Queens by ~15tph. Would keep that proposal. Perhaps the point here is minimum impact, but I'd _strongly_ caution you against not deinterlining 59/creating a 59-esque situation at 36 St. 59 is undoubtedly among the hardest merges in the system to operate -- so much so that it's the point from which the entire IND is scheduled. 36 St, which would essentially be 59 St but with a lot more trains, would promise to be an ops disaster if 59 is any guide. Given that CPW can be done with a max addition of a cross platform xfer, and that doing a 59 pattern in Queens also likely would add to express loads given destination parity btwn expresses and locals, I really think a 53/63 exp/local pairing is the way to go.

I make them with a friend's code in R, the free stats software. DM me if you're interested in a copy.

Scheduled throughput southbound at 59 St (where trains enter the CBD), see the 8-9AM time slot: I think you're creating a false dichotomy here. Systems knowledge is good. Data and reports are also good, and are completely necessary to ensure that issues of perception are countervailed appropriately. What NYCT needs and currently lacks is a structure that has the critical thinking skills and system knowledge to quickly identify service issues, but also the analytical capabilities to place that issue in systemic context, avoiding the previously common problem where, euh, attentive supervisors just made changes to their home lines external to system process. FWIW, I think it's worth complicating the "they did all these things and service got...worse" narrative. Most of the runtime increase you observe came to pass to combat some very real safety deficiencies in the signal system. Some of the finer points of that issue are certainly worth debating -- whether we should have spent the money to add signals to combat capacity losses, whether we should have spent more to properly mod interlocking areas, etc -- but I certainly don't think seeing that slowdown as an endogenous process is totally right. There are a TON of areas where NYCT could improve/has been regressing, but the causations behind those issues aren't just "we need to be a lot better at system management/managerial culture" (which we do, but you get my point).

What is this “obvious solution” you speak of? To me, the obvious in the case of the individually is just improving current service given the self-evident flaws of skip stop on a line with significant intra-corridor ridership, the operational issues with running an express via M track, and the fact that a few simple fixes in the 125-161 stretch could save Jerome riders significant amounts of time. As for the travel demographics of Concourse/Jerome in general, the actual destinations of real commuters on the line are a lot more central in midtown than one would imagine given the bias of corridor ridership. This should indicate two things to us armchair analysts: the do a disproportionately poor job of serving core-bound corridor riders, and that the greatest benefit to corridor riders who are traveling beyond the Bronx (ie the folks that this would target) would likely come from service expansions on the IND, given its centrality to Midtown destinations and access to midtown crosstown service in the at 7/53. Things like bumping service on the from 15 to 20tph, reviewing service patterns at the 59 St interlocking, and perhaps considering adds to the (which also peak at 15tph combined southbound) to increase network-level gains for Concourse/Jerome riders are all operationally neutral or positive interventions that would, ya know, serve real markets. And all of this could be furthered with station access interventions, whether that be reopening closed entrances or modifying bus service to help people move around the Concourse/Jerome corridor’s many hills. Pie in the sky? Perhaps. A set of investments that would see extremely high returns on a network scale if implemented? Absolutely. The runtime graphs I posted a page or two ago are collected from actual trains; that’s how long things take today.

On high density corridors like the Lex, words do not describe how better of a fit subways are than buses. Thank GOD we built them. Interlining 125/Lex would be Dekalb but with more merge delays and more capacity loss all to save people *checks notes* A cross platform transfer. Please, dear god, no. This is like basic level operations analysis: merges along high ridership/throughput corridors should be minimized.

As an option, sure, but it would be....VERY unfun to operate. You’d basically be replicating Dekalb Avenue, just this time at higher throughputs next to a high dwell station on a corridor that is inarguably is the most essential to the function of the subway. A recipe for operational paralysis, in other words. I think it’s best to learn to manage dwell times at 125 (and across the corridor as a whole) better.

The other issue here that I noted before is that running an express from Burnside to 149 would mean trains scheduled on a 4 minute headway from Burnside would end up at 149 almost at the exact same time, mucking up the merge between each other/them with the . You could schedule unevenly in the north, but then one will be riding the other’s tail through a meh signal system down from Woodlawn, or extend the express segment further north but then risk making the express catchment exceedingly small.

It's more like 30mins from Mosholu to 125 during the peak. (Both below charts generated using realtime data, so all runtimes are real trains) ...but the area in which trains are losing the most time rel. to the baseline midday runtime is the 161-125, ie the portion of the route where express service will help the least. 80/20 rule would suggest better operating the merge there, better controlling dwell times and adjusting speed restrictions esp. now that that area is in the queue for CBTC is the best way to improve Jerome rider experience.

Sorry. You'd either have n/b trains skip 135, or you'd rebuild 135 to a 3 track/2 platform station with s in the middle, or you'd just all out grade separate the area potentially using the middle track as someone else suggested.

Would be nice for connectivity, I guess, but would slam the even moreso than today. Dunno if it should be pursued. I think that's exactly what should be done, but only after runtimes are stable (ie no more SPEED projects in the pipeline). I also think that the scheduled runtimes should be somewhat more aggressive than they are today so that the incentive to run a tight ship is maximized. Unsure. I think some definitely do, it's just that a lot of mx activity happens during the peak.

Eh. If we kept some 32s/cut out some of the ridiculous runtime adds implemented in peak hour schedules, we may have. Foreign systems also have much lower spare factors than do we largely because their car maintainers work overnight rather than during the peak, a practice whose adoption could free up a significant portion of the fleet for service.

Classic. That area is scheduled like garbage too -- they fully have s and s going through within 30s of each other. I think the could help a lot -- it has cross platform transfers with the and into Midtown, after all. Just a question of getting everybody's frequencies to a level at which CPW is attractive.

The is so bad during rushes that a significant number of people ride to Tremont or Fordham and then cross over to the downtown for access to local stops. That's...embarrassing. On the point of loading guidelines more broadly, they're an objectively terrible way of structuring service. In a networked system, the interactions between lines make things like transfer times and turnover and network load balance equally salient variables even to cost considerations (not that we should be structuring service around costs alone, but to speak the language of the agency...) as is crowding. Routes that have high turnover -- like the -- should get more service as a reduction in their headway shortens transfers of more high-density trip types, making them more attractive and increasing revenue proportionally more, etc.

- The issues at Union Square are equally bad in both directions. S/b it's gap fillers causing long dwells as you've identified; n/b it's terrible passenger flow. - The BG terminal is bad in both directions as well -- s/b you get hit with fumigation delays, n/b with the merge. - 3 track from Franklin to Borough Hall is a hornets nest of 1 shot GTs. You note the variability problem, but I think that stretch is worth highlighting independently - 125 St is chaos -- long dwells, 10mph 1 shot enforced leaving speed nb. It's not constraining given how much of a dumpster fire the core section of Lex is, but it certainly contributes to lengthened peak-hour runtimes. I've noticed that frequently, a will get held for a or crossing in front, which in turn plugs a coming downhill into Franklin. No direct crossing interaction, but the cascading effect certainly hurts s. On the question of service more generally, I tend to say no. Assuming the proposal are express trips from 149 to Burnside, you first run into the issue of merge delays. Skipping 5 stops will save you 2.5-3.5 minutes, or almost a full headway...which means you arrive at Burnside at about the same time as your leader. Then what? Somebody is getting a merge delay, or you extend the express segment of the even further north, reducing its potential catchment and thus the case for express service, etc. As I see others have noted, there's equally an issue of yard access. M track on Jerome gets a *lot* of use in this capacity. Again, assuming this is just an express as far as Burnside, you'd avoid put ins in the AM around BPB, but the first Burnside drop out arrives at Burnside before 9 AM! You're either going to have to move it to the local (running the risk of fumigation delays), keep the set in service (what I would do), or end express service quite early. Tractable, but again, something to think about. There's finally a load balance argument. would undoubtedly attract riders from the which we...really don't want to be doing, given Lex loads.

CBTC will certainly enable it; I’d love to see it happen. Just a question of reprogramming limits in the CBTC software. I would say yes, though by and large this is what was done to begin with, even in the mod effort (with some exceptions, ofc). It makes little sense to me to sacrifice speed for capacity in areas that don’t need capacity.

If we could figure out a way to rebuild 135 so that nb trains could hold short of the junction on the spur for a crossing move before proceeding through, that'd be great.

s skipping 138 on the middle is really important for junction fluidity at 149. Having s plugged behind s s l o w l y merging in front from the connector tracks in the AM/diverging s l o w l y and potentially getting plugged by s in the PM wouldn't do anything good for Lex capacity.

A train blasting into Church at 60 would be surprising but not inherently unsafe if control lines were designed for that speed. It’s just that doing so is really bad for capacity. Allowing trains to run wild in river tubes or on long downhills such as this at times does not actually produce speeds in excess of safe speeds around curves etc. What it _does_ do is force signal engineers to design half mile long control lines to account for greatly increased stopping distances, which would in turn reduce line capacity through greater train separation (esp around stations) and forced increase use of station time. This is why, for example, A4 on CPW has GTs starting at 86 St rather than just before the curve at 116. Of course, there are also thousands of cases where allowing speeds greater than x does create a geometry risk of some sort, but anecdotally those curves are superelevated such that they’d be good for speeds much higher than what exists currently. This article on the original IND signal system gives a good overview. https://www.jonroma.net/media/signaling/railway-signaling/1932/New Eighth Avenue Subway- Signaling and Interlocking in New York City.pdf#page= https://www.jonroma.net/media/signaling/railway-signaling/1932/New Eighth Avenue Subway- Signaling and Interlocking in New York City.pdf#page=5 I mean, yes? I don’t think they necessarily saw the enforced slow speeds as being something that necessarily had to be made up for, they just wanted to maximize the impact of the express run (which they most certainly did — on a minutes saved/stops skipped basis, Culver is one of the most efficient express runs in the system).

GT35s (installed for capacity’s sake given the downhill) will do that to speeds. Fun fact, though: the original IND signaling was timed even slower — 30mph.

This is unbelievable how? 46 St is between those 2 stations, you need to shut off power on multiple tracks to deal with 12-9s generally, and the shortest possible diversion is from...Queens Plaza to Roosevelt.

I really don't think we need to be so beholden to interagency cooperation issues, especially when the two railroads in question are under a single organizational umbrella and are about to see large parts of their operation merged as a part of this 'Transformation Plan.' The infrastructure issues here are trivial -- underrunning to overruning on the M8 requires zero intervention from the engineer, as the train senses the type of electrification automatically -- and the bureaucratic issues boil down to the equally tractable issue of installing management teams at the two agencies who are willing to pursue interoperability and enmeshed operations. As for the issue of construction costs...I do not see your point? If things were cheaper to build, we would have the capacity to build more things from the various wishlists. This observation is well grounded in the history of the various expansion projects. I'd personally love to see PATH be integrated into the subway proper -- one of the great failures of our time, IMO, was Path-Lex.