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. With the evolution of transportation technologies, infrastructure, and mobility tools, the management of the curb is increasingly important. However, this focus should be not only for the transportation industry: regardless of transportation implications, the curb is an asset that affects everyday life. As a result, the curb is an asset that can be inventoried and mapped, which 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 another way, such as 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 most of it 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 not sure if the brick edge counted as tactile. When adding 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”. We have buildings, we have sidewalks, we have different types of roads, but beyond that, we often find the map has gaps and blank spaces. While this may be useful for human readability, it also means a significant amount of information is 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 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.

This is important for the whole OpenStreetMap community. If OpenStreetMap fails to embrace the curb as a crucial piece of data, another platform will take the lead. Mapping the curb is already becoming a revolutionary practice, 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. In cases such as Sacramento or Amsterdam, where the cities’ open data includes on-street parking details, this means a TNC might expect to consume both cities’ data in similar formats and schemas. 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)?

It’s imperative to consider the current conditions in mobility in relation to the curb, but it’s also crucial to start thinking about the innovative technologies in transportation and the changes in preferences in how consumers and travelers prefer to move from Point A to Point B. Using OSM as the main platform to map the uses of the curb would benefit—in an open source manner—municipalities, Departments of Transportation (DOTs), and users as a whole.

By mapping the curb and its diverse uses, public agencies have the opportunity to have an inventory and potentially create an asset management practice specifically developed for the curb. Furthermore, having the curb mapped would be advantageous to mobility applications or platforms that use OSM data, such as Open Trip Planner (OTP), enabling indication of the specific location of different modes of transportation along the curb. You could get a ride-sharing bike from a bike sharing station located on the curb, ride it on the protected allocated bike lane along this curb, then wait for a bus or a TNC at designated areas—also along the curb. Meanwhile, delivery vehicles can be more efficient by using their appointed loading zones on the curb without obstructing traffic or bike lanes. Most importantly, all of these stakeholders could access this information from the same central database, yet also contribute to it as necessary.

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?

/Daniela Waltersdorfer J, Transportation Analyst at Cambridge Systematics
and Christopher Beddow, Solutions Engineer

This is an extended version of an article originally published by Geoawesomeness on Feb 11, 2019