Curb polygons and linear referencing

[schnuerle]

Based on the Discovery Phase of our curb work, the recommendations from our Working Group Steering Committee, the scope and goals of our short term CDS plan, and the discussions at our public working group meeting about CDS Regulations, the spec is planning to define curb areas using 2-dimensional polygons by default, instead of linear referencing.

The reasons for this include making it easy for cities and agencies to get starting using simple GIS tools, not requiring a linear referencing system in place already to use CDS, areas make it easier to see if vehicles are inside or out, and are easy to understand on a map at a glance.

While linear referencing will not be required, in the spec we will be strongly encouraging cities to set it up eventually to support CDS and other curb use cases. Linear Referencing Systems (LRS) will be able to reference CDS, and vice versa.

What are the advantages and disadvantages of 2D polygons vs 1D lines for our curb management use cases? What is your agency and company using now to define and manage curb space geospacially? How do you do conversion between systems like these?

[schnuerle]

See the start of defining the areas within CDS here. We will also mention this on our Curb WG call this week.

[jacobmalleau]

I agree with this point "While linear referencing will not be required, in the spec we will be strongly encouraging cities to set it up eventually to support CDS and other curb use cases. Linear Referencing Systems (LRS) will be able to reference CDS, and vice versa." as many cities who are looking to adopt a digitized curb inventory often already have a LRS in place (their GIS programs are usually quite good).

A couple thoughts on 1D lines versus 2D polygon:

• Visualizing curbs as lines over spaces I think is the most aesthetically pleasing, and also makes it easier to see when dealing with other data on a map. I think many tools will default to converting polygons into lines for visualization. I wonder if CDS should define a standard way to translate between the two.
• I have seen a mixed use of 2D versus 1D with open data from cities - I will say they are more likely to use 2D polygons for individual spaces and 1D lines for longer curb segments.
• Any general curb layers cities have generated (that I have seen) are always 1D lines, not polygons.
• CurbIQ currently uses 1D lines for visualization, management, and analysis of the curbside. I think regardless of the adoption, we would still visualize as 1D lines.
• 2D polygons would work better for taking disparate curb related datasets from a city and linking the data together. Up until now, we have matched relevant data to the CurbLR LRS which works, but can be messier.

Would be interesting to hear perspectives from cities and what they prefer picturing the curb as.

[nick-jonas]

Hi! Chiming in here for the first time, and very excited to see progress happening in this space. I work as the lead designer for the Pebble team at Sidewalk Labs, which is a realtime (and historical) vehicle occupancy sensor. We're starting out with demarcated spaces with plans to move to the curb and hopefully adopt (and contribute to!) whatever spec that comes out of OMF.

Currently, we have made a 2D drawing tool that overlays geometry on a map for demarcated spaces:

pebble-carousel-1.mp4

While we have used this for pilot curb deployments (non demarcated spaces), we have started think about better ways to address non-demarcated, linear curb lengths but showing "ranges" of availability. Here's an example:

The range is completely dependent on the spacing/distribution of each sensor, the field of view of that sensor, and the position of the car:

@jacobmalleau I think this falls in line with what you are saying, and I'm also very curious how cities are picturing this as well.

[cartograham]

Overall, I'm not opposed to polygons but to construct a 2D polygon, you must know something about the width of that zone for that particular location. Is the intent to set an arbitrary width/distance to construct the polygon? From the city perspective, I think there is a minor risk for going with polygons if there will be an assumed/arbitrary width (most cities will not have their individual parking lane widths inventoried)

If Curb Zones in the CDS are eventually published, mapped and graphically displayed for users to view/interact with, the assumed width may lead certain vehicles (delivery trucks, etc) to zones that cannot accommodate them.

Probably a minor issue, but wanted to float it out there.

[schnuerle]

Width should be defined as part of the spec I think. That's a suggestion in the current working document now.