Category: Chicago

Getting a little closer to understanding Chicago’s pothole-filling performance status

December 21, 2013 /

Tom Kompare updated his web application that tracks the progress of potholes based on information in the city’s data portal in response to my query about how many potholes the city fills within 72 hours, which is the Chicago Department of Transportation’s performance measure.

He wrote to me via the Open Government Chicago group:

Without completely rewriting http://potholes.311services.org, I added a count of the number of open (not yet addressed) pothole repair tickets (requests) that exceed 3 days old. As of today, the data from the City of Chicago’s Data Portal shows 1,334 or the 1,404 open tickets in the 311 system are older than three days.

Full disclosure: The web app actually looks for greater than 4 days old. The Data Portal’s pothole data are only updated once a day, so these data are always a day old. 4 – 1 = 3.

Keep in mind that this web app only shows how many are yet to be addressed, and does not count how many have been patched within CDOT’s 3-day goal during some arbitrary time period. That is a much more intense calculation that this pure client-side Javascript web application can handle due to bandwidth restrictions on mobile (3/4G). This web app already pushes the mobile envelope with the amount of data downloaded. I can fix that, but, again, not without a rewrite.

Still, 1,334 open repair requests (12/16/2013 Data Portal data) is quite different than the number of open repair requests reported by CDOT (560 in Alley, 193 on street) on 12/16/2013. I’m not sure what is the difference.

This reminds me of a third issue with the way CDOT is presenting pothole performance data online (the first being that it’s PDF, the second that it doesn’t work in Safari). The six PDF files are overwritten for every new day of data. If you want information from two days ago, well you better have downloaded the PDF from two days ago!

Citibike in New York City differs slightly from Chicago’s Divvy

December 16, 2013 / / 14 Comments

I visited New York City two weekends ago for a Streetsblog writers conference. I was there for three nights and four days. To get around I put a bunch of cash on a Metrocard to use the subway and JFK Airtrain and I bought a 7-day pass for the Citibike bike-share system.

Citibike and Divvy in Chicago use nearly identical equipment from the same manufacturer, and Alta Bicycle Sharing operates both systems. Citibike sells the 7-day pass for $25, a relative steal for personal transportation costs in New York City – probably any city. Divvy only offers 24-hour and annual passes.

Citibike stations have maps of a better design that matches the walking wayfinding stanchions that New York City’s Department of Transportation has installed. The stations integrate the ad+map board onto the kiosk while Divvy has separated them. I don’t see an operational advantage to either design, but there does seem to be less material used in Citibike’s integrated design which uses one fewer solar panel.

I’ve never used Divvy’s touch-screen kiosk to obtain a single ride code as part of using a day pass so I can’t compare it to interacting with the Citibike kiosk to obtain the ten or so ride codes I needed on my trip. This was the most infuriating part of the experience, which annual members don’t experience because they have a key: the kiosk is very slow in responding to a tap and sometimes the docking bay wouldn’t accept my brand new ride code. You can’t get a replacement ride code for two minutes, preventing quick dock surfing.

The bicycles seem exactly the same: too small of a gear ratio which means a slow top speed and an easy-to-reach “over pedaling” threshold. This may be more important for New York City to have because you must climb 140 feet up the bridges to cross between Manhattan and Brooklyn or Queens while Chicago has no significant slopes. I eventually stopped using Citibike in favor of the subway and walking. I like riding trains almost as much as I like riding a bicycle and cycling in downtown Manhattan is difficult if you’re unsure of a good route to get to your destination. I prefer to not use an app for directions because of how frequently the turns appear meaning I have to inspect the app just as often to ensure I made the right one.

I’d like to see my Divvy key work in other cities where Alta operates bike-sharing. Just charge my bank card on file, applying the lowest-cost pass and letting me bypass the user agreements before purchasing a pass in another city.

CTA fare breakdown for Ventra and fares it replaces

December 13, 2013 / / 8 Comments

This CTA graphic shows all the fare media Ventra replaces. 

The Chicago Transit Authority expanded its pilot contactless card fare payment technology systemwide in 2002, and introduced Chicago Card Plus, which added the benefit of linking to a credit/debit card, in 2004. After 11 years, the two cards were hardly “popular” as Jon Hilkevitch called them today. In the context of his article I believe he meant “liked” or “admired” and not widespread, as Ventra does not have the same admiration because of all of the issues people are experiencing.

While Chicago Card/Plus users likely preferred this fare payment over magnetic stripe, for their convenience and speed, a minority of passengers used it.

Data from CTA for January to July 2013, representing 1.6 million average weekday rides.

Magnetic Stripe: 75%
CCP & CC: 19% (17% & 2% respectively)
Bus Cash: 6%

Ventra? 69% this week.

CDOT misses the lesson on open data transparency

December 9, 2013 / / 2 Comments

Publishing the wrong measurement as a PDF isn’t transparency.

The Chicago Department of Transportation released the first progress report to its Chicago Forward Action Agenda in October, two and a half years after the plan – the first of its kind – was published. I’ve spent an inordinate amount of time reading it and putting off a review. Why? It’s been a difficult to compare the original and update documents. The update is extremely light on specifics and details for the many goals in the Action Agenda, which should have organizational (like record keeping and efficiency improvements) and public impacts (like figuring out which intersections have the most crashes). I’ll publish my in-depth review this week.

Aside from missing specifics and details, the update presents information differently and is missing status updates for the three to five “performance measures” in each chapter. It was difficult to understand CDOT’s reporter progress without holding the original and update side-by-side. I think listing the original action item, the progress symbol, and then a status update would have been an easier way to read the document.

The update measures some action items differently than originally called for, and the way pothole repair was presented, a problem for people bicycling and driving, caught my analytical eye.

CDOT states a pothole-filling performance measure of the percentage, which it desires to be increased, “patched or fixed within 72 hours of being reported” but the average, according to the website Chicago Potholes, which tracks the city’s open data, is 101 days*. The update doesn’t necessarily explain why, writing “the 72 hour goal for filling potholes is not always feasible due to asphalt plant schedules” and nothing related to the performance measure.

As originally written, the only way to note the performance would be to list the percentage of potholes filled within the goal time, at the beginning and in the update. This performance measure has a complementary action item – an online dashboard – which could have provided the answer, but didn’t.

CDOT published that dashboard this summer as a series of six PDF files that update daily and you can hardly call it useful.

Publishing PDF files in the day and age of open government data – popular with President Obama and Mayor Rahm Emanuel – is unacceptable. Even if they are accessible – meaning you can copy/paste the text – they are poor outlets for data given the nationally-renowned civic innovation changes that Emanuel has succeeded in establishing.

There’s another problem: the dashboard file for pothole tracking doesn’t track the time it takes to close a pothole request, nor the number of pothole requests that are patched within 72 hours. It simply tells the number completed yesterday, the year to date, and the number of unpatched requests. (I’ve posted the pothole-tracking file to Scribd because the dashboard [PDF] doesn’t work in Safari; I also notified city staff to this problem which they acknowledged over three weeks ago.)

The “Chicago Works For You” website reports a different metric, that of the number of requests made each day, distributed by ward.

I discussed the proposed dashboard with former commissioner Gabe Klein over two years ago. He said he wanted to create a dashboard of projects “we’re working on that’s updated once a week.” Given Klein’s high professional accessibility to myself, John Greenfield and other reporters, I’ll give him and CDOT a pass for not doing this. But Klein also said, “I’m really big on transparency and good communication. When I left [Washington,] D.C. our [Freedom of Information Act Requests] were dramatically lowered.”

I’ll consider the pothole performance measure and action item “in need of major progress.”

* For stats geeks, the median is 86 and standard deviation is ±84.

Why do speeding crashes in Chicago lead to worse injuries?

November 21, 2013 / / 6 Comments

Don’t git behind me. Photo by Richard Masoner. 

A discussion about Chicagoans’ proclivity for tailgating (on a post about speed cameras) prompted me to look at the prevalence of this in causing crashes. I looked at the three-year period of 2010-2012 first, mainly so the numbers wouldn’t be so large, and left this information in a comment. But considering the prerequisites* for a crash to be reported in this dataset, and my desire to compare two multi-year periods, I switched my analysis to the single four-year period 2009-2012.

2009-2012

Total crashes: 318,193. Total fatalities: 554 people.

Tailgating crashes

62,080 crashes, 19.53% of all crash types

Tailgating crashes, injuries breakdown:

  • Killed: .0012 (this represents the number of deaths per crash). 75 people died in these crashes, representing 13.54% of all deaths.
  • Incapacitating injuries: 8.53% (the average distribution of people’s injuries in all tailgating crashes)
  • Non-Incapacitating: 46.32%
  • Possible injury: 45.15%

The share of all crash types that are tailgating has increased steadily from 18.11% in 2009 to 20.79% in 2012.

Speeding crashes

10,339 crashes, 3.24% of all crash types

Speeding injuries:

  • Killed: .0118 (this represents the number of deaths per crash). 122 people died in these crashes, representing 22.02% of all deaths.
  • Incapacitating injuries: 15.55% (the average distribution of people’s injuries in all speeding crashes)
  • Non-Incapacitating: 51.95%
  • Possible injury: 32.50%

The share of all crash types that are tailgating has decreased slightly from 3.72% in 2009 to 3.02% in 2012. While speeding leads to fewer crashes, it leads to a greater incidence of death and serious injury. The probability of a speeding crash leading to at least one death seems to stay steady through the period while the probability of seeing a person with an incapacitating injury versus a different kind of injury varies more, but not so much in a range that overlaps the rates for tailgating crashes.

A future comparison at injuries should look at the top crash causes for death and serious injury.

N/A and Unable to determine crashes

237,729 crashes, 74.71% of all crash types

N/A and unable to determine injuries:

  • Killed: .0013 (this represents the number of deaths per crash). 305 people died in these crashes, representing 55.05% of all deaths.
  • Incapacitating injuries: 9.38% (the average distribution of people’s injuries in all N/A crashes)
  • Non-Incapacitating: 48.26%
  • Possible injury: 42.35%

Notes

Updated December 4, 2013

I updated the wording on how to interpret these numbers. For example, previously for “killed” there was a percentage saying this number represented the amount of crashes that had at least one death. This wasn’t accurate: the same number represents a rate of deaths per crash of that type. Injury percentages represent the distribution of injury types experienced by all the people injured in crashes of that type.

Reliability

Analyzing crash causes is not very reliable as 45.60% of the reported crashes in 2012 had “N/A” or “unable to determine” listed as the primary cause! The third and fourth most frequently ascribed causes were the two tailgating codes (described below). There are some crashes that had the one of these two causes in the secondary cause field but I haven’t calculated that.

Cause code descriptions

Each crash has two cause codes. For tailgating crashes I searched for reports where “failing to reduce speed to avoid crash” or “following too closely” in either the primary or secondary cause field (it’s possible that a report had both of these causes ascribed). For speeding crashes I searched for “speed excessive for conditions” or “exceeding speed limit” in either the primary or secondary cause fields.

Prerequisites

This data excludes crashes where there was no injury or no property damage greater than $500 (2005 to 2008) and $1,500 (2009 to 2012). You cannot compare the two datasets when you want to see a share of all crashes because the number of “all crashes” will be underreported in the second dataset.

Queries

These are some of the MySQL queries I used to get the data out of my own crash database (I’m figuring out ways to make it public, using a shared login). “Cause 1 code” indicates the primary cause of the crash according to the police officer’s judgement. “Cause 2 code” indicates the secondary cause of the crash according to the police officer’s judgement.

1. Crash cause reliability: SELECt count(casenumber), sum(`Total killed`), `Cause2`, `Cause 2 code` FROM `CrashExtract_Chicago` WHERE year = 12 GROUP BY `Cause 2 code`  ORDER BY cast(`Cause 2 code` as signed)

2. Speeding crashes: SELECT count(casenumber), sum(`Total killed`), sum(`totalInjuries`), sum(`A injuries`), sum(`B injuries`), sum(`C injuries`) FROM `CrashExtract_Chicago` WHERE (`Cause 1 code` = 1 OR `Cause 1 code` = 27 OR `Cause 2 code` = 1 or `Cause 2 code` = 27) AND year > 8

3. Tailgating crashes: SELECT count(casenumber), sum(`Total killed`), sum(`totalInjuries`), sum(`A injuries`), sum(`B injuries`), sum(`C injuries`) FROM `CrashExtract_Chicago` WHERE (`Cause 1 code` = 3 OR `Cause 1 code` = 28 OR `Cause 2 code` = 3 or `Cause 2 code` = 28) AND year > 8

4. N/A and Unable to determine crashes: SELECT count(casenumber), sum(`Total killed`), sum(`totalInjuries`), sum(`A injuries`), sum(`B injuries`), sum(`C injuries`) FROM `CrashExtract_Chicago` WHERE (`Cause 1 code` = 18 OR `Cause 1 code` = 99) AND year > 8