We recently launched “A day in the life of Nice Ride bikes,” an interactive animation showing what a typical day of Nice Ride use is like in the Twin Cities. It was a very technologically intensive piece and was a first on many accounts for our team.

As always, we started by thinking about what questions we wanted to answer and what ideas to convey. Tom had come across the data a couple months back and we knew we wanted to do something with the data, as pretty much the whole interactive team commutes by bike. We were inspired by Brendan Slotterback’s map of routing density, but wanted to go with a more interactive approach. I also wanted to experiment with animations and saw bikes riding around a map, and so we came up with the idea of trying to model what a typical day would look like.

[cms_ad]

Nice Ride data

Nice Ride released its 2011 data in February of 2012. This data included the names and locations of all the stations, rental and demographic data on all casual and regular subscribers, and all trips that were taken in 2011. The trips described the start stations, the end stations, as well as the start and end time of the trip. Nice Ride did not track the actual routes of the trips, as there are not GPS units on the bikes.

Analysis: Getting to usable data

Creating an animation of bike trips in a day with only start and end points meant we first had to determine the likely routes for each trip. 

To do this we first needed a database of all the streets and bike lanes in the Twin Cities. Fortunately, there is already a free database of all this information from Open Street Map.  Open Street Map (OSM) is a wiki for the world’s geographical information, like roads and waterways. The first step was to get the OSM data into a local database to work with using just parts of the data provided by metro extracts (as the whole planet is about 500GB of data).  The next step was to find a way to create routes between stations that were weighted for bicycling. After attemping to use pgRouting for this and failing to get everything setup properly on my Mac, we went with Routino to produce these routes.

A smaller piece of the visualization is the route layer which shows all the routes that were taken in 2011, weighted by popularity (how many times it was taken). After we had our modeled routes in our database, it was easy to use TileMill to produce a tileset of those routes and stations. We even added in a bit of interaction where you can click or hover on stations to find out their name.

When thinking about how to actually make an average day of bikes, we brainstormed a bit and determined that the most efficient way was to find the “most average” day of 2011 and model that instead of trying to build a day from scratch. We found that average day by looking at bike density per 5 minute periods (you can see a graph of this at the bottom of the piece, which we will go over more below). Then we went through every day and found how different from the average it was.  The “average day” turned out to be May 18, 2011.  For those wondering, the least average was July 04, 2011, which had a very high bike density. 

We now had all our data; exporting all of it to JSON(P), a popular data standard, meant we could use it easily in our application.

Bringing it all together

Armed with the usual technology stack of jQuery, Underscore, Leaflet, and Wax, it was straigtforward to get an interactive map together to show off our base maps and the routing layer we produced above. The next thing we needed was a way to animate each bike route as well as keep track of the day as it progressed.  After looking at a number of different libraries, Animator.js was the best fit. Even though it’s a bit old, it was very lightweight with a straightforward API.

The final bit was to make a progress bar of the animation, and nothing would be better than showing off the bike density data that we calculated earlier. Using flot, we were able to put in the graph of average bike density and use the crosshairs plugin as the progress bar for the animation. With a few controls on top, we were done.

As always, all of our code for this project is open source and available on GitHub.  The README file explains how to get all of this running locally if you wanted to extend it.

This dataset has a lot of great detail and we hope to explore more of it, as this interactive only scratches the surface. We also hope that Nice Ride MN will continue to release their data as often as possible and in friendly formats.

Join the Conversation

2 Comments

  1. Routino versus pgRouting

    Very slick, Alan. What troubles did you have getting pgRouting going? I’d like to talk to you more about Routino. We’ll soon be developing a route simulation tool for our fire department clients.

Leave a comment