Green Line Extension to Medford & Union Sq

The slowdowns are the result of the FTA getting involved and demanding them. Who knows how long they had been running the T at some level of risk deemed unacceptable to the FTA.
That's probably a part of it, but not all of it. They basically stopped keeping track inspection records in 2022.
 
That's probably a part of it, but not all of it. They basically stopped keeping track inspection records in 2022.

And because of that stupid mistake, they paid for it very dearly! When will they learn that you can catch more flies with honey than with vinegar?!!!!
 
View attachment 43238

Accordingly to the website. The three longest slow zones are

1. Westbound (Inbound) between Tufts and Ball Sq for 1,200 ft (.23 miles)
2. Westbound (Inbound) between Gilman and East Somerville for 800 ft (.15 miles)
3. Eastbound (Outbound) between Ball Sq and Tufts for 800 ft (.15 miles)

So it is kinda pre-Gilman. A good 1,700 ft (1,200+500) is before Gilman sq. Though there is a 800 ft long slow zone between Gilman and East Somerville. That spot parallels with the community path so everyone can outwalk the Green Line in very visible fashion.

Hmmmm... This one of the moments where the MBTA website provides better data than TransitMatters.

That's so weird b/c yesterday from Gilman to East Somerville we didn't slow down *at all* -- but then we sat at E. Somerville for about 3-5 minutes because of "a train in front of us," so that was a bummer...
 
View attachment 43238

Hmmmm... This one of the moments where the MBTA website provides better data than TransitMatters.

I'm still surprised we still don't have slowzone data for the GLX and D branch on TransitMatters. I'd think those two should be trivally easy to get slowzone data for those two from TransitMatters. Anyone know how they can add this data easily so we can keep track via TransitMatters? For the longest time TransitMatters had somewhere on the old v-3 dashboard "slowzone data for the D branch and GL trunk coming soon", but now they upgraded to dashboard v-4 and we still don't have this data from TM.
 
I'm still surprised we still don't have slowzone data for the GLX and D branch on TransitMatters. I'd think those two should be trivally easy to get slowzone data for those two from TransitMatters. Anyone know how they can add this data easily so we can keep track via TransitMatters? For the longest time TransitMatters had somewhere on the old v-3 dashboard "slowzone data for the D branch and GL trunk coming soon", but now they upgraded to dashboard v-4 and we still don't have this data from TM.
Funny thing here, TransitMatters just pulls an API from the T and makes it pretty and available. Their slow zone data are based on the difference between the best runtimes that the T has recorded in the data and the current times, not any official slow zones from the T. (This method is beneficial since it doesn't rely on the T making anything public but rather what the trains are actually doing).

I think the D line has bad data in the API, because the GL is hard to track being a combination of track circuits and GPS, and the trunk probably rarely runs at full speed / has challenging data quality issues too. But not sure. In any case it is probably a case of the source data needing lots of cleaning or being unusable entirely rather than anything TM has direct control over.

Also they are an entirely volunteer org, so, if it's due to a lack of time or resources on their end that is pretty understandable.
 
That's so weird b/c yesterday from Gilman to East Somerville we didn't slow down *at all* -- but then we sat at E. Somerville for about 3-5 minutes because of "a train in front of us," so that was a bummer...

The quickest trip from Gilman to East Somerville yesterday was 84 seconds, right about the pre-slow-zone median. The median trip was 3:06. The 84 second trip, and the handful of other sub-100-second trips, were apparently drivers completely ignoring the slow zone. You were likely on one of those trips.
 
The T's deferred maintenance issues date well before Baker, Poftak. You don't get this far in the hole in just 4 or 8 years. (I am not suggesting they helped at all, but they perpetuated an ongoing issue, they didn't start it.)

In that 8 years, I would say they also did do a "good" job of doing a whole dog and pony show while continuing or possible even accelerating the hole digging. I mean I fell for it - hard. I'm the guy that wrote up the thread "MBTA 2021 - The year the MBTA stop sucking?" and omg I can't believe I was so wrong.

On some level, I do still do hold on that the work in those 8 years of all transformations programs and work performed and presented during that time did something. But I don't think anyone can truly say it's apparent. But instead there is so much more visible - or at least rider affected issues to clear out now versus back then.
 
The quickest trip from Gilman to East Somerville yesterday was 84 seconds, right about the pre-slow-zone median. The median trip was 3:06. The 84 second trip, and the handful of other sub-100-second trips, were apparently drivers completely ignoring the slow zone. You were likely on one of those trips.
Data from TransitMatters show plenty like half the trips not obeying the slowzone. Before, the trips would basically the same, now there's so much varibility. This makes the bunching problem really, really, bad, if some drivers fail the obey the 20 minute slowzone roundtrip. It causes the drivers speeding up and not following slowzones to get too close to the trolley in front of them that are obeying the slowzones.

1696534296826.png
1696534312995.png
 
drivers speeding up and not following slowzones to get too close to the trolley in front of them that are obeying the slowzones

Doesn't that implies we have data that demonstratively shows the drivers are ignoring orders? If so, it's hard for me to feel angry since nobody is hurt and it even as laymen some of us are speculating they are unreasonably err-ing to caution. At the same time, it is concerning as it also implies the rules are being ignored which could mean serious rules are getting ignored (assuming the known ignored rules are truly overkill).
 
Guess I got another speed demon today b/c Gilman to Lechmere was as fast as it had been all spring and summer.

Of course, on the way home I got tired of waiting after 9 minutes and walked all the way to Gilman... (which, in this weather, was absolutely fine by me).
 
From browsing the TransitMatters dashboard for Gilman -> East Somerville, it seems that the fast trips (within 2 minutes) are much more common in the PM than AM, especially after 5pm. Strangely, despite a large number of sub-120s trips, the median and the mean are not too far apart, with the mean often being a few seconds longer.
1696540203041.png

Also, these fast trips seem less common on Wednesdays and weekends than other days of the week. Here's Wednesday, Oct 4:
1696540281021.png


So the question is, why are some drivers seemingly ignoring speed limits, and why do such behaviors differ at different times and on different days?

Could it be that drivers on certain shifts weren't made aware of the slow zones? Or is it just a bug with the T's GPS systems and arrival time predictions, perhaps only for certain cars?
 
Last edited:
From browsing the TransitMatters dashboard for Gilman -> East Somerville, it seems that the fast trips (within 2 minutes) are much more common in the PM than AM, especially after 5pm. Strangely, despite a large number of sub-120s trips, the median and the mean are not too far apart, with the mean often being a few seconds longer.
View attachment 43259
Also, these fast trips seem less common on Wednesdays and weekends than other days of the week. Here's Wednesday, Oct 4:
View attachment 43260

So the question is, why are some drivers seemingly ignore speed limits, and why do such behaviors differ at different times and on different days?

Could it be that drivers on certain shifts weren't made aware of the slow zones? Or is it just a bug with the T's GPS systems and arrival time predictions, perhaps only for certain cars?
I really want to believe that the speed restrictions are possibly for only certain types of rolling stock only, rather than the operators aren't just deciding willy nilly whether or not to obey them.
 
Data from TransitMatters show plenty like half the trips not obeying the slowzone. Before, the trips would basically the same, now there's so much varibility. This makes the bunching problem really, really, bad, if some drivers fail the obey the 20 minute slowzone roundtrip. It causes the drivers speeding up and not following slowzones to get too close to the trolley in front of them that are obeying the slowzones.

View attachment 43254View attachment 43255
It's hard to believe that so many drivers are ignoring the slow zone orders. Hopefully there is some other explanation, but in the usual absence of any forthright information from the MBTA, we have to at least ask whether the drivers are being reckless. I hate to say it, but the Globe needs to see this data and start digging into the matter of why.
 
It's hard to believe that so many drivers are ignoring the slow zone orders. Hopefully there is some other explanation, but in the usual absence of any forthright information from the MBTA, we have to at least ask whether the drivers are being reckless. I hate to say it, but the Globe needs to see this data and start digging into the matter of why.

And there's still no info on a fix for the line as of yet!! I say that they should get in touch with the construction co that was responsible for laying the track work & fix the problem by relaying the rails!! It's only fair that it be done right! After all, commuters have long-awaited for this program to be completed & open for business!! :mad:
 
It's hard to believe that so many drivers are ignoring the slow zone orders. Hopefully there is some other explanation, but in the usual absence of any forthright information from the MBTA, we have to at least ask whether the drivers are being reckless. I hate to say it, but the Globe needs to see this data and start digging into the matter of why.
Operators speeding is a big issue on the Green, unfortunately. One time I was riding the train of an operator friend when he was in the trailing car, and he kept pointing out how the leader was going [value] over the limit and showing me the limit signs through the door window as we passed (and then cue us going significantly slower when it was his turn to drive).

Funny thing here, TransitMatters just pulls an API from the T and makes it pretty and available. Their slow zone data are based on the difference between the best runtimes that the T has recorded in the data and the current times, not any official slow zones from the T. (This method is beneficial since it doesn't rely on the T making anything public but rather what the trains are actually doing).

I think the D line has bad data in the API, because the GL is hard to track being a combination of track circuits and GPS, and the trunk probably rarely runs at full speed / has challenging data quality issues too. But not sure. In any case it is probably a case of the source data needing lots of cleaning or being unusable entirely rather than anything TM has direct control over.

Also they are an entirely volunteer org, so, if it's due to a lack of time or resources on their end that is pretty understandable.
I've gotta imagine data quality issues are a huge part of the issue.
 
Operators speeding is a big issue on the Green, unfortunately. One time I was riding the train of an operator friend when he was in the trailing car, and he kept pointing out how the leader was going [value] over the limit and showing me the limit signs through the door window as we passed (and then cue us going significantly slower when it was his turn to drive).


I've gotta imagine data quality issues are a huge part of the issue.
That has to be hell for trying to enforce any kind of schedule or regular service.
 

Back
Top