The beginnings of a very nerdy and exciting walkshed analysis of Cincinnati’s transit network

July 9th, 2013

After more than a month spent casually fooling around with PgRouting, a network analysis extension for PostGIS, I finally have all the dependencies sorted out and the program successfully installed! Basically, this will enable calculations like finding the shortest path between two points, solving traveling salesman problems, and most interestingly for us, calculating the minimum cost/distance to any other point in the network. What all that means is that I can now make really cool maps like this that use actual street network topology rather than distance as-the-crow-flies to calculate travel times/distances.

Walking distance from the Ft. Wright transit hub

A depiction of the walking distance from the Ft Wright Transit Hub to anywhere, delimited with approximate one and ten mile bands(Just because I can!)

I promise you’ll have some very neat things to look at in the near future! I’d like to use this tool to finally get a solid idea of what areas around here are really accessible by convenient transit and not just seemingly adjacent to a line that’s either low-frequency or inaccessible by foot.

5 responses to “The beginnings of a very nerdy and exciting walkshed analysis of Cincinnati’s transit network”

  1. jonathan says:

    Very cool. I had a similar idea when I moved to Cincinnati. I wanted to understand where I could live and still get to work in 15 minutes. I would love to see this done for walking, biking, public transportation and driving. It looks like you have gone past just the idea stage.

  2. Tim Bender says:

    Really cool Nate. I spent a decent amount of time in OpenTripPlanner doing the same thing and have yet to see anyone who has done justice to the cost of transit frequencies in a static map.

    Simply people just want to look at a map and see how far they can go using transit. Well, it depends on what day of the week and what time of day. OTP allowed you to fudge a “within +/-[x] minutes of start time” but it still kept the user whimsically tied to a certain time of day.

    If your in-vehicle travel time on Route X for a particular trip is 15 minutes, but Route X has 60-minute headways all day, then your average trip travel time will be 45 minutes (1/2 x 60min + 15min). People need to see 45 minutes on average, not 15 minutes best-case-scenario. I’m not sure that OTP had the capability to visualize large periods of a day like this. But it should, and maybe PgRouting will allow this.

    Good luck. Would love to see more examples, and it would be amazing if you post documentation on implementation.

  3. Peter says:

    Did you ever figure out how to make PgRouting give you something back that looks like a travel shed? I’ve found it easy to find the distance between two points, but gave up a year or two ago when I tried to do a service area analysis with it.

    • Nate Wessel says:

      I did! Though not for transit just yet.

      The closest I’ve come to what I suspect you might be looking for is to use the pgr_driving_distance() function on each of a set of points that define access to something. This could be grocery stores(access to food) or transit stops(literal access to the transit system) or whatever. The basic idea is to loop through these points and
      1) select the nearest node in your network to that point. This is not super-accurate at large scales, but there are clearly are better ways to do it which i won’t get into. For small scales, this has been good enough for me.
      2) calculate the distance from that node to all others within a certain distance, say 1 mile.
      3) insert those nodes (those within one mile) and their minimum distance from their origin into another table.

      Once you’ve looped through all the access point nodes and saved the results, you simply run a query on the table you’ve been inserting into that selects the minimum cost for each identical node(of which there will be many if there is much overlap), and that node’s geometry. SELECT MIN(cost), geometry, FROM x GROUP BY geometry;

      From there, you’ve got each node in the network that is within one mile of an access point, and it’s distance to the nearest access point. And then it’s just a cartographic problem :-)