Skip to content
techgirl.nyc

MTA · New York City Transit

Measuring how track work affects subway service.

I connected track-work records with train movements to help the MTA identify where scheduling changes could reduce disruption.

The story in four stages
Press play or pick a stage

One train keeps losing time between 42 St and 34 St.

Each row is a station and time runs left to right, so every diagonal is one downtown train. The bright one slows on a single stretch, but nothing in the train data says why.

One stretch of track at midday · each line is a trainSchematic
59 St50 St42 St34 St28 St12:30 p.m.12:4012:501:001:10 p.m.Time →Track work · 42 St → 34 St12:45 – 1:05 p.m.Extra running time
Selected trainOther trains
Two datasets, no link between them
Train movementsWhen each train passed each location
Track-work recordsWhere and when crews held the track, kept in a separate system
Illustrative station names, train paths, work window, and hourly pattern. The analysis compared the same segment, direction, and time of day. Findings describe train running time, not passenger hours or achieved savings.

Track maintenance keeps the subway running, but trains slow down as they pass a work zone. Work orders and train movements lived in separate systems, so no one could say which work locations and times cost the most service.

I joined the two datasets on track, time, and location, measured the extra running time against typical times for the same segment, direction, and hour, and automated the pipeline with Airflow and Spark SQL so teams can refresh it daily. The results describe observed additional train running time, not passenger hours or time saved after a schedule change.

≈64 sec
additional running time per affected segment
≈58 h
additional train running time on one corridor over three months
6M × 490K
arrivals matched to work orders
Built with
Python / SQLMatched baselinesAirflowSpark SQL