The birth of neighborhood shopping: inThirty

Hi, my name’s Brian Lange, and I'm a co-op student working at Datascope. This is the story of InThirty, my summer project and our submission for the Apps For Metro Chicago contest.

Early this summer, we brainstormed possible projects to kick off my co-op at Datascope. We quickly zeroed in on doing something with the CTA's treasure trove of open data and began filling the whiteboard with ideas. We talked about using the Train and Bus Tracker data to find out which stations caused the most slowdowns, and even considered hooking up sensors to our windows (which are right by the Red, Brown and Purple Line tracks) to gather our own data.

An idea that came out of those early talks that we really latched on to was the idea of “neighborhood shopping”. When you have to move to a city, how do you decide where to live? Could picking a neighborhood to live in be as easy as picking out a TV on Newegg? We started to study some fantastic sites that partially address this question like NabeWise and WalkScore, and thought these sites could be improved upon by (i) allowing a user to choose their interests, and (ii) bringing more data into the equation.

I started off on the "neighborhood shopping" project by learning some Python (using Mark Pilgrim's Dive Into Python — a great resource if you're looking for one) and writing some short scripts to experiment with various modules and web APIs (like Yelp). These were early prototypes, but some of these scripts are still being used in our current implementation.

After getting my feet wet, I turned towards the network science that is at the core of much of what Datascope does. The CTA transit system is a classic example of a directed network (so classic, in fact, that it was my professors' example in my Data Structures course at Northwestern. Shout out to Professor Horswill!). The train and bus stops act as the nodes of the network, and the edges connecting the nodes each have a travel time that acts as the weight. This network formulation makes it easy to apply some pretty cool algorithms to find the shortest path between any two stops, much like Google Maps.

It was around this time that we stumbled upon the Apps for Metro Chicago contest and decided we could enter our “neighborhood shopping” app. We started looking through the city data portal and decided parks would be something people would probably like to live near, and the city's park database gave us everything we needed. So after learning some basic Django web framework skills, I made our first iteration web app: ParkScore. Users could put in an address and choose a method of transportation, and ParkScore could tell them how many acres of parks were nearby and show you where they were. Relatively simple, but once again, an important part of our implementation today.

This “score” concept was great if you knew an address, but what if you didn't? Well, if you can find a score for one point, you can find it for many. We calculated “park scores” for over 30,000 points across the city, and then found the average score for each Chicago neighborhood by averaging the scores of each point inside that neighborhood's borders.

Once we had this data, we needed a way to display it. Inspired by some other map-based web apps like Mapnificent and Trulia, we decided on a minimal, map-only interface with a color coded heatmap overlay to show the neighborhood's average “scores” at a glance. At this point we had our current app and submission for the Apps for Metro Chicago contest: InThirty.

It's been a journey and a great learning experience already, and there are lots of features and data sets yet to be added that will bring InThirty closer and closer to our initial vision of a "neighborhood shopping" app. Check it out, leave feedback or requests in the comments below, and stay tuned — we'll know by Friday whether InThirty is a Transportation Round finalist in the Apps for Metro Chicago contest.