RR503

If you happen to have the documentation of the 74 St switches project handy, that'd be a useful reference point.

I had to copy and paste that section so many times before I got all the errors worked out, I must have forgotten to fix that. Thanks.

That's something I forgot to add/would definitely do. Issue is capacity along Broadway. You need the full 15tph for loads in Astoria, and you can't go above 21tph at City Hall Curve. The math there just doesn't work -- 6tph to/from Queens Blvd just won't cut it. If that constraint didn't exist, that's absolutely what I'd do. Good catch. Will fix. I deinterlined 149 because the current merges there are just...so...bad. I'm sure I've posted the chart before, but if not: Despite the bypassing 138 at rushes, runtimes are almost double what they are off peak. That's 100% merge congestion, and it's congestion that really isn't doing any good for Lex. You're right that it'd be an unpopular move, but honestly with runtimes that nuts, it may actually work out to a net positive in total trip time. The logic at 145 builds off of this: with 30tph of capacity going up Jerome and greater capacity along Lex, there's less of an incentive to have Concourse operating as an interlined relief route. That's why I undid 145, though it isn't a decision I'd be all that unhappy about reversing -- 145 is a crap merge, but thanks to its design it generally doesn't create cascading impacts.

It would, and in a perfect world I'd do just that. But I was trying to keep the list of things there to things I could actually see happening, so Burnside switches it is! (Also, demand growth in the Bronx is concentrated in the southern portion of the borough. Don't know if we necessarily want to be running 30tph+ that far north)

I'd prefer to see the given that the is already a bit of a mess, but given the blowback experienced on a certain pilot because we were replacing 10 cars with 8, I figured that may be a price worth paying. It's not a decision I have any strong feelings about, though. You could work it like that, but there's also a capacity problem. Both the and run 10tph peak into Manhattan from Brooklyn -- you can't merge those both into Astoria with current terminal infrastructure. You could run more 96 St s, but then it becomes harder to manage yards. There's a similar issue with Queens, the 's 10tph can't all turn at Whitehall, so you're either stuck with an ugly mainline discharge at Canal or an extension to Brooklyn, at which point we're basically back where we're started. The nice thing about the is it's a low frequency overlay that's easily adjustable into capacity gaps. I think it's best we keep it that way, and if we're really worried about the 's length, extend the instead.

Knowing more. I've done a lot of work with that area and with those lines, and the more you get into it the more you realize just how impossibly difficult it is to run a reliable and frequent railroad with merges like Dekalb. This isn't to say we shouldn't go for things like eliminating the CCTV stop, better signing area STs and the like -- if for no other reason than I have about 0% confidence of Dekalb deinterlining going forwards anytime soon -- but there's just no way to run a system used by humans precisely enough that you can make a 30 second wide merge window.

This is really gonna require federal assistance to fix. Through fares and its collection of economically sensitive taxes, MTA is very exposed to economic fluctuations in its operating budget, and the state already has plenty on it's budgetary plate. I'm really hoping congress/FTA pulls through with a sizable temporary operating assistance program for transit agencies in general, but I've been doing this long enough to know not to hold my breath.

Now, for some fun. I finally made maps of my various deinterlining ideas. Today's service https://drive.google.com/open?id=1HHNa2XqlrDKPIKUzpTJcyQbSndtbs1cM What I'd do without spending any capital $$$ https://drive.google.com/open?id=1yZcwJfjcO1tfYuttqW2lUuatAFvIaxuz What I'd do with capital $$$ https://drive.google.com/open?id=15z4fvc1cfxxtY_ZhUbFex3jxgT0dt3lm The general principles here are to minimize merges/maximize capacity while trying to preserve a maximum of important connectivity (so we deinterline CPW, but not Essex or Bergen), and on the no-$$$ map to try to jump for deinterlinings that can largely be achieved through low-effort swaps, ie , , . Nothing on here will be all that unfamiliar to those of you who've been reading my ramblings for a while, but I thought it'd be nice to see it all on one map.

Well what you should really do is break runtimes out into its components: runtime and dwell. Then try to figure out components: how much of this runtime is holds to time? What about controllable dwells? etc, and then you go ahead and schedule around median runtime, but without those confounding components in the mix.

I'm not sure of the advisability of ZPTO without PSDs and the like, but these arguments about blackouts and safety rel. OPTO are relevant to every transit system in the world, yet we're the outlier in still having two person crews. As you point out, this is political and thus not totally responsive to the technical (de)merits of a given configuration, but I think that's a disconnect worth recognizing.

Gonna disagree with you here. You're right that Queens and 59 St are trash, but Dekalb and 36 are no walk in the park either! Dekalb is especially troublesome beyond its discrete operational impacts given that it is upstream -- in both directions -- of operationally complex and capacitally restricted areas. For southbound trains, intervals arriving bunched and/or in the wrong order at Coney Island, Brighton Beach or 36 St causes congestion, while northbound variability will throw merges at 34, 59, etc. Those are nontrivial impacts! In my research on this issue, the general pattern that keeps resurfacing is that a chain is only as strong as its weakest link. You can make one part of the system work well, but if all of that capacity is going to run into some mess like Dekalb, you're not going to be able to realize nearly the benefit that you could have if you tried to fluidize the entire line. Now, of course, that one merge probably will become easier to operate because you're going to have fewer cascading impacts running into it, but it's still going to have a nontrivial negative impact on your capabilities. See, for example, Camden Town on LU's Northern.

KISS is generally a good principle by which one may run the railroad, but I do think it’s worth recognizing the ways loops hamper dispatchers’ ability to mitigate service problems. If something happens on the southbound before the PM rush, there’s a near 100% chance that the problem will ricochet back north thanks to the fact that you have little to no terminal recovery time. This in and of itself is a tradeoff — recovery time is an operating cost — but that sort of operating margin really saves the railroad from having to be constantly skipping/holding/pissing off riders. I again don’t think this is an issue that’s clearly best one way or another, just again, tradeoffs....

and terminating there for Culver CBTC IINM.

If you want to run , you're probably best off extending the yard tracks at Church at 300', reinstalling the full complement of crossovers on the lower level, and running local to Church and express. You can do 10 -KH, 10 -CI,10 -Church and 10 -Church to keep the load on the relay op at Church to a manageable 20tph. Kings Highway can barely handle what it does today, and CI is a joke of a terminal. Just a friendly reminder to everyone that: - There is about 25tph of unused capacity in the tunnels between Manhattan and Queens today - Up to 10tph of that unused capacity is Forest Hills inefficiency, up to 15 is Astoria and the 's occupancy of space in both 60 and on QB (which can be treated as an extension of 53/63) - Some indeterminate figure (if I had to guess, 10-15tph) of that unused capacity is thanks to the extreme complexity of merge/diverge operations on Queens' services. The fixes here should be self-evident: fix your terminals, fix your service patterns. We don't need, and cannot justify, more infrastructure until you do those things.

Agree with everything here except for this. Loops are good for terminal fluidity, but they wreck your ability to mitigate pipeline issues -- your terminal becomes GIGO. Would add tail tracks and well designed signals entering the terminal to the list as well -- that latter issue plays a role at JC.

Yes. They could do force and lock, but your switch maint budget would go way up with it moving after every movement through. I personally think the DGTs are bad, but the 80/20 at Forest Hills is in dwell times -- DGTs add 16 seconds to entrance times, while terminal dwells can be anywhere from 45s-120s.

Yes I am! They also modded the signals on the LL I'm told to make the relay op more efficient.

[citation needed] on them dialing performance back. We've had the same signal design standards (=same max acceleration profile) since the mid 1990s. I suspect this was either a really good TO who knew how to play with 2 shots to make them work just right, or a broken speedo

Good. Incessant, scab-picking, fact-averse discussions such as this make people with limited free hours but a wish to share real knowledge feel like these forums aren't worth the time. I would categorize myself as one of those people.

This is a good question re: X. I'll ask around. It's quite disappointing to see that this project somehow didn't get piggybacked onto the oh, idk, 2 years of expressing and weekend shutdowns for the stations work. Costs the agency $$$ and riders time unnecessarily.

Those of you who don't have the facts to back up your claims about certain types of car equipment having impacts on certain lines shouldn't comment as if you do. It's an unnecessary waste of everybody's time and computer bandwidth. As these charts show, actual runtimes are down vs 2019, even when you limit the analysis to just the PM rush. I don't doubt that the R46s are having 3-10s adverse impacts on dwell times at busier stations and maybe are slowing some express runs slightly, but those impacts seem to be trivial in the face of the general downwards trend in runtimes.

You do realize that the merge delays and capacity losses back then were so bad that the MTA chose to completely rebuild the junction, right? And even then, service did not perform all that well. The 80tph run through in the 1968 pattern got really messy, I'm told, with trains backing up onto the bridge and into Dekalb moreso than even today. All that aside, a lot has changed! Signal mods have made the system less resilient, electronic delay reporting has made numbers fudging harder, and people have higher expectations for service. Just sayin'...

Serious congrats to @Union Tpke and all the others that have pushed for reopened entrances. It's amazing to see these decisions reexamined.

Next to is allowed, on the same tracks as is not unless you have a temporal separation waiver

Yeah, not working for me either. To the general discussion: very few issues are, by themselves, conversation-ending propositions when it comes to reroute scenario, and the 's yard placement is especially tractable. Back in the '80s and '90s when these discussions were last had, there existed a much steeper drop off in PM demand to points north on IRT Broadway, which made running s back north from Flatbush expensive relative to loads and contributed to the business case for access to Livonia, This is much less true today, which makes it easier (though of course still a cost) to run the line to Flatbush. Generally, though, there's a reason cost-benefit analyses exist, and it's to resolve question exactly like this one. Upwards of 30% of weekday daytime trains are delayed for more than a minute northbound through Rogers (a stat that's considerably higher during the peaks); on excess runtime expenses alone, this would likely pencil out. Here's some data on hourly loads leaving the core: