Visualizing Gaps in OpenStreetMap Data and why Routing for Bikes, Scooters and Wheelchairs is so bad
(Direct link to data visualizer: https://osm-viz.fly.dev )
TL;DR
This application is meant to highlight what we perceive to be a problem in the digital map of the world – the map that all major map products (Apple Maps, Tesla onboard navigation, …) as well as all boutique map products (Pointz, Komoot, …) use as their underlying source of data. Even Google, a company that seems to have "infinite data" (not OSM data), offers cyclists and other micro-mobility users frustrating and even dangerous routes.
The problem is that, for any applications that are not car routing, the data used to achieve the task are usually abysmal – even where they are good in quality, the data are patchy and incomplete. If you are already very familiar with OpenStreetMap, its structure, how it’s used, and all of the ways in which it falls short, you will probably see immediately what our web app (linked above) is all about and exactly what it shows. If not, the rest of this article will try to guide you through an orientation.
A note: the data visualized in this app was pulled from the OpenstreetMap database on 19 Aug, 2024. OSM is the mapping foundation for map-based products like Tesla self-driving, Mapbox, Strava, All Trails and many other companies with >$1,000,000,000 valuation.
A motive
For the two of us, a bicycle is our primary means of transportation – we use it to commute to work, to bring home groceries, to visit friends, and anything else. Like everyone who needs to go anywhere, we also use a mapping app on our phones to figure out how to get from here to elsewhere. However, unlike most people who get around primarily in cars, we have been sorely disappointed at being directed to hop a fence to jaywalk across four lanes of 40-mph traffic when we request a bike route (this is a lived experience).
It doesn't have to be this way, of course. Car routing was terrible years ago but today Google and Apple can instruct me to use the second-to-rightmost lane to take the next exit because I’ll have to bear left 300 feet afterwards! If I’m in a car, I can press the green “Go” button and not think any more about where I’m going because Google and Apple know; all I have to do is follow their very precise directions (that usually interrupt the conversation I’m having with the person in the passenger seat; who’s getting all of my attention because I don’t have to pay any attention to where I need to turn, or when I need to get in the next lane; because Google and Apple have that covered).
But if I’m on a bike, or if I’m walking, when I press the green “Go” button I get a banner at the top of the directions (on Google) that warns me to use caution because the directions may not reflect actual conditions! No kidding! You’re telling me to hop a fence and dodge 40-mph traffic across four lanes, when there’s a crosswalk with a walk signal 30 feet away? What gives?
We created this little webapp to visualize the data behind boutique bike navigation apps like Pointz Mobility, as well as big names like Apple and Tesla navigation. `
The tour
We are going to elide some details here, but there are some points that are important for context.
There is a thing called OpenStreetMap. OpenStreetMap (OSM) is by far the largest and most comprehensive database of map data in the world. It is open-source and available for anyone to use. It is also collectively constructed by either volunteers who contribute data that is of personal (or maybe civic, or other) interest to them, or by corporations who have a vested interest in some aspect of the map.
OSM represents the map of the world as a graph of nodes and edges (“ways” in OSM parlance). Generally, nodes are points on the map (buildings, bus stops, mailboxes, …) and ways are streets, roads, highways, and such. The nodes are pairs of coordinates latitude and longitude (GPS points, kinda). The edges are two or more nodes connected by a line which can be used to represent roads and other ways as well as areas, like building footprints, political boundaries.
When Google, Apple, a Tesla car, or anyone else that provides routing as a service calculate a route, they use an application called a routing engine that consumes (takes as input) a graph representation of the world like OSM to find an optimal path through it, along connected ways, between two nodes. However, an unfortunate aspect of computer applications is that they can’t operate on data that don’t exist; in order for a routing engine to use a possible path through the world, that path has to be represented as a sequence of ways in the map data it consumes.
With that, let’s take a look at osm-viz. When you open the app, you will see a satellite image of the San Francisco Bay area, obstructed in the top left corner by a multi-colored menu of selections. Clicking on a selection will cause a web of similarly-colored lines to be drawn over the map (sometimes a rich web, sometimes a pitifully sparse one). You can zoom in or out, but will notice that the data we are visualizing only cover the greater Bay area (vaguely, north to Santa Rosa, east to Sacramento, south to Gilroy).
Let’s look at the first selection: “First-class citizen sidewalks.” As mentioned above, generally OSM ways represent streets, roads, highways, and the like. Much of the time, non-car infrastructure, such as sidewalks, are not ways in the map but rather metadata tags attached to streets. This means that the data may include hints to the existence of a sidewalk, but no real data on it.
Over the past decade or so, an initiative sprung from the University of Washington called OpenSidewalks (OSW) has sought to change this. For the most part, sidewalks in OSM are represented as metadata attached to car infrastructure – “here is Main St. and Main St. has a sidewalk on both sides”. OSW sees sidewalks as ways (roads for people) in their own right – “here is a sidewalk that runs between these two points.” In our app, we call these sidewalks, that exist as ways distinct from roads and streets, first-class citizen sidewalks. When you click on this selection, you will see that some pretty remarkable work has been done to map sidewalks in the Bay area! But you will also notice just how incomplete the data is.
However, OpenSidewalks is a relatively new initiative, so even today much of the sidewalk data in OSM is in form of metadata tags. Click on the selection “Ways marked as having sidewalks” and you will see the options here. Now, San Francisco looks much better, but there are still holes. Zoom in on some of the holes, and you will see that the cause is definitely not a lack of real-world sidewalks. The other thing to remark is that, quite logically, ways that represent streets with sidewalks are drawn along the middle of streets, not along the actual sidewalks. This is what we meant above when we distinguished between “here is Main St and Main St has a sidewalk,” vs. “here is a sidewalk.”
Our app also lets you see one of the saddest lessons of this exercise – that much of the car infrastructure that should be tagged with metadata indicating that it has pedestrian and bike infrastructure simply is not. Click on the selection “Ways with no mention of sidewalks” (NB: this is a big chunk of data to query and load, so be patient – for us, it may take 15-20 seconds to appear) and you will see the map covered by a deliberately-chosen inky black.
Some other points of interest:
Pedestrian ways: This is a designation used to mark roads or areas designated mainly or exclusively for pedestrians.
Crosswalk Ways: This tag is part of the OpenSidewalks project. Instead of marking a crosswalk as a point (a node) or a just a footnote, in OSW data crosswalks are bonafide ways - a line you walk, ride, or roll along, just as you would on a sidewalk.
Cycleways: This tag indicates a way that has some sort of bicycle infrastructure that is an inherent part of the road. Think bicycle lanes separated from car traffic by a white painted line. Note that, like sidewalks that only exist as metadata on streets, this tag is not applied to the cycleway itself, but rather adds information to a car street or road.
Highway cycleways: Indicate ways that are designated for bicycles. Typically (but not always), these are distinguishable from cycleways in that they are separate from car infrastructure and motor vehicles are usually prohibited (except emergency vehicles). The category bicycle road is very similar, but this tag is more typically used in Europe than in North America. There is also a slight difference in that highway cycleways typically resemble paths, whereas bicycle roads resemble roads.
Living streets: are streets where pedestrians and non-car users have equal right of way to cars. They usually have lower speed limits than residential streets.
takeaways
So, let’s start connecting some dots. What do these maps and colored lines mean? What do they tell us? What should they tell you? Let’s go back to our original motivation: understanding why bicycle routing (or pedestrian routing) is so deficient compared with car routing. We can make several observations:
The network of first-class sidewalk data is paltry (NB: a glaring exception is the city of San Jose, which has benefited from the amazing work of a dedicated and sharp team of volunteers – our hats are off to those Santa Clara county OSM volunteers); the network of first-class bike lanes is non-existent.
The network of second-class sidewalk data is better than paltry, but nonetheless incomplete. The network of second-class bike lanes and paths is, as far as we can tell, mostly good.
Some of the holes in the map are owing to a lack of infrastructure – this is especially true of bicycle lanes and paths. But many of them, particularly in pedestrian infrastructure, are owing simply to a lack of map data.
Routing, Navigating Made Impossible
One thing to keep in mind as you are looking at these lines superimposed over a satellite image is that it is easy for you, a human, to visually analyze a picture and fill in missing connections where they have been omitted. But imagine what would happen, how much confidence you would have filling in missing connections, if you were to remove the satellite image from the background.
This is analogous to what a computer would be faced with if it were tasked with calculating routes through the network of nodes and edges that is the OSM map. Computers simply can’t draw a path of connected edges through a graph whose edges aren’t connected. Further, we can see anecdotally how a strategy of relying on edges that assure us of the existence of nearby, parallel edges leads to failure modes that, well, require us to use caution because directions “may not reflect actual conditions.”
The final, concluding observation that we make in this is that, if we want a mapping app that calculates high quality, trustworthy routes for bicyclists, pedestrians, (and people using strollers, people on crutches, blind people, wheelchair users, people on crutches, tourists, etc.) and which is capable of giving precise, step-by-step directions on par with directions that established mapping apps can give to car drivers today, then we need to map the world for bicyclists and pedestrians.
We want a mapping app that can tell us, as a bicyclist or scooter user:
when and where to merge left or right,
when we need to leave a bike lane and get onto a shared road,
when we are permitted to get up on a sidewalk to avoid dangerous traffic.
We want a mapping app that can tell us, as a pedestrian or wheelchair user:
where sidewalks narrow or widen,
where there are obstructions like bus stops or mailboxes,
where there are steps, or no curb cuts.
We want a mapping app where we can type in a destination, press “Go,” and just follow directions without needing to give them any more attention than you would if you were driving a car.
None of this will be possible as long as bike lanes and sidewalks are only metadata attached to streets. It will certainly not be possible where such data doesn’t exist at all. Good data can help us avoid bad infrastructure. City and transport planners can use accurate data to plan better and build more efficiently.
Putting our money where our mouth is
Since it doesn’t do anyone any good for you just to listen (or read) us complain, we are setting out to conduct an experiment in gathering missing map data in a fast, efficient, data-rich, and fun way.
The idea is simple – collect highly-accurate geolocation readings and associate with them labels that can be recorded by speaking into a microphone. Mounting a lightweight tool with this capability to a bicycle or similar device, we hope to be able to draw OSM map data while riding the ways. This way we can record the location of infrastructure such as missing paths. We can also survey large areas fast, recording the presence of things like bike racks, damaged infrastructure and other features that interest us and our partners in business and government.
Right now, the prototype is a work in progress – minimally functional but with lots of room for improvement. Some other ideas we hope to explore in the future are adding cameras to it to collect image data, and adding an accelerometer to gather estimates of surface quality.
Note: We know Google's mapping is not based on OSM. In fact, Apple and others used OSM data to compete with Google starting in the 2010's. Google's routing solution for cyclists, scooter users and others not in cars is notoriously bad ...despite having access to oodles of data.
Comments