Opting for Cabs, The Hidden Benefit(?) of Construction
New Yorkers spend millions on taxis when subways undergo maintenance on the weekends.
You have several choices when your subway service is disrupted:
- Get those steps in! - walk up to 20 blocks
- Take the bus - wherever that's supposed to happen
- Hail a cab or call an Uber - $$$
- Turn around, go home, fall onto the bed
It's a drag when we're presented with the trade-off framed above. Often, you’re forced to hand over the extra cash and spring for the cab. But if this happens to lots of people, across the city, every week, that’s an economic impact that’s hard to ignore.
Externality is the official term for this sort of impact.
A cost or benefit that affects a party who did not choose to incur that cost or benefit
When you buy a Metrocard, you sign-up for the occasional maintenance necessary to keep the whole system moving. I thought long and hard if the forced alternative modes of transportation created a negative externality (cost) for commuters. I decided no. Maintenance and it’s associated costs are part of the social contract between commuters and the MTA. Side-effects are baked into the relationship.
Cabbies, on the other hand, benefit from the situation and as a third party. They experience a *positive externality* with the extra cash in their pockets, stemming from a phenomena they had no part in shaping.
So how many people defer to option 3, hailing a cab? It’s an important question for policymakers to ask. If the MTA considers the lost ridership revenue, cost of contractors, and future maintenance, shouldn’t they consider the external effects of planned maintenance?
I spent the last six months data-mining, researching, hacking, and FOIA haggling to wrangle construction records and taxi-trip data from the MTA and TLC. The analysis below is the result of some pretty cool engineering and really lucky events, if you want a deeper dive, feel free to check out the “How did I do this below”.
Let’s start with a pair of Saturdays in July, 2013. The 6th and 13th were both sunny, mid-70s, beautiful summer days in Manhattan. Elliot Spitzer resigned on the 6th and the Yankees lost an away game on the 13th. Demand for public transportation was likely identical on both days.
The only difference? Planned maintenance on the 4,5,6 closed local stops on the uptown and downtown tracks between Brooklyn Bridge and 86th St on 7/13/2013.
AKA you were $0L if you lived on Canal and wanted to take the subway to the Met on 81st.
The two heat-maps show stark differences. Taxi pickups on the 13th had greater intensity along the 4,5,6 corridor, especially near main transit hubs at Union Square, Grand Central, and 59th St.
Madison Square Park is a good reference point. The area is bordered by two Local 6 train stations, the 23rd and 28th St stops. Both of those options were closed to everyone attempting to depart the area.
*ZOOM IN AND ENHANCE*
Pick-ups on the 13th are more intense and concentrated within the half-block radius of each station. There’s also heavier traffic on the avenues. It’s possible that folks on Lexington and 3rd, the two vertical stretches to the left of the markers, looked at Google or Embark and realized they were out of luck before walking to the station.
The verdict: more people needed rides on a day with construction as compared to just a week prior when everything was running smoothly.
To dig deeper, let's look at some summary statistics. The chart below shows the per-minute figures for ridership and fare totals. Several tests demonstrated statistically different averages between normal and construction days.
We expect that with more rides, come higher revenue and the data confirms that hypothesis. A side note, however, is that the average fare on a given ride is higher during subway construction. My hypothesis? Folks use the subway for longer treks, and without that option they are forced to pay for an unexpectedly far trip.
The pattern repeats itself on other comparisons and validates the original hypothesis: subway construction affects taxi markets. I examined the last three years of taxi records and split the group on the basis of construction or no-construction. The benchmark -> does the maintenance cause delays that “heavily affect ridership” a standard the MTA used in their file.
Subway construction, on average, does increase taxi-pickups. The gap between the green and red lines is statistically significant. Both curves also have the same shape. General cab-hailing behavior peaks at the expected times. The average revenue just has a higher magnitude when the subways go down.
Construction on the Lexington Line creates demand for about $1.5million in rides every year. We get this number with some 11th grade calculus: calculate the area under each curve and finding the difference for both Saturday and Sunday trends. (Check out the math/formulas below)
City-wide impact hovers around an annual $12million externality for cab drivers. My analysis focused only the Manhattan portion of the 4,5,6 tracks. If we extrapolate the figures and multiply by the other 8 "trunk lines" we see the larger impact unfold.
The MTA invests over $2.5 billion on subway maintenance, repairs, and improvements every year. That's about $300 for every woman, man, and child across the 5 boros. Whether you're paying elevated state and city taxes or forking over cash at the MetroCard kiosk, everyone shares in the burden.
The impact I found, relative to total ridership and capital investment, is miniscule. We're talking basis-points range. But the externality is still real. $400 in extra income for cab drivers, who make on median $33,000/year (and dropping), is a significant boost that wouldn't exist without disruptive subway construction.
Does it matter that cab drivers benefit from subway construction?*YES* Taxi companies like inconvenient public transportation (see: lack of easy access to LaGuardia + JFK.) But the market still isn't efficient. Cab rates stay the same despite higher demand.
That's what firms like Uber are exploiting with surge pricing. Without strong protections to stem private benefits of public transit interruption, commuters are vulnerable to even higher costs when subways go down. And no one bargained for that when they bought their Metrocard.
Want to just dig into the data? Check out the links and scripts below.
I developed a fairly straightforward strategy for this study in a cab-ride to my finance’s place. Yes there was subway construction that day.
- Collect a minute-by-minute level summary of taxi-trips.
- Map daily construction status to the taxi-trip table.
- Run several statistical diagnostics on varialbes using construction status as independent variables.
- Visualize those key statistics over time.
- Calculate the integrals of each curve and then find the differences.
- Ship the results on my own website!
EASIER SAID THAN DONE
Before I get started, I’d be remiss to say that the work above was not possible six months ago. Taxi-trip records were released on an annual basis in separate tables and the MTA didn’t share public records of subway construction. Two fortunate things happened:
- August: The Taxi and Limousine Commission in coordination with NYC’s Open Data initiative worked with Google to host all taxi-trip records on BigQuery (Google’s service for big data analysis).
- Late October:My FOIA request to the city for the dates and extent of construction on the 4,5,6 was fulfilled and they shared a treasure trove of historical records.
1) Collect a minute-by-minute level summary of taxi-trips.
The TLC recently partnered with Google’s BigQuery to create a table of every taxi-trip taken in the past five years. It is a wonder and a long-time coming. Previous releases were limited to a year and one would have to combine and query all of them locally. Today’s solution allows me to query 211MB of data in under 30seconds with complex requests. It is AWESOME. The dataset contains everything from the pick-up and drop-off coordinates to tip-amounts and the type of payment system integrated into the cab.
90% of the query was SQL basics: pull the sum and average of several variables and group for the minute-by-minute summary.
The other 10% - geofencing the trips - was harder than I anticipated. Manhattan doesn’t sit on perfect North-South latitudes/longitudes. The island is actually on a slant, in respect to True North, so using a simple “point-in-the-box” equation doesn’t work for querying broad swaths of land in NYC. In short, you end up getting squares that don’t align to the sector in question.
The path of the 4,5,6 is slanted too, just like the rest of Manhattan. That makes it difficult to triangulate pick-up coordinates and filter whether they sit along the various stations of the Lexington Line. So I had to crack open my old trigonometry textbook and find a generalized approach.
I picked four points at the northern and southern end of Manhattan. The resulting rectangle provided a stretch of the city with a standard deviation of a block from the subway entrances in question. With those coordinates I created an equation that would take any given pick-up location and test whether the distance between that point and each four corners is greater than the sum of each side of the rectangle. Some online examples of this are here, here, and here.
After testing this formula several times placed the code into the full query and pulled the trigger. Step one done.
2) Map daily construction status to the taxi-trip table.
The MTA posts data every minute, but finding historical and aggregated information is difficult. You’d think this is a distribution-with-the-public-problem, but the MTA didn’t have a central store of historical construction data. “We found someone in finance who tracks this for his work, here’s his file.” They were gracious working with me to obtain the file, but it wasn’t plug-and-play.
There’s a famous quote that 90% of “data science” is just getting your information into a format friendly for processing. That was certainly the case here. The FOIA file that the MTA shared with me was a trainwreck (pun-intended).
Every month going back to 2010 had its own tab and days with construction were marked not by character or digit — but rather color-coded. So I had to hand-code a binary 1-or-0 for the appropriate status of subway construction for each day between 2012 and 2015. The Google-spreadsheet I’ve shared below contains that mapping and further explanation.
3) Run several statistical diagnostics on varialbes using construction status as independent variables.
Before digging into higher modeling and visualization I wanted to make sure that I had the statistical grounding to move forward and demonstrate differences.
This is pretty boring. If you’ve read this far, just dive into the R script below where I’ve got several box-plots that find statistically significant differences between both # of rides and revenues between days with/without subway construction.
4) Visualize those key statistics over time.
The ggplot2 package for R is always great. I found a beautiful theme function that I’ve posted on my Github. It allows you to format your entire plot and avoid messy plotting scripts by calling the function instead of incorporating those arguments into the command.
5) Calculate the integrals of each curve and then find the differences.
This was fun! An R package called Bolstad2 contains the necessary integrating functions to calculate the same curve as the geom_smooth writes for the plot. By subtracting the specific integrals for each day’s summary curve we get the difference figure.
6) Ship the results on my own website!
I’ll spare you the details of my personal development in HTML and CSS prowess and jump right into the fun stuff: graphs and images!
CartoDB was a pretty great place to throw data into their application and get sharp, reliable, scalable graphs on the other side. They have made significant improvement in their product over the past year. Importing data is a breeze and they have great options for embedding and deployment. They’ve even managed to perform some iframe witchcraft that prevents the user from accidentally zooming into the map as they scroll. Thumbs up team!
On another note, I tried to use JuxtaposeJS for a “before-and-after” slider. Their embed option is really finicky and wrangling the object’s size is a pain in the @$$ so I gave up and replaced that idea with the gif. Same idea, but the slider would have been cool.
Lastly, moving images from R plots into websites is a pain. An easy remedy is *not* to listen to bloggers talking about using hi-res PNGs and just opting to get the SVG file, throwing that straight into your directory and rendering on the browser. The image looks better and it’s automatically responsive.