Maintaining Data on the Curb with CurbLR: A New Open Standard

Maintaining Data on the Curb with CurbLR: A New Open Standard

Curb management is becoming a hot topic for cities as street users compete for the often overlooked resource. Many books (like this and that) have been written about parking. Companies are forming to enable improved access to parking and parking data. Cities are publishing reports about their curb management strategies (San Francisco’s). Data standards are being created to improve digital coordination. 

Azavea had a great opportunity to dive into the fray and work with a promising open data specification for curb regulations called CurbLR. Find out much more here. Philadelphia’s Center City District was interested in understanding how curb management approaches affect traffic. They manually collected data on every street-side parking sign in Philadelphia’s Center City District, with an area of 1.3 square miles and more than 69 miles of linear curb line. Azavea converted the data into a CurbLR-compliant format that makes it easier to visualize and generate statistics. For example, there are 50% more free parking spots at 9 am on Sunday than Monday.

screenshot of philadelphia curblr data

Check out the interactive map here:

The potential impact of CurbLR

  1. Improved urban planning: Improved data access can help cities and private companies make better decisions and use shared resources more efficiently. Outcomes could include improved parking flow and reduced traffic. Up to 30% of cars in cities are caused by people circling looking for parking, creating excessive congestion and emissions.
  2. The public benefits when data is openly available. But private companies are already offering proprietary data services to cities that promote their own infrastructure and standards. We see this as the curb equivalent to the General Transit Feed Specification (GTFS), which was a boon to cities and the public.

Generating the data

Center City District provided Azavea three main datasets: 

  • Curb Segments
    • Location geometries at curb segment level
  • Parking Zone regulations
    • 4,514 features describe data at regulation level (i.e. no parking between 2-4 pm at a specific segment)
  • Hourly Parking table
    •  561,456 features: hourly level description of parking regulations

Azavea generated:

  • CurbLR JSON file
    • A single CurbLR compliant JSON file that describes all regulations
  • “Relational database”
    • Consists of three different files
      • Segments shapefile
      • Regulations CSV
      • Timespans CSV

We generated the “relational database” because CurbLR is not a flat dataset (e.g. each segment could have multiple different regulations, each regulation could have multiple different timespans), it does not lend itself well to being viewed in desktop GIS software such as ArcGIS or QGIS. This approach makes it easier to view CurbLR dataset it desktop GIS software

The challenges of working with CurbLR

CurbLR is a very promising standard, but there are still some kinks to work out. The most significant challenge was the ability to attain complete accuracy with the linear referencing tool. SharedStreets developed a powerful command line tool that takes an input set of points or line segments, as well as a series of additional parameters and tries to match them with OpenStreetMap road segments. 

The linear referencing output includes a GeoJSON geometry (of either the street centerline or the street centerline offset) as well as reference IDs to the OpenStreetMap street segment. It also gives us the ‘side-of-street’ (i.e. right or left relative to the direction of traffic), which is required for CurbLR compliance. This enables the co-registration of datasets with slightly different geometries to ensure they are referring to the same curb segment.

There are two main problems that occurred when referencing the CCD curb dataset:

Unmatched segments

Unmatched segments are curb segments for which the referencing tool was unable to find a match within the OpenStreetMap road network. The referencing tool output includes a GeoJSON file indicating which segments did not match.

Mismatched segments

The second issue that occurred in the linear-referencing process was mismatched (or “incorrectly matched”) segments. These were cases in which the CLI matched the CCD curb segment with the incorrect street in OSM. Although it is difficult to determine the precise number of mismatched segments, Azavea ran through a number of these segments to understand the problem. The mismatched segments occurred most frequently for segments similar to the case displayed in the image below.

An example of a mismatched segment: the selected (red) curb segment should be on North 10th street but the referencing tool matched it to Appletree St. (which is perpendicular to N 10th).

It is important to note that the SharedStreeets linear referencing tool is relatively new. Azavea engaged with SharedStreets to discuss these cases. SharedStreets noted that the tool had not yet been tested on these types of short parking segments and found it helpful to see these types of results. They plan to make changes that will adjust the weights associated with proximity and tolerance for perpendicularity in order to minimize these errors.

What do we hope is next for CurbLR?

Data standards become more useful the more they are used and implemented. We are grateful to both Center City District and SharedStreets to have the opportunity to work at the cutting edge of a new standard. We believe it has tremendous potential to become the standard used for maintaining curb data in cities across the world. This would make cross-city scalability easier for companies that interact with the curb, for example, rideshares like Uber and Lyft,  along with companies that promote improved parking access like Passport Parking and SpotHero.

We’d like to see:

  1. More cities engage in CurbLR pilot projects
  2. Improvements in the SharedStreets CLI tool along with suggestions for dealing with unmatched and mismatched street segments. 
  3. Further tooling that makes it easier to update and manage CurbLR data. This could be a desktop GIS plugin (ArcMap or QGIS) or a simple web interface. 

Questions or comments? We’d love to hear from you! Feel free to reach out: