Over at the City of Bend, Oregon, where I work, we’re in the early stages of crafting a 20-year transportation plan. We knew we wanted to use accessibility indicators to analyze and compare future scenarios and potential transportation projects, but we weren’t sure exactly how to go about doing that.
With so many articles on accessibility mapping popping up, Bend can’t be the only city out there that’s looking around and wondering how to go about measuring this for ourselves. This post shares what we learned in the hopes of giving a headstart to other cities in a similar boat*.
*or car or bus or bike. #youdoyou
There are a lot of shiny tools out there. They all look great when they pop up in my email feeds (and I’m sure they all have nice-looking websites) but what approach would actually fit our needs? Especially for a smaller city that doesn’t have the resources of a metro area like Seattle or New York. We surveyed several different tools and workflows to see how they work and what would make sense for us.
From a user’s perspective, here’s my review of:
- Urban Footprint
- Conveyal Analysis
- Bicycle Network Analysis, by People for Bikes
- The hammer method: QGIS and Postgres
- Fun with Python: OSMnx (coming soon)
- The more expensive hammer method: ArcGIS (coming soon?)
Some of these are out-of-the-box solutions that don’t require GIS skills. Others are raw code or require some experience working with data from OpenStreetMap, a free, editable, mostly user-contributed map. I’ve noted the skills required. I’m sure there are other methods out there —use the comments section to add a link to a user-friendly explanation or write up a short blurb.
I’m modeling transportation scenarios for 2040. The goal is to use employment accessibility to compare the impacts of different investments in transportation infrastructure and services — being able to answer questions like, “How easily would our future population be able to access future jobs if there were new roads, new bike facilities, and transit lines with reduced headways?”. This means I needed a tool that could take a lot of custom data inputs (but this post should be relevant even if you don’t have those requirements).
I wanted a tool that could answer “yes” to the following questions:
- Can it model a variety of modes?
I want to calculate separate metrics for pedestrian, bicycle, auto, and transit accessibility.
- Can I feed it custom population and employment data?
I’m modeling a 2040 future state, so I don’t want to use current census data. Bonus points if these inputs don’t have to be aggregated/disaggregated to a particular geography (e.g. I want to be able to feed it the best data that I’ve got, whether it’s at the tax lot, census block, or TAZ-level)
- Can I feed it custom transportation inputs?
I want to be able to model new roadways, particular bike/ped links, and modifications to transit routes and headways. For bikes, I want to restrict the network so that I’m only routing people on connections with a low level of traffic stress (LTS). For pedestrians, we have a patchy sidewalk network so I want to restrict the network so that we’re not routing pedestrians on busy roads without sidewalks.
Extra bonus points go towards tools that are easy to work with, cheap or free, quick to run, and have friendly support.
What it is: SIM-city-like planning software that runs land use scenarios, calculates accessibility, and enables planners to answer “what if…” questions, without having to pay a fortune to consultants and wait for someone else to run a model. Freedom!
How it works: Urban Footprint charges an annual subscription fee. This was pretty darn affordable (around $6k/year) and surprisingly low for what you get for that cost. I’m not sure how these guys make any money, tbh. The fee is lower if you contribute data back to Urban Footprint. You also pay a one-time fee for UF staff to get your “canvas” ready so that it’s up-to-date with accurate land use data. Or you can just use their base map data and not pay the customization fee. Bend is experiencing a growth boom so the canvas didn’t seem totally accurate for us; we would have wanted to customize it to account for a ton of new development. Your mileage may vary.
Nerd factor: Zero. This is intuitive and user-friendly for folks without a GIS background. This would be a great tool for staff who want to be able to view, share, and play around with data analysis without needing specialty software. The support team is friendly and helpful. Some GIS experience is needed for whoever is preparing the input data to send to UF.
What it does well: This struck me as a pretty high-powered tool that combines land use and transportation analysis in one platform. There are a ton of different features and capabilities in here. UF can currently calculate pedestrian, transit, and auto-based accessibility. In addition to employment accessibility, it can calculate accessibility to other destinations like schools and parks. Bonus points for having a 30-day demo so you can see whether it would fit your needs.
What it doesn’t do (currently): UF’s user interface can’t currently run scenarios with custom road networks*. It uses current OpenStreetMap (OSM) road data and publicly-available transit data (in GTFS format). There wasn’t a way that I could customize these inputs in order to input my own roads data or restrict bike analysis to low-stress facilities. The development team told us that this could be possible with some customization ($ ?), and these features could be available in the future. If you’re just running scenarios with current road networks, you should be fine, but you should make sure the OSM data for your area looks complete. Notes on that at the bottom of this page.
UF’s interface is a little clicky but I’ll gladly accept that in return for a bunch of capabilities.
*Behind the scenes, there is a ton of additional capabilities, they just aren’t surfaced in the user interface (yet?). This presentation gives more info.
Other comments: We had some niggling concerns about the data customization process. Legally, we can’t hand over our most detailed employment data to a third party, so we would need to aggregate the data before sending it. The routing engine had pedestrians jumping across a narrow canyon and fording a river in one part of town, but this type of issue occurs only under very particular geographic circumstances and is common to a lot of routing engines; it seems to be a downside of more detailed analysis. We could have just manually adjusted the results in the output data.
Overall: I really liked this one. It didn’t meet our needs for this particular project because we needed so many custom infrastructure inputs, but it could be really useful for other applications.
What it is: Elegant software tool designed to help planners evaluate changes to public transport systems using accessibility indicators.
How it works: Conveyal sets up your data in a hosted version of this tool and guides you through how to use it. Contact them for pricing (we didn’t, so I can’t weigh in there).
Nerd factor: Using the hosted version of this tool, the nerd factor is zero: very intuitive, no special knowledge or experience required. Instead of logging into the hosted version of this tool in a web browser, I installed the whole system on my laptop using the open source software code that Conveyal releases, so the nerd factor was very high. I recommend the front-door approach instead. Once you’re using this, you would need some experience working with OSM data and GIS if you wanted to analyze custom road networks.
What it does well: This was designed to model changes to public transportation, and oh boy does it do this nicely. Analysis takes GTFS transit data and uses it to visualize your local routes; the interface lets you interact with these to modify your network. It’s really elegant. Also, Analysis lets you input your own road network data (in OpenStreetMap’s PBF format), which means I could input future transportation networks to model future roads or restrict bikes to low-stress facilities. Prepping these data inputs required some time and effort. Inputting custom future land use and population data was straightforward, and it will grab 2014 census data for you. The calculations run really, really quickly.
This tool also gave me a variety of outputs: isochrones, grid files, graphs, and an overall metric (e.g. In X mins, Y% of Bend residents can reach ##### of jobs). Instead of just returning the result I asked for, it includes sliders so that I can adjust the X or Y up or down. Results can be downloaded as a raster.
What it doesn’t do (currently): This is a more specialized tool than UF, so it’s not the place to look for a general land-use-and-transportation-analysis tool (fine by me — that’s not what I was looking for right now). I’m not sure how I would calculate access to land use parcels like parks or hospitals, but I bet this is something Conveyal could talk through. There is some work-in-progress on adapting this to analyze low-stress bike facilities, but that’s not available yet.
Other comments: Conveyal has great blog posts that summarize their thinking about accessibility. Prepping input data made me think about how hard it is to blend OSM data with city shapefiles, and the need for tools to help with this.
Overall: This is what we ended up using — it got the job done and was faster and easier than developing our own analytics methods. This would be especially good for a transit agency (that’s what it was designed for, after all).
What it is: TBEST (Transit Boardings Estimation and Simulation Tool) is an ArcGIS-based transit tool currently being explored by the Oregon Department of Transportation. TBEST has many detailed public transit analysis capabilities and it can analyze accessibility for public transit.
How it works: This software can be downloaded (for free) and used in conjunction with ArcGIS. It uses an input road network, demographic information, and GTFS data provided by the user.
Nerd factor: Low, assuming some familiarity with ArcGIS. There are training materials on their website that walk through the specifics of what TBEST does and how to use it.
What it does well: Facilitate transit planning, with very detailed analysis. TBEST can develop and run future transit scenarios, forecast future ridership, act as a GTFS editor, and facilitate analysis of demographics, land uses, etc. that are in close proximity to transit. Accessibility analysis along transit lines is evaluated based on the routes, stop, and schedule. TBEST can also calculate more detailed metrics, like point-based accessibility based on the number of transfers required.
Other features: TBEST allows for integration and editing of local socioeconomic datasets (examples: MPO TAZ files containing base and future-year socioeconomic distributions, datasets from a regional travel demand model, parcel-level land use data with time-of-day person trip activity-levels calculated for each parcel. The parcel data is supplemented with a parcel-editor which allows planners to modify base year parcel distributions to represent future-year development.)g
What it doesn’t do: Accessibility for other modes. Accessibility for pedestrians getting to/from transit is analyzed based on a distance-buffer rather than along the road/pedestrian network. In other words, this tool currently tells you what’s near a transit stop, not necessarily what’s reachable from a transit stop. Auto and bike accessibility analysis are not currently supported in TBEST.
Overall: This wasn’t a fit for what I was looking for, since it didn’t address all modes. It could be a robust tool for transit agencies looking to better understand and model their transit network and potential future states.
What it is: An infrastructure-based estimate about the level of traffic stress (LTS) on road networks in hundreds of American cities. Want to consider this as part of your bike analysis but don’t have LTS data? This could be a useful estimate. This also calculates a variety of accessibility metrics ***but they are only as accurate as the completeness of your OSM data for amenities and attractions***
How it works: People for Bikes used OSM data to make inferences about the level of traffic stress on road networks based on particular OSM tags, and they applied it to cities across the US. Analysis was done by Toole and Azavea, who were amazing about documenting the heck out of their methodology and who also published their weightings and source code. If you’re more of a visual/audio person, here’s a conference talk about their process.
You can download the calculated LTS networks from the site.
What it does: If you’re lucky and your city is on the list, you can export the bicycle network data for use. It also calculates a whole pile of accessibility metrics, but please read the cautions below.
What it doesn’t do: The accessibility metrics are based on the amenities, etc, currently in OSM. For a city like Bend, which has… well… not all of its amenities mapped, these could be misleading. For a city that’s been mapped in great detail, this could save you a lot of time and do the calculations for you. Happy medium: Use the network and run it against your own jobs/amenities data.
Overall: We had our own, city-specific LTS data from a previous consulting contract and staff input. We didn’t use this, but it could be valuable for others.
What it is: A hacky method to use free tools that don’t require a special user interface, vendor fees, or anything involving a contract. This will use the same approach as the specialized tools above — calculate point-based accessibility, iterate over an “analysis-area” grid, weight the results by population. The difference? You get to do every step of the calculation yourself and wait a while for it to run.
How it works: Chris Kohler wrote this QGIS Planet guest post. It had the blessing of Anita Graser (patron saint of QGIS) so it seemed like a great place to start. This will generate drive-time isochrones and could be adapted to bike and ped applications. This needs to be run over an analysis grid and weighted by population in order to calculate employment accessibility for X% of the population.
Nerd factor: Very high. This one requires GIS knowledge and experience with open source packages — it’s not just a case of having QGIS running, but of dealing with Postgres and command line tools.
What it does well: Avoids specialty software and vendor contracts. Free. Forces you to understand the analytical processes. Allows for endless customization of inputs.
What it doesn’t do: Chris’ blog post doesn’t address transit. This is a harder problem since there are routes, stops, and schedules involved in transit. I’m pretty confident there’s some sort of QGIS plug-in that would handle this if you spent some time digging into it, but I can’t make promises.
Overall: This was our back-up method and I’m really glad we didn’t have to use it. The more steps there are, the more opportunities to get something wrong… but the more you can really customize the analysis. Do you like geeking out in a dark room with only the light of your computer monitor? This one might be for you (not judging).
Honorable mention goes to this tool, which looked really useful but I didn’t have time to test yet.
How it works: This is a python-based tool with good documentation. It could be used for accessibility analysis and a host of other applications.
Nerd factor: Very high. This is more straightforward/automated than calculating isochrones in QGIS. But it’s got a bunch of dependencies. Probably more time on the set up, less time on the analysis.
What it does well: Avoids specialty software and vendor contracts. Free. Forces you to understand the analytical processes. Allows for endless customization of inputs. More automated than the QGIS method.
What it doesn’t do: This doesn’t address transit. Again, I’m pretty confident there’s a way to would handle this if you do some digging for other tools.
Overall: This was another back-up that I didn’t have to use, but kind of wish I had, and plan to come back to.
What it is: Our IT department would be much happier if we used an ESRI-based solution. If you’re at a city government, then your IT department probably has similar feelings. Network analysis features don’t come standard with an ArcGIS license and for some reason, we haven’t got the extension. We put in an internal request for this. Check back in a few months…
A caveat: Our city roads data is not built as a routable network so additional work, open source tools, or OSM data may be required to make this solution work.
Other comments: It seems like there’s a sometimes-vast gulf between the OSM/open data community and public agencies (like mine) that are really set in the ESRI path. I’m learning that no matter how great a tool is, it just won’t be accessible for a lot of agencies unless it can be somehow made compatible with ArcGIS. Some tools achieve this by having results that can be downloaded as raster data. Other tools (like the Python method) would be a lot more usable if there were a clear way to use this within ArcGIS (no command line tools required).
Notes: These views are entirely my own and do not represent those of the City of Bend. Thanks to Seth Fitzsimmons for helping me get a couple of these tools up and running .