CurbLR is based on the design and thinking laid out in CurbSpec. At SharedStreets, we spoke with a handful of cities across the US, reviewed their parking regulation datasets, conducted field mapping in a local area to experience data collection, and converted an initial dataset of ~35,000 Los Angeles parking zones into the CurbSpec format. To our knowledge, this was the first attempt to convert a curb regulation dataset into CurbSpec. When trying to convert GIS data into the spec, we realized that several significant modifications were needed, including:

• Adding location information for the regulation (both geographic and with the SharedStreets linear referencing system.
• Structuring regulations as a GeoJSON, and in a flatter manner (one curb activity per feature)
• Using a well-known values approach to avoid free-form text where possible
• Adding metadata to describe the agency that created the data, and other relevant aspects that apply across a CurbLR feed
• Adding a structured, but optional, place for data such as payment information and asset information, which is required for some consumption efforts

The addition of linear-referenced location information was a significant change that is critical to how the spec functions. Because of this change, we chose to rename this spec as CurbLR.

CurbLR is a data standard for describing urban curb regulations. It exists to help government effectively manage and regulate the curb and to support public and private users of city streets.

CurbLR provides a structured, standardized format that can be used by government agencies, citizens, and companies who want to store and share information about curb regulations, regardless of whether the data are gathered through mapping, crowdsourcing, or machine learning techniques. It uses linear referencing to link regulation information back to the street.

CurbLR is a common language on which many things can be built, including rules engines, query APIs, consumer notification services, mapping tools, and analytic models.

CurbLR is a JSON format, and it includes all regulations as a GeoJSON object.

1. Machine-readable: From navigation apps to connected cars, urban mobility is increasingly digital. CurbLR helps computers understand the curb, whether that's answering real-time questions like "where's the nearest place to drop off a passenger?" or modeling parking allocation scenarios for an entire neighborhood.

2. Human-oriented: Curbs are managed and used by people, so CurbLR must be useful to humans and not just machines. CurbLR is designed to be directly readable and writable by people with technical training, and to support tools that make it accessible to the non-technical.

3. Possible: Most curb management is not digitized today and this won't change overnight. To ease this transition, it must be possible to take existing signs and translate them into CurbLR, even if some desired data fields are unknown.

4. Adaptable: No two cities manage their curb in exactly the same way. CurbLR is built to support many types of regulations and management practices. A city should not have to change its curb regulations to use CurbLR.

5. Essential but not exhaustive: CurbLR is not the appropriate place to store exhaustive information that would not be consumed by others outside the city (for example, the date when a parking sign was last replaced). This information can be maintained separately and linked to the curb regulation data - in the same way that GTFS contains essential information about a transit system, but doesn't capture every bit of the transit agency's data.

6. Reversible: Cities can convert parking regulations into a CurbLR feed, and can also reverse this to link back to their original data.

7. Consumption-oriented: Government agencies typically maintain data about physical assets, which are easily managed in GIS systems and are the simplest format for an agency to update over time. CurbLR describes regulatory geometries, which requires a more complicated data model and a GeoJSON format. In order to fully capture essential data, the spec is difficult to edit and maintain directly in a GIS system. Therefore, CurbLR is intended as a format for cities to publish and share curb regulation data with outside agencies or private companies. The structure and details of the spec follow this logic. In addition, since public agencies producing data often have fewer technical resources than private companies consuming data, CurbLR strives to avoid burdensome data requirements for cities by focusing on basic asset data. Wherever possible, CurbLR avoids data processing and interpolation, leaving these issues for engineering teams on the consumption side of the workflow.

8. Future-friendly: How we use the curb is changing. Cities are adjusting parking prices based on demand, new transportation services are arriving on our streets, and vehicles without humans behind the wheel will one day deliver people and goods to the curb. CurbLR exists to help make these futures a reality and will grow and adapt as urban mobility evolves.

CurbLR structures every curb regulation as having three components: the GeoJSON feature (point or line), the location properties, and the restriction that applies. While the restriction is relatively straightforward to describe, location is more difficult.

Curb regulations are usually represented by physical assets like parking signs and curb markings that describe where the restriction applies. These signs can be mapped using their geographic coordinates.

The assets themselves are easy to map, but the concepts they represent are not. Curb regulations don’t have a perfect, 1:1 relationship with physical space. They represent regulatory geometries, not physical geometries.

CurbLR uses asset data as the building blocks for a spec, but supplements it with additional location information and structure.

CurbLR requires users to reference asset data to their location along a street, using the SharedStreets Referencing System. Individual asset locations are given the SharedStreets Reference ID for the street on which they are located, along with their location along it. Points can be extrapolated into line segments by setting a particular width for each type of restriction, by including information about sign relationships along a street, or by estimating based on similar metadata. This enables asset-based point or line data to be converted into street-linked data.

Here's a visual overview:

SharedStreets references can be regenerated at any time, and individual assets can be edited without impacting the rest of the data. This provides a stable, interoperable way to convert the location of a parking sign into the regulatory geometry that it represents.

With location taken care of, the rest of a curb regulation is relatively straightforward to describe, using categories to capture what, where, to whom, and how the restriction should be applied.

The links below show real world curb regulations translated into CurbLR.

CurbLR groups regulation properties into several categories, focusing on where the restriction occurs, what it restricts, when, to whom, and how, it applies, and how it relates to overlapping restrictions.

These categories are described below:

Feature properties that correspond to where a restriction applies are grouped in CurbLR as location. The remaining fields form part of the restriction that applies to the object. All of this is stored as individual features that form one GeoJSON object. Above this in the file, the CurbLR feed will contain metadata properties that apply to all regulations, such as the date when the feed was created. These are stored as a manifest, which is a JSON object.

The example below shows the structure of one feature in the feed:

• External referencing for designated periods: Extend TimeSpan to allow arbitrarily designated periods (e.g. "Snow Emergency" or "School Days") to be specifically defined via a static or dynamic (API) referencing system.

• Enhanced payment definition: A schema to define payment requirements for a given use. Could support the publishing of dynamic parking pricing or complex fee structures such as peak period ride share pickup / drop-off fees.

• Cross-jurisdictional allowed use mapping: A mechanism to establish defaults and translate restrictions (which are locally defined in their meaning) into a standardized, cross-jurisdictional list of activities. This would, for example, allow automated interpretation of local restrictions to determine where activities like passenger loading could take place.