For the last two years, I’ve mapped the flows of the Nice Ride bikes. I’ve always been slightly dissatisfied with the results, since bikes were obviously shown taking routes that any sane Nice Rider would never take (Hennepin Avenue between Lake and the bottleneck, for example). Try as I might, I could never get ArcGIS to prioritize trails, lanes and bike boulevards sufficiently.
Enter the good people at Cyclopath. Cyclopath is something like a bike route wiki, in that it is constantly updating it’s database of bike routes using ratings from users. So every street in their database has a rating from bad to awesome (actually 0 to 4). And this database includes the whole metro and beyond. Best of all, they were willing to share it!
The latest version of ArcGIS has a new “restriction preference” setting, meaning there are six levels of preference for a link from “Highly Avoid” to “Highly Prefer”. So I combined cyclopath’s street ratings with these preference settings and got a new and better route analyzer. Here are the results:
As a reminder, here is what the old version looked like:
A few changes of note:
Hennepin is obviously not so popular anymore, save in downtown where there are more Nice Ride Stations.
The Cedar Lake Trail got a little more popular, perhaps 500 trips in some locations, since it was a Highly Preferred route.
West River Parkway south of the Washington Avenue bridge got a lot less popular (although crossings at Franklin stayed nearly the same).
There is generally just a lot less jigging and jogging on small streets as trips tend to condense onto major routes (see the major difference on Summit Avenue in Saint Paul).
Here is a version with a base street map for orientation:
Minnpost has taken my concept of mapping Nice Ride data to new heights. They’ve produced an animation of a 24-hour period showing where bikes navigated. I haven’t figured out how to embed the animation, so you’ll have to click on over.
For the mapping nerds: they used Routino, which I never figured out how to use, rather than ArcGIS with Network Analyst.
Google has a pretty cool labs project called Fusion Tables, which I think most people don’t know about. One great feature is the ability to create a web map from georeferenced data quickly and easily. Great news, it’s getting even easier. From Steven Vance, news that you can now upload shapefiles (through a third-party site).
It is now possible to upload a shapefile (and its companion files SHX, PRJ, and DBF) to Google Fusion Tables (GFT).
Before we go any further, keep in mind that the application that does this will only process 100,000 rows. Additionally, GFT only gives each user 200 MB of storage (and they don’t tell you your current status, that I can see).
Login to your Google account (at Gmail, or at GFT).
Prepare your data. Ensure it has fewer than 100,000 rows.
ZIP up your dataX.shp, dataX.shx, dataX.prj, and dataX.dbf. Use WinZip for Windows, or for Mac, right-click the selection of files and select “Compress 4 items”.
Visit the Shape to Fusion website. You will have to authorize the web application to “grant access” to your GFT tables. It needs this access so that after the web application processes your data, it can insert it into GFT.
If you want a Centroid Geometry column or a Simplified Geometry column added, click “Advanced Options” and check their checkboxes – see notes below for an explanation.
Choose the file to upload and click Upload.
Leave the window open until it says it has processed all of the rows. It will report “Processed Y rows and inserted Y rows”. You will be given a link to the GFT the web application created.
Here is a web map I made of Minneapolis bike count figures over time, the old fashioned way (geocoding by hand). You could also get this to work before by exporting KML from ArcGIS an importing it into Fusion Tables, but that was clunky and had inconsistent results. Google should incorporate this quickly, if they want to keep up with what you can do with ArcGIS Online.
On-street bike parking at the Birchwood Cafe in Seward
New American Community Survey data is out, which gives us the first look at Census Tract-level data since 2000. I pulled out some transportation data for the Twin Cities metro, and previously looked at trip-to-work mode share changes for the region. Cycling and telecommuting showed gains, carpooling and driving alone showed losses.
These small changes don’t seem that interesting, until you start to dive into the data. Since cycling gained mode share, it’s worth exploring in more detail where these gains are happening. Are the gains happening uniformly across the metro, or in specific areas? What places have the highest bicycle mode share? What do the changes mean for infrastructure and transportation planning? Attempts at answers are after the break. Continue reading →
Mapnificent answers this question by drawing travel-sheds for trip lengths you select. They dynamic slider to change trip travel time is really cool. You can also change the settings to include biking to/from stations (rather than walking) and you can compute the intersection between two or more travel sheds.
I’d love to see them add bike and car travel sheds to this map. Presumably the data could be pulled from Google in the same way as transit information. Pairing this information with NAICS data could provide a really powerful accessibility map.
One drawback (at least for the Twin Cities), they don’t appear to have any data for opt-out transit services (Southwest, MVTA, etc).
In my first post on the two potential Southwest Transitway alignments, I discussed the density of population, employment and transit dependent populations along each route. In this post, we’ll explore land use patterns and the mixing of uses along each route and near the stations. Click through for more.
I’ve never written a long post about my opinion on the Southwest Transitway LRT alignment alternatives, although I have participated in some intense discussion on the City of Lakes Urbanism blog. I cynically believe that the routing decision will probably be made based solely on the numbers that allow the line to compete for federal dollars, rather than the best long range planning, but that won’t stop me from adding my two cents and possibly rousing rabble at the upcoming meetings.
When comparing the 3A and 3C alignments (Kenilworth Trail versus Uptown), the question for me has never been how easy is it to engineer and build (Kenilworth wins this one every time), but who will the line serve, or in other words, what is its purpose? Is it a commuter line to get people from the far-flung suburbs to downtown Minneapolis rapidly a la Northstar, or is it an urban transit line a la the Hiawatha line? 3A represents a commuter line that would serve suburban customers and move them to downtown quickly, mostly bypassing any housing density, retail or transit-dependent populations. 3C would serve the “second downtown” of Minneapolis, Uptown, as well as some of the most dense housing, large employment centers and more people who depend on transit to get around. In short, missing one of the most vibrant activity centers in the Twin Cities because you have an easy right of way would be a huge mistake.
Before I get too deep into a rant, I want to share some maps that I think illustrate the point. I assume the data behind these maps has been factored in to the alternatives analysis, but I guess we’ll have to wait until August to find out.