OSM2GMNS Software Badge
Travel models require explicit representations of roadway, transit, bicycle, and pedestrian networks. In travel modeling’s early days, these networks were drawn by hand, which resulted in coarse renderings of major roads, like freeways, and the exclusion of minor roads. Bicycle ways and foot paths are still not represented in many travel models. Digitization and the Census Bureau’s TIGER line files made things much easier. And today OpenStreetMap (OSM) serves as an invaluable resource for the urban planning community. In many regions in the United States and abroad, OpenStreetMap contains detailed descriptions of every road, most bicycle paths, and many sidewalks.
As we discussed in a previous Badge post about OSMnx, OpenStreetMap’s key short-comings in regards to serving the needs of travel modelers are as follows:
- it is not routable,
- the structure of its attributes are not aligned with travel models, and
- its attribute data is not sufficiently complete.
The OSMnx package elegantly solves the first problem, but does not address the second or third. OSMnx is for urban planners generally, but not travel modelers specifically. Enter OSM2GMNS.
Xuesong (Simon) Zhou’s team at Arizona State University, which included Jiawei Lu, the primary developer of OSM2GMNS, were inspired by our OSMnx post and created a Python package that first creates a routable extraction of OpenStreetMap (just as OSMnx does), and then exports the network to the General Modeling Network Standard (GMNS) format. GMNS is supported by Zephyr, with important financial and intellectual contributions from the Federal Highway Administration (FHWA). GMNS is a standard — in its infancy, but a standard nonetheless — for travel model roadway networks. We hope the travel modeling community continues to support GMNS. By exporting network data to GMNS, the OSM2GMNS package addresses the second short-coming of OpenStreetMap: it presents roadway network data in a manner familiar to travel modelers.
OSM2GMNS also provides reasonable estimates for the key network quantities that travel modelers need that are not consistently available in OpenStreetMap: roadway capacity, number of lanes, and free flow travel speed. These estimates are not always accurate, but by providing them, OSM2GMNS shows an awareness of what travel modelers need and creates a pathway to use the data right away — refinements to the capacity, speed, and number of lane estimates can come later. This feature addresses the third key shortcoming of OSM identified above.
Badging Details
The Software Badging process requires that Zephyr answer the following three questions about a software package:
- Is the software useful to the Zephyr Community?
- Does the software contribute to a common problem space or benchmark in a manner that encourages community progress?
- Is the software easy to use?
The first question is an easy and enthusiastic yes! OSM2GMNS builds on what OSMnx started in a manner that is tailor made for travel modelers — an important part of the Zephyr Community. By exporting the data directly to travel modeler’s format of choice in GMNS and by populating the key attributes needed by travel modelers, OSM2GMNS increases the utility of OpenStreetMap for the Zephyr Community.
We addressed the second challenge of contributing to a common problem space or benchmark in the OSMnx post. In that post, we suggested using Northwest Portland as the benchmark for network creation from OpenStreetMap. The idea being: if both OSMnx and OSM2GMNS address the common problem of creating a routable network from OpenStreetMap, how do we know if either is doing the extraction correctly? In the absence of a reference network, which would require a human to extract a routable network from OpenStreetMap, the best we can do is to compare the two extraction tools. If both tools give us the exact same result, it gives us confidence that both are doing the extraction correctly.
I have been noodling with some Python code to compare the same OpenStreetMap extractions used by OSMnx and OSM2GMNS. The results are similar, but differ in ways that are not obvious to me. I think it would be great for the community if the OSM2GMNS team performed this comparison: showing that the OSM2GMNS extraction for Northwest Portland is or is not the same as the one provided by OSMnx. Doing this would (a) provide a useful demonstration of how to use OSM2GMNS’s tools, (b) provide useful insights as to the reasons the tools give different results (if they do), and (c) give potential OSM2GMNS users confidence that the package is working as expected.
I have added an OpenStreetMap protobuf file for Portland along with a boundary file for Northwest Portland to our Software Badging Benchmarks repository. We welcome the community to use this small network to demonstrate how their OSM extraction tools work.
The third badger question goes to ease of use. OSM2GMNS has a straightforward set of APIs that are simple to use. I appreciate the OSM2GMNS team’s responsiveness in updating documentation and examples that I found lacking in my initial review. If the project gains traction, adding contributor guidelines and issue templates to the repository would be useful.
Ready to Get Started with OSM2GMNS?
The OSM2GMNS repository can be found here and the user’s guide is here. The tools basic capabilities can be readily explored using one of the several example networks included in the repository or the Portland file we identify above.
A Badge for OSM2GMNS
The Zephyr Badging committee is pleased to award OSM2GMNS version 0.5.2 an official Zephyr software badge.
Please get in touch if you have used OSM2GMNS in your work and your thoughts on our approach to badging software!
David Ory is a consultant with WSP, a founding instigator of the Zephyr Foundation, and chair of the Zephyr Software Badging Program Management Group.
