Curb (or “kerb”) management has become a hot issue in cities as street users compete over limited space along the street to park cars, hail a ride, deliver packages, and drop off scooters. City governments and private companies have been scrambling to map curbspace and its uses, with private platforms springing up to help capture this data. At SharedStreets, we’ve partnered with Ford Mobility and been working with a number of cities and companies to help develop an open standard for curb regulation data, which creates a common language for data creation, sharing, and consumption.

There’s been so much interest and collaboration in the public and private sector… but OpenStreetMap is noticeably absent. Curb regulations are not commonly mapped in OSM, despite some discussion of their importance. There isn’t a standard way to capture the dynamic uses of space along the edge of the street, such as what activities are allowed, when, for whom, and how each restriction relates to other overlapping rules.

At SharedStreets, we believe that open data benefits everyone and it ought to be possible for agencies, mapping enthusiasts, and civic tech groups to map curb regulations, take advantage of common tools, and use information for advocacy or other purposes. We’re also keen to support OpenStreetMap, which is a foundation for SharedStreets’ core tools. So when we set out to develop an open data standard, CurbLR, we also hoped that it could be compatible with OSM. Just as GTFS is a standalone format for transit information, we think that complete curb information should be shared in a format that can be published independently by government agencies. But we’re interested to find a way that OSM could hold the building blocks of curb regulation data for those who are interested in mapping it, so that users aren’t “locked out” of the activity and collaboration that’s happening elsewhere.

So, how could OSM do this? We examined the ways that OSM can currently store curb regulations and concluded that they are problematic for handling this type of regulatory information. The challenge isn’t capturing the curb rule itself, such as a resident parking zone that applies during certain hours. The hard part is how we represent the location where the rule applies.

Instead, we propose that the physical assets that correspond to parking regulations, like signposts and meters, can be mapped as individual points in OSM and given a new tag, kerbside_marker=*. This data can act as the building blocks used to extrapolate a CurbLR feed, which contains the geometries of the regulations, detailed information about the rule itself, optional payment profiles, and metadata.

This path would enable OSM to store curb asset information that anyone can easily map, edit, understand, and use. From there, the asset data can be snapped to the street centerline, converted to street segments, and linear-referenced using SharedStreets’ open tools, giving them additional location information that is needed by cities, but which is not easily stored and maintained in OSM. The referenced dataset can then be converted to a standalone CurbLR feed that can be ingested by analytics tools, rules engines, and APIs.

Here’s more detail about how we examined the problem and what we propose.

What do we mean by “curb” and why is it important?

First, a clarification. When we talk about mapping “curb regulations”, we are referring to the curb as the outer edge of a street (shaded yellow in the image below):

We are not referring to the actual curb itself, which is a physical barrier with static properties like height, width, color, and the presence of a curb cut. This is currently mapped in OSM using ``kerb=*`.

The edge of the street is a different physical feature than the curb as a barrier, and corresponds to a different location in space. These things should be mapped separately. While we agree that there is a need to map the actual curb, our work pertains only to curb regulations. To help keep this clear, we use terminology like “curb regulations”, “curbside”, or “curbspace” when describing our work in the context of OSM.

Why does this data matter?

Curb regulation data has many uses. In order to manage competing demands for space along the street, city planners across the US and Europe need to understand supply. They can then analyze how they allocate space and model potential changes and impacts. Private companies can generate and use curb regulation data for their navigation, ridesharing, and parking payment services. Autonomous vehicles need data about where they may load or park. Micromobility providers need to understand where scooters, bikes, and other devices may be stored.

Historically, there hasn’t been a common format to store and share information about the curb. Each government agency, jurisdiction, vendor, and company approaches this problem independently and ends up developing bespoke data formats. This limits collaboration and coordination around increasingly important public space.

At SharedStreets, we’ve been working with city governments and private companies to develop an open standard that captures essential location and regulation data in a format that can be easily produced and consumed. We recently released a first draft of a spec, CurbLR, as an evolving proposal and an invitation for collaboration. CurbLR provides a structured, common language share data about regulations - like a “GTFS for the curb”. It gives cities and vendors a template for data collection and is useful for building analytic models, rules engines, APIs, and other mapping tools.

While cities and companies are working towards a data standard, mappers and civic tech groups haven’t been part of the conversation so far. If OpenStreetMap can also be a place to store information about curb regulations, then everyone would have access to an open platform where they can create and access this information.

Current state of OSM

How parking restrictions are (or aren’t) mapped

Curb regulations are often dynamic usage restrictions; they apply at different dates and times for a given segment of the street. For example, a given street may have residential parking at any time, two-hour parking for visitors, street cleaning every second Tuesday morning of the month, and several fire hydrants that override all other parking rules. These can currently be mapped in OSM on ways, using conditional tagging, as noted in Mapillary’s blog post.

To do this, the way for a given street segment is given additional tags: parking:lane and parking:condition:<side of street>. Since a street segment can have multiple restrictions that apply at different times, a hierarchy level can be included in the restrictions. For example, an overlapping “no stopping” zone and “resident parking” area would be tagged as parking:condition:right:1=no_stopping and parking:condition:right:2=resident with additional tags to indicate when each restriction applies.

How is conditional tagging for parking used?

Conditional parking restrictions are not especially common in OSM, but they do exist. They usually describe very basic aspects of parking, such as whether parking is free, ticketed, or available for residents only. Here’s a look at common tags for conditional parking:

Even when conditional parking tags are used, they tend to be inconsistent and highly specific to the mapper. For example, one of the most common parking conditionals is a “no stopping” restriction that happens at a given time on weekdays. All of these tags were placed by one individual; they focus on a few roads in Luanda, Angola:

Once we looked for overlapping or complex curb regulations in OSM, the examples became very, very sparse. As of June 2019, only about 600 second-level parking restrictions existed in OSM. Only about 250 third-level parking restrictions existed¹. Two and three levels of curb restrictions is not an edge case or an outlier; this is common on many urban streets.

To understand what conditional parking tagging looks like when it is used, we explored where multi-level parking restrictions were mapped and how they were captured. Here’s an example from Toulouse, France (you can view more through this parking editor tool):

Take a look through these tags and try to interpret them. They are very difficult to understand and they offer many opportunities to contradict each other. Since tags can be applied on the left, right, and both sides of the street, it’s possible to have conflicting restrictions (e.g. free parking on the left side, paid parking on both sides) without a means to resolve which one takes precedence.

It’s not surprising that this type of mapping is very uncommon. In part, this may be due to poor editor support for such a tedious tagging scheme; parking regulations are complicated and will always require many tags to capture their essential information. Better editor support for curbspace tagging would make any tagging scheme more viable for mappers.

However, we also believe that the underlying mapping approach just isn’t appropriate.

Problems with mapping regulations as ways

A fundamental limitation of the current OSM tagging convention is how locations are handled. It’s straightforward to map physical assets, like a signpost and the restrictions on it. But regulatory geometry is harder to map. Regulations don’t have a fixed, 1:1 relationship with physical space; they are a concept that exists on top of space. As a result, it’s possible to force curb regulations into OSM. But not in a way that people can easily map, maintain, understand, or use.

In the example below, a given street has four levels of parking restrictions that apply to different activities, at different times and days: a snow emergency zone, a street cleaning restriction, a loading zone, and a permit parking restriction.

When regulations are mapped on a way, node placement becomes critical. There must be a node on the way at the beginning and end of each restriction, and there may be additional nodes that are simply there to shape its geometry. These nodes divide the street into many sections, which will have between 0 and 4 levels of parking regulations, like so:

A given regulation, like permit parking in the example above, will sometimes be tagged as parking:conditional:right:3 and other times as parking:conditional:right:4 depending on its relationship to other regulations.

Mapping all of these regulations correctly would be extremely difficult. The correct tags for a given regulation will be different for each street, and will vary even along sections of the same street. Modifying one regulation, like a loading zone, will have cascading effects on any other regulations with a greater hierarchy level. Moreover, if a mapper realigned the geometry, simplified the way by removing nodes, or altered the street in any way, there would be unintended consequences for the curb regulations.

This seems like a massive headache for mappers. Yes, moving a node is always risky, and a mapper must consider all the tags that may be affected. But for something as common as a parking restriction, which could affect the majority of tags on all urban streets, this tagging method just doesn’t seem practical or sustainable. Better editing tools could help, but they would need to be used anytime a mapper is ever edits a street with parking restrictions.

Moreover, additional tags can make editing infeasible. If a *:capacity tag is used, such as for parking space counts, moving a node or splitting a way would require the mapper to determine the number of spaces on each side of the split. That’s tedious and not always possible to determine from aerial imagery, and editors can’t really help mappers do that intelligently.

Overall, we feel that curbspace regulations are very problematic to map on the way.

Is this a unique situation? Why?

Regulatory geometries never have a perfect relationship with physical space, but sometimes they are simple enough that they can be mapped anyway. There are other street attributes (like speed limits and turning lane movement restrictions) that are commonly linearly referenced, but are still mapped on ways and used by data consumers like routing engines. However, we view these attributes as outliers. For example, a speed limit (maxspeed) is typically a single regulation that applies to an entire street. It may vary during some hours due to a school zone, construction zone, event, or other restriction, but these variations are simple enough that they can still be mapped on the way without too many problems for mappers, editors, or consumers.

Curbspace is a much, much more complicated type of regulation, since it often involves mapping four or more overlapping, dynamic usage restrictions with complex time spans, user classes, regulatory authorities, mode restrictions, and payment profiles… all occurring over subsegments of a street.

Tagging on the way may be feasible for some attributes, but the complexity of regulations that govern things like curbspace would be better captured through other means.

Alternate proposal: Mapping asset points

A curbspace data standard should live in a separate format outside of any platform, but OSM could hold the building blocks for it. We propose that a better way to store curb regulations in OSM would be to map the point-based physical assets that correspond with regulations: sign posts, fire hydrants, curb markings², etc. This is the information that exists at the street-level to inform people about what a regulation is and where it applies. It can be physically viewed and photographed, it’s what cities focus on when conducting curb inventories, it’s straightforward to map, and each individual point can be edited without affecting the others.

Precedent in OSM

OSM already uses this approach for signposts on a road, which are mapped as points and tagged as traffic_sign=*. The points can be located on either side of the road, or on the centerline itself. There is precedent for using additional tags to denote whether a given restriction (such as a school zone with a lower speed limit) is beginning or ending.

We did not find any examples of traffic_sign tags being used for curb regulations. Instead, traffic signs are currently used to map informational signs (e.g. a city or hamlet limit), vehicle restrictions (e.g. max weight, max height, cyclists only), and movement restrictions (e.g. max speed, yield, no right turn). The images below show results from taginfo:

A new key: kerbside_marker

Given that curb regulations are not currently mapped with the traffic_sign key, and since many types of curb markers are not actually “signs”, we propose to use a new key: kerbside_marker.

Values of kerbside_marker should capture:

• what the marker is (e.g. meter, signpost, curb paint)
• its relationship to other nearby signs, if applicable (e.g. if this is the beginning, middle, or end of a loading zone)
• what activity is being restricted
• when the restriction applies
• for whom it is applied (includes restrictions based on mode, permit, and vehicle type)
• how this relates to other overlapping restrictions
• whether payment is required, along with a payment profile

Each of these categories is addressed in detail in the draft CurbLR spec. The CurbLR data model could easily be used as a basis to define key:value pairs for asset points in OSM. If additional asset information is desired (such as the signpost type or date of install), this could also be added to OSM.

Limitations

Curbspace inventories are often initiated by city governments and cover entire sections of a city. Preparing this data for an OSM import would be reasonably straightforward. However, the tagging schema would still be cumbersome to navigate when manually mapping individual points. This is inevitable given the complex nature of these regulations.

Editing tools for JOSM and/or ID could help with manual mapping. There is also room for machine learning algorithms to also play a role - curbspace inventories typically involve collecting photos from the street and entering the data afterwards, and street-level imagery is also available from sources like Mapillary. If these models could help to group similar photos for mappers (and, over time, learn to interpret them), then they could provide options to speed the process.

Then what? Deriving regulatory geometries and consumable data

Point-based assets are not sufficient to use directly in routing engines and other applications³ in order to be consumable, they have to first be converted into regulatory geometries and linked back to the street. We think the best way to do this is outside of OSM.

To create the regulatory geometries, asset points can be snapped to the street network and converted into street segments. SharedStreets’ open tools are one way to do this. The length of each street segments can be set by determining the relationship between signs on a street (i.e. using the information about restriction beginnings and endings), or by setting an approximate width for each asset type (e.g. a single parking meter refers to a space that is ~5.5 meters long). Or a combination of the two. SharedStreets is currently building these capabilities into our command line tools, and we hope to release a version in the coming weeks. Other means could certainly be used or created; transforming points into line segments is a tractable problem.

Regardless of how line segments are created, they also need to be linked back to the street. We believe that linear referencing is the best way to do this for regulatory data. With linear referencing, objects like parking signs are related back to the street and their location along it (e.g. the location may be described as “Main Street, from 30m to 40m” and assigned that geometry). We developed the [SharedStreets referencing system] (https://sharedstreets.io/how-the-sharedstreets-referencing-system-works/) in order to create an open, non-proprietary way to do this. Using this system, each street is assigned a unique and consistent Reference ID that enables data to be exchanged between basemaps, even when the streets don’t match perfectly. Direction of travel (relative to digitization) is also considered in order to identify which side of the street the object is on.

The SharedStreets referencing system is one pathway for doing this, though users could certainly use or create another referencing approach.

Linear referencing is a departure from the basic OSM model, which is self-contained and primarily relies on relations to link disparate geometries. However, linear referencing provides a common language for people to refer to a given street and a location along it. This is especially useful for communicating about regulations since city governments, private companies, and OpenStreetMap all have a different understanding of the exact geometry of a street, and therefore they disagree slightly about where a given regulation applies. This is not going to change; there will never be universal agreement on a single map of the world. So, in order for a curb standard to work for everyone, there needs to be a way to communicate about location without being beholden to any particular basemap. Basemap-agnostic data can be combined from multiple sources and would work seamlessly across consumption tools and products.

Quick recap

To recap, here’s the process we propose:

• OSM could store point-based asset data, tagged as “kerbside_marker=*”. This provides a more straightforward way to map and edit curb regulation information, as opposed to conditional parking tags on the way.
• Points can be snapped to the street and converted into line segments, using information contained in the tags to determine the length of each segment. This would be done outside of OSM, by data consumers. This can be done using the SharedStreets tools, or using whatever other methods are most desirable for a data consumer.
• The resulting segments would be converted into linear references with a given geometry, which enables them to be used more readily by data consumers. Linear referencing can be done as part of the previous step, using SharedStreets’ tools. However, if another pathway is more suitable for the data consumer, then they could use that.
• All of this data (OSM curb regulations + derived location references + metadata) could be converted into a CurbLR feed, if desired. This format exists as a series of JSON files so that it lives outside of any particular platform - much like GTFS.
• This process provides a pathway for OSM to store the building blocks of a standardized curbspace dataset. This could be consumed from OSM and processed on the consumer side, or else converted into a basemap-agnostic, platform-agnostic data standard: CurbLR.
• As curb regulations change over time, individual asset points can be edited without affecting overlapping regulations. Segmentation, referencing, and data conversion can all be re-run to produce an updated feed or other outputs, if desired.

This overall approach replicates how city governments themselves are mapping and storing GIS information about their curbspace, and the workflow they are using to begin producing CurbLR feeds. Our intro post discusses this process in more detail, with graphics and examples. By storing curb regulation information as asset points, OSM can provide a more straightforward, viable, and sustainable means to store curb regulation data.

Thoughts? Questions?

If you have opinions about how to approach curb data in OSM, we’d love to hear them. This blog post will be sent out to the OSM tagging mailing list for consideration, and we’re also available by email, on the OpenStreetMap-US Slack group, or through GitHub.

In addition, if you’re interested in CurbLR as a spec, please reach out. It’s currently in draft form and we want to ensure that it takes various user groups’ needs into consideration. We are actively gathering feedback from cities, companies, civic tech groups, and mapping communities who work with curb data. Over the coming weeks, we will use this feedback to guide a revised version of the spec, likely with a more modular structure and more robust payment profiles. Let us know if you’d like to join the conversation!

Acknowledgements

The ideas laid out in this post were informed by the entire SharedStreets team as well as through conversations with Chris Beddow, Dani Waltersdorfer Jimenez, staff at the DC Department of Transportation (DDOT), corporate partners, and a handful of others in the OSM community. We are grateful to them for their contributions, which have helped shape our thoughts on the curb.

Footnotes

1. Source: taginfo; retrieved 12 June 2019. This includes conditional parking tags on the left side, right side, and both sides of the street
2. Curb paint, common in the US state of California, can be mapped as the start and the end point of the paint
3. traffic_sign is not converted into line segments and linked back to the street, and this is one reason why it enjoys little support among data consumers. For practical reasons, renderers and routers have focused on explicit relationships like tags on ways and relations between features. Many mappers consider traffic_sign to be a last resort with the understanding that the data won’t be as readily usable by data consumers.