Changing with the times, the curb is no longer just the elevated edge along the side of the street. It is now used to describe an intermediate zone alongside a road, including transit bays, street parking, “flex zones”, valet lanes, bicycle lanes, Transportation Network Company (TNC) pick-up and drop-off areas, or commercial loading zones. The evolution of transportation technologies, infrastructure, and mobility tools means that the curb is increasingly important. As a result, the curb can—and should—be inventoried and mapped. This raises inevitable questions for OpenStreetMap: how do you manage and map the diverse uses of the curb, with specifics pertaining to size, usage, and time restrictions?
The OpenStreetMap Wiki contains a few entries for “curb” (mainly correcting to the British spelling, “kerb”) This includes Key:kerb, which is defined as the edge where a road meets a sidewalk . The entry goes on to state:
As these are transition points between different surfaces and/or elevations, the locations of kerbs are important features to pedestrians, cyclists, and especially to those with reduced mobility (e.g., in wheelchairs)
In this case, the curb is meant to be mapped as a node in a way, like the point where a sidewalk crosses a lowered or flush curb and becomes a marked crosswalk. This is the curb as a point, in one dimension.
Meanwhile, the Tag:barrier=kerb entry on the wiki describes the curb as a line, but with a third dimension as well: height. The entry is very brief, and mainly consists of the following:
…barrier=kerb is a barrier for vehicles and wheelchair drivers. The height of the kerb is important and with this information, the usage by different groups can be determined. The height of the kerb is tagged additionally as height=*, if available. Right side is bottom, left side is top.
This is the beginning of the curb as a discrete feature on the map. Using OSM iD editor in a downtown area, we can spot a curb in the nearest Mapillary image, then follow the curb outline using Digital Globe Premium basemap. It can be marked as a regular curb, while it’s not certain if the brick edge counts as tactile. When noting the height, there’s a clear need to physically measure the particular curb. This curb and the one across the street are both yellow, indicating no parking is allowed—but there’s currently no way to indicate this in OSM.
Examining the OpenStreetMap base layer, it’s easy to see how much detail is missing compared to a satellite map. Mapillary images are a reminder of how much rich detail is on the ground when doing some armchair mapping. And of course, if you’re on the ground, whether out for a walk, driving and parking a vehicle, or cycling just beside the curb, it’s obvious that the map isn’t very detailed about the “spaces in between”. In other words, there is a significant amount of information missing. When a machine needs to access map data—whether a routing service using the Overpass API, or a hypothetical autonomous vehicle—the OSM database is simply not very informative about the curb.
There are ways to demarcate the diverse uses of a static location within OSM, such as through the use of “conditional tagging” such as parking:lanes:conditional. This, however, limits the mapping of the curb to adding conditions to existing line segments, in this case, lanes on the street. But, how do you map an actual polygon that emphasizes the dimensions of a specific curb space, and where do you then provide descriptions of its diverse uses? For example, two vehicle zones may serve as residential parking at nighttime, but function as TNC drop-off and pick-up zones as well as loading areas for deliveries during the day. Perhaps that whole zone additionally functions as a bus lane during peak hours in order to control congestion.
These are merely a few of many examples. The fact that OpenStreetMap has failed to embrace the curb is important for the entire OSM community. If this continues, another platform will inevitably take the lead. Mapping the curb is already becoming a game changer, seen for example in such cities as Los Angeles and San Francisco where Coord, powered by Sidewalk Labs, helped put intricate details of curb classification and regulations into an API that can empower applications that need to get information about the curb at a given longitude and latitude. While this data is painstakingly collected in order to be accurate and precise, curb data is also collected through more automated methods such as Mapillary’s computer vision, which intelligently detects and classifies curbs in street-level imagery.
Collecting the data is a massive challenge, but organizing, analyzing, and sharing it is just as daunting. SharedStreeets is pioneering an open standard and data exchange for road network information, geared toward increasing private and public partnerships when sharing such data as curb regulations. Meanwhile, Remix specializes in helping cities to understand private data when enforcing regulations and planning policies. But why are we not doing this via an open platform, such as OSM? Most, if not all of this is happening in parallel to OpenStreetMap, rather than in collaboration. Where do these paths cross, between open public data, privately collected data, and the world’s decentralized, yet standardized open map (or database)?
The power of OSM is in its function as a map that can be commonly contributed to as well as commonly used. Having the ability to map the curb with tools improved and standardized by OSM, with the curb as its own tag and polygons specified certain curbside uses, would adopt the wonderful world of open source mapping into the rapidly changing present and future. Maps are certainly changing as technology evolves, and as maps are used less for human navigation than for machine navigation, their purpose needs to not shift but to expand. As Justin O’Beirne wrote in a 2017 analysis, “we’ll start caring more about the macro than the micro”. This indicates a shift in how humans read maps, yet while we are looking for POIs our transportation mode will be looking for the micro-level details that we don’t need to consciously consider as map consumers.
So, the question remains—will OSM embrace the curb? If OSM is to remain a map for humans, which it very much is, then the macro-level is sufficient. OSM’s status as the best map of the world, however, calls for unifying these macro and micro details together in a database of everything in the physical world—for humans and our machines. In order to achieve this, the question should be extended: how will OSM embrace the curb?
By Daniela Waltersdorfer J (@DWaltersdorfer), Transportation Analyst at Cambridge Systematics, and Christopher Beddow (@c_beddow), Solutions Engineer at Mapillary. This is a shortened version of a blog post that was originally published on mapillary.com/blog.