OSMnx Software Badge

David Ory
zephyrfoundation
Published in
7 min readNov 18, 2020

A key feature of a travel model is an explicit representation of space. Meaning, it locates the travel of individuals (or collections of individuals) to a series of specific locations, e.g.: starting at home, traveling along the interstate, ending at work. In order to locate travel as it moves between locations, travel models require an explicit representation of the transportation system.

OSMnx Extraction for Oakland, California

This requirement has been in place since the early days of travel forecasting. In the absence of digital maps, simplified roadway networks were first created by hand. Over time, travel model networks have been derived from numerous sources, including centerline files maintained by state departments of transportation, the Census Bureau’s TIGER/Line files, and, more recently, base maps maintained by commercial vendors such as TomTom and HERE.

OpenStreetMap has been a theoretically-appealing option for creating travel model base maps since its creation in 2004, as it is “open”, and many purveyors of travel models prefer to distribute their networks freely to the public and stakeholders. Practically, however, OpenStreetMap has not been useful for at least the following reasons:

  1. it is not routable,
  2. the structure of its attributes are not aligned with travel models, and
  3. the attribute data is not sufficiently complete.

The OSMnx package created by Geoff Boeing elegantly solves the first of these problems.

The purpose of a travel model network is to predict the routes taken by vehicles when moving from one location to another. To route vehicles, a network must be constructed of links and junctions. Vehicles traverse links and move from one link to the next, making turns as necessary, at junctions. This is a routable network. OpenStreetMap’s design is based on edges and nodes, where an edge is a line and a node is a location on a line; a node need not be a junction. This representation is not a routable network.

OSMnx is a Python package that extracts an arbitrary selection of OSM data and creates a routable Python networkx object. OSMnx is not the first software package to create a routable network from OSM specifically or an edge-based graph generally. ArcGIS’s “Network Analyst” tool has long served this purpose in the GIS community and many of the commercial software packages used by the travel model community do this as well. However, OSMnx is the first open source package we have used that solves this program using the modern Python libraries many travel modelers prefer, paired with a dead-simple application programming interface (API). In short: it does exactly what we need, is readily accessible, and is easy to use.

Because OSMnx solves one of the three key problems with OSM, it mitigates the friction of using OSM as a roadway, cycleway, and/or pedestrian travel model base map. This is important because many in the travel modeling community work for governments and many travel modeling work products are intended for public consumption. OSM is a base map created, maintained, and used by the urban planning/mapping community and using it allows travel modelers to better engage with our community. Specifically, it allows travel modelers to (a) directly share the information in their networks with other OSM users and (b) sets the stage for us to contribute back to the OSM community by adding/correcting OSM attribute details.

The Zephyr Foundation’s Software Badging project management group generally encourages open source software projects to go through our process to obtain a software badge. In the case of OSMnx, the usefulness of the tool and quality of the product motivated us to reach out to Dr. Boeing and ask him to submit the project to our program. He was kind enough to do so; we thank him for the submission and for creating OSMnx.

Badging Details

The Software Badging process requires that Zephyr answer the following three questions about a software package:

  1. Is the software useful to the Zephyr Community?
  2. Does the software contribute to a common problem space or benchmark in a manner that encourages community progress?
  3. Is the software easy to use?

The first and third questions are readily answered for OSMnx. As discussed above, creating an easy-to-use pathway for travel modelers to use OSM as their base map is useful and may prove to be important. The Python implementation, open source license, and simple API are attractive features.

Ease of Use?

The OSMnx software has unit testing, robust documentation, and clear contribution guidelines. At the time of writing, it has been downloaded over 280,000 times, received direct contributions from 45 developers (and many more on various derived versions of OSMnx), and is a requirement for nearly 500 other Python packages. OSMnx is, therefore, demonstrably easy to use.

Contribute to common problem or provide a benchmark?

The second question is more challenging in the context of OSMnx but important to the Zephyr Software Badgers. In order for us to, as a community, make systematic progress, we must engage with each other. Excellent software should engage in a community working to solve a common problem. If we do not work towards solving common problems, progress is hindered or at least inefficient. The problem OSMnx solves for the travel modeling community is the creation of a routable network from OSM. Ideally, OSMnx would use an accepted benchmark to demonstrate that the network it is creating is a reliable and faithful translation of OSM’s edges and nodes into networkx links and junctions. Unfortunately, no such benchmark exists and it would be tedious (and bizarre) for someone to create and maintain one. In the absence of a benchmark, how can users of OSMnx know that it is doing what it purports to do?

The practical answer to this question is that many of us have downloaded OSMnx, used it, and confirmed, anecdotally, that it does what it says it does. We then tell our friends and others use it, confirm it does what it says it does, and on and on. The large number of OSMnx users suggests that it works as intended. But it would nonetheless be useful to confirm this more rigorously and doing so may have the ancillary benefit of setting a community standard for OSMnx and other tools that aspire to do the same thing.

Northwest Portland as the Community Standard

In Dr. Boeing’s journal article introducing OSMnx, he used Portland, Oregon to demonstrate the package’s features. Following his lead, we suggest using the northwest sector of downtown Portland, Oregon as the community standard for tools that translate OSM into a routable network.

As noted above, there is no canonical representation of OSM as a routable network created by a reliable, human expert. We cannot, therefore, confirm the efficacy of OSMnx against this standard. We can, however, compare the OSMnx extraction of OSM for Portland with the extraction conducted by SharedStreets. SharedStreets is a software effort founded by Kevin Webb to create a canonical reference system for maps. Such a reference system could be used to conflate maps from numerous sources of information and, over time, allow such conflation to be trivial (whereas today it is expensive). The SharedStreets reference system is based on a link and node system and on OSM. It therefore creates a routable version of OSM in order to create canonical references of links and nodes.

The Zephyr Badgers wrote software to create a routable network of the northwest sector of Portland using OSMnx and SharedStreets. We then compared the representations, specifically the OSM node IDs attached to each OSMnx and SharedStreets links. Mechanically, this process is easy to do with these two toolkits. Unfortunately, the SharedStreets project is no longer updating its tile sets (nor the software used to create its tile sets), so the SharedStreets extraction relies on a dated extraction of OSM. We cannot, therefore, do an apples-to-apples comparison using the same OSM information. The apples-to-oranges comparison, i.e., using the default OSM information for both tools, resulted in a match rate of about 76 percent over the ~12,000 links in the area, with the differences in places where the underlying OSM information has changed.

Matched (green) and Un-matched (Maroon) Links from OSMnx and SharedStreets Extraction of OSM

Moving forward, we recommend that OSMnx publish a “standard” translation of OSM so that other efforts, including SharedStreets, and potential users, can more easily compare extractions across tools.

Ready to Get Started with OSMnx?

If you’re ready to get started with OSMnx, one place to start is Geoff Boeing’s blog entry documenting OSMnx’s key features. OSMnx also has robust documentation of its APIs and several example Jupyter notebooks.

A Badge for OSMnx

The Zephyr Badging committee is pleased to award OSMnx version 0.16.1 an official Zephyr software badge.

Please get in touch if you have used OSMnx in your work and your thoughts on our approach to badging software!

David Ory is a Managing Director at WSP, a founding instigator of the Zephyr Foundation, and chair of the Zephyr Software Badging Program Management Group.

The Zephyr Foundation is a venue through which leading researchers and practitioners seek to develop and implement travel analysis methods and tools that are demonstrably more valuable, credible, transparent, tractable, reproducible, and usable in order to support public policy decision-making that is inclusive and promotes equitable outcomes, shared prosperity, and sustainability. Contact us if you’re interested in learning more about other Zephyr projects.

--

--