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.

[mplsmitch]

My experience has been that GNSS/GPS accuracy is good in clear sky locations but in urban areas it's hit or miss. Because it depends on line-of-sight, the location accuracy around tall buildings can be pretty far off because of multipath errors. There's an explanation of why this is the case here: https://www.gps.gov/systems/gps/performance/accuracy/

There's a good app for evaluating accuracy here: https://github.com/barbeau/gpstest

[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

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.

We are proposing that polygons not be required, but rather the format could be polygons OR linestrings (or points). Sounds like this might cause an issue with how this was envisioned, but maybe this is something that works at this stage of the spec and if there becomes a clear benfit to one way or the other (and/or the consistency issue becomes paramount) down the road, this could be revisited.

[jacobmalleau]

We currently use lines for curb zones as several of our clients prefer this. We can convert these lines into polygons using an assumed width to align with CDS but would be great if we could have lines as an option.

[bhamlinSDOT]

Seattle records all of our curb spaces linearly which meets all of our current needs. (you can view what we use today here) (Note that this data is not in CDS format but will be in future). Having a polygon would be much more difficult to maintain as our travel lanes that define the curbspace width can vary widely all across the city not to mention even on the same block). I can see the value in having polygons as a way to bucket "events" but I'm really not seeing this use case in practice. (if you are please let me know)

Looking at the comments and conversation above, it seems like there is decent support to allow lines for curb zones. I am actually leaning more towards making lines the required and polygons as optional as I see far more line data sets being used. I am less inclined to allow for points as I believe one of the greatest values of CDS is being able to easily see how long a curb space is. I think a point would be more of a curb object such as a sign post. (which may not line up exactly at the head of a curb zone)

[kalvingreer]

The majority of clients that I work with when it comes to interacting with curb-level spaces or, as we define them - entities - at times don't have any data to showcase what spaces exist on the street or have some version of legacy data. Going back to Miranda's point from a while back in this thread and agreeing with @mschwartzie, I don't think we need to move away from polygons; however, supporting a single point (typically a lat/long location) will be a much lower barrier of entry for cities looking to do this for the first time. If later on they decide they want to go more in-depth with full polygons they can always add it but that comes with much more expense.