Curb Zone/Space geometry: allow lines or points

[InrixParking]

Is your feature request related to a problem? Please describe.

Curb Zones geometry should be able to be represented as linestrings as well (currently it is restricted to polygon) -- often we know the length of a curb zone but not the "width".

Describe the solution you'd like

Allow type linestring for geometry field under curb zone

Is this a breaking change

• No, not breaking

Impacted Spec

For which spec is this feature being requested?

• Curbs

Describe alternatives you've considered

We just did a workaround and created a buffer around our linestrings, but this isn't completely accurate.

[schnuerle]

Would be a new Linestring option along with Polygon for Geometry field in the Curb Zone object. https://github.com/openmobilityfoundation/curb-data-specification/tree/main/curbs#curb-zone

What do others think about this option? I know CurbIQ and ESRI either use or suggested using lines instead of polys.

When creating CDS the WG intentionally used polygons to define zones to make it clear when a vehicle was in a zone, space, or area based on GPS.

Does allowing both make the spec less consistent and harder to implement?

Might need to also add this option to Curb Space? Or maybe a Point option for space? This may need to be thought about in another Issue.

[mschwartzie]

Would love to get any feedback here. Our API is 100% compliant with Curbs specification pending this change

[schnuerle]

Comment from @MirandaBradshawPassport on closed issue #127:

Clients have expressed concerns that drawing zones and spaces on a map will be time consuming. Is dropping a single point (one lat/long) on the map to represent a space or zone considered CDS compliant? Are poly-lines to represent zones or spaces compliant?

It would save time for large operations with hundreds of zones and thousands of spaces if they didn't have to draw polygons for every zone and every space.

If a single point or poly-line is not compliant, then can we make that really explicit in the documentation?

[schnuerle]

Note per #129 that Curb Events come in as a point, which is one reason the Zones/Spaces are defined as polygons, so the single point can be inside the polygon. If a Zone is a line or point, the event location cannot be inside of it, but only near it.

[schnuerle]

When CDS was created, it was intended to sit on top of existing asset management systems or work independently. And defining the width and length of a curb zone is important if the lane widths are narrow, or wide, or cover 2 lanes sometimes (like a 2 lane hotel pull in). And sometimes they are not rectangular, but maybe more like a trapezoid. And can define a surface parking lot area. For these reasons it was a polygon.

If your source system is a line, then it's a simple mathematical transform to extrude that to a polygon of say 10 feed wide to work with CDS. And even if it's a point you can easily extrude that to a line and then polygon based on known zone lengths and widths.

[mschwartzie]

For the use case of coding the curb at scale (think: citywide), the only options are gross inaccuracies/oversimplifications OR an infeasible amount of effort to code the width accurately. Given the high level of accuracy we have reflecting the length of curb spaces, using polygons to suggest the width of the zones would be inconsistent.

For our system, we are relating events to the zones, either by proximity or hard coded in the case of sensors that are clearly monitoring specific zones. Is there a reason why this could not be a potential approach while using Linestrings? GPS is inaccurate enough that trying to ensure the events are truly happning inside of the zone has its own set of challenges.

As an aside, since streets/curbs are sometime curvilinear, extruding lengths and widths not always 100% straightforward. Again, an issue when trying to represent the curb at scale

[mschwartzie]

Just to clarify, we aren't proposing to change from polygon to linestring, but are requesting linestring be an option in addition to polygon

[jamesian-barr]

We also use unidimensional representations at the block level. Adding to @mschwartzie's point: not only does GPS typically wander 10s of meters, but there is also static data (eg: meter locations) in every single city that would fall outside of the shape, for various reasons, regardless of the shape being linear or polygonal.

[schnuerle]

We also use unidimensional representations at the block level. Adding to @mschwartzie's point: not only does GPS typically wander 10s of meters, but there is also static data (eg: meter locations) in every single city that would fall outside of the shape, for various reasons, regardless of the shape being linear or polygonal.

Yes GPS is inaccurate, and in this case it's one of a few options for pinpointing location and Event activity. Some systems and sensors can interpolate/calculate the GPS of a vehicle and provide those coordinates through CDS. CDS also requires specifying which curb Zone/Space a vehicle is using, regardless of if the GPS falls within it. In real world data so far, with low powered scooter GPS, I think we've seen in most cases that the GPS is pretty accurate in showing parking/stopping locations, which can get a better lock than a moving vehicle.

For objects outside of the Zone, I agree we anticipate that their GPS will not be in a Zone, and instead be accurately GPS placed at the curb by the city.

We've also seen GPS be more accurate over time as it's supplemented with other sensors, so maybe it's a bit aspirational, but I expect GPS accuracy to continue to be improved with sensors, connected vehicle tech, AVs, etc, so it's something to strive for in the spec.

[schnuerle]

Just to clarify, we aren't proposing to change from polygon to linestring, but are requesting linestring be an option in addition to polygon

The main reason we did not add line or point options is because some cities may choose polygons, some lines, some points, and then CDS would look a lot different in different cities.

But you are saying that you would be ok with still requiring polygons, and then allowing supplementing with lines or points? If so that seems like a very easy ask.