Add Curb Objects

[schnuerle]

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

From OMF’s original curb work purpose statement in 2020:

“OMF is well positioned to help cities use dynamic digital curb regulations, which could allow cities to manage the curb and adjacent infrastructure on sidewalks within the public right of way in real time and communicate the evolving restrictions, permissions, and pricing…”

We need to consider defining “curb objects” (or curb assets?) that can be defined in the right of way, including on and off street areas in and around curb zones. We previously called these “curb adjacent elements” but “objects” is clearer. This info is useful for accessibility, ADA compliance, and knowledge of obstacles for loading and unloading of passengers and goods.

Examples of objects that can be on or off the curb. Each object has basic location, size, plus custom properties.

Include definitions/activity/events for curb area adjacent elements that facilitate or impede curb transactions. Examples:

1. Trees/Planters
2. Utility box
3. Bench
4. Ramp
5. Art, sculpture, fountain
6. Signage (fixed, temporary)
7. Post box
8. Bollard, barrier
9. Surveillance camera
10. Bike rack
11. Storage locker
12. Meter pay station
13. Signal cabinet
14. Scooter parking
15. Electric charging
16. Solid waste bins
17. Lighting
18. Bus stop
19. Drinking fountain, toilet
20. Food vendor
21. Fire hydrant

What other objects are you interested in describing and then tracking use?

Describe the solution you'd like

How do we add this to CDS? Define in Curbs API and Events API.

Might need linear referencing from fixed curb point. What point is the fixed mark?

Or maybe just lat/lon like in OpenStreetMap. These objects are not affected GPS accuracy or drift, since their location is defined by the city agency.

Basic Curbs

Each object would need identical basic properties in Curbs API like:

1. Name
2. Description
3. Linear distance from fixed curb point
4. Perpendicular distance from fixed curb point
5. Max length
6. Max depth
7. Max height

Custom Curbs

Each object could have custom properties in Curbs API.

Ramp:

• Incline
• Material

Signage:

• Purpose
• Text
• Owner

Locker:

• Total capacity
• Unit capacity
• Unit cost
• Access type

Bus stop:

• Seating
• Cover
• Signage

EV Charging:

• Plug type
• Payment Required
• Hours
• Level
• Kilowatts

Street tree:

• Species
• Trunk circumference

Events

If an object can be used, also provide information in Events API.

Beyond what most current data standards (OSM, Plugshare, etc) have available because it’s based on usage that curb managers may need to know.

Some objects could have additional Event data sent like:

1. Used (sent by operator/monitor if it was used in any way: bike rack, ramp, meter, storage boxes, EV chargers)
2. Total Cost (storage boxes, EV chargers)
3. Total Energy (EV chargers)
4. Issue (could report any issue with the object)

Is this a breaking change

• Yes, likely breaking, but may be just an optional addition

Impacted Spec

For which spec is this feature being requested?

• Curbs
• Events

Describe alternatives you've considered

Some existing sources for potential lists of curb objects, properties, features, for example in OSM:

Additional context

Working group Meeting Sept 19 2023

Slide deck

[schnuerle]

At the next public working group meeting Oct 17 we will be having a discussion about:

1. Types of objects and why
2. Aggregation of object layers
3. Accessibility
4. Location notation

Please review the agenda and slides and bring your examples and ideas.

[jacobmalleau]

Some thoughts on this from the work I have done with CurbIQ:

Objects You Would Like To Standardize: The list you have is pretty comprehensive. The main items we have seen that are valuable to document are ones that relate directly to equivalent Curb Policies. This includes fire hydrants, parking meters, curbside signage, etc.

The Solution You Would Like to See:

• A big need we see for Curb Objects is that many cities already have a comprehensive dataset of curbside assets, but they don't have an effective way to easily translate this data to a set of curb policies in CDS. Having an effective way to translate between assets and policies would make generating curb inventories in CDS more accessible to a lot of cities, and bring value to tracking curbside assets as well.
• Basic Versus Custom Curbs Attributes: I think there should be a baseline set of attributes that all objects need to have, this falls along the lines of IDs, names, type, etc. Custom attributes for specific curb objects can then be added on an as needed basis in future versions. For example, if OMF focuses more on EV charging infrastructure or curb payment stations in the future, additional attributes could be added, whereas objects like trees may never need more detail.
• Location Notation: this can be similar to Curb Zones where multiple options are available for identifying location.
• Mandatory vs. Optional: I don't think this needs to be a mandatory component of the CDS spec, but it can be an optional addition to the Curbs API where assets can be associated with Curb Spaces or Curb Zones. They would then also be indirectly linked to Curb Events as well.

I would be happy to help assist or lead this effort of implementing standards for Curb Objects as this advances in CDS.

[schnuerle]

@jacobmalleau I personally agree with the solution you propose. If you and CurbIQ would like to take the lead on drafting a PR for this, that would be a welcome contribution.

I think some core details beyond the above need to be discussed, like where in CDS do these objects lay? Is there a new /objects endpoint in the Curbs API, similar to /policies? Or are they added to /curbs directly? Should there be parameters for leaving them out of the payload, like we do with policies? Or maybe they go even more top level into a fourth Objects API? Where should event properties lay in Events, maybe an array of objects that were interacted with during the curb event, with relevant fields for each object? Does this lead to any Metrics, or maybe those are left out for now?

Great to see this discussion get this far along, thank you!

[alkhoury-elias]

A new question came up on how to handle/represent a protected bike lane that is separating a parking space whether it is metered or not.

[bhamlinSDOT]

@jacobmalleau I second @schnuerle comment. I really like your thoughts on this. Let's get a Steering Committee group together to try and flesh out what this could look like in practice.

[jacobmalleau]

@schnuerle some initial thoughts on your questions (and also what we discussed in our monthly meeting):

• Where do CDS Objects Lay: it likely makes sense to treat them similar to policies as they are separate from curbs directly. We should also be able to leave them out of the payload.
• Objects and Events: similar to how events can be related curb zones, areas, or spaces, events should also have the option to be related to a given object. I feel like this is important for parking meters and EV infrastructure (although these are also directly related to Curb Spaces).
• Objects and Metrics: if the above is set up for events, then metrics would naturally flow from this.

[schnuerle]

The start of draft PR #126 for this was created by @jacobmalleau for the Nov 21 public working group meeting.

[aydarrat]

I think one thing we need to be conscious of here is to not try to boil the ocean. This is the Curb Data Specification not a new asset management system. Everything we put into this spec needs to be explicitly necessary for curb management unless we want to make it just the static asset specification. While one argument could be that you can create a specification and people can choose to populate it or not, these specs also need to be maintained overtime and our goal should be that some agencies would look to develop a "complete" version. That all said, I love the idea of objects and I think we should definitely have details about objects that are explicitly used for curb management purposes (parking meters, EV chargers, lockers, etc) I find it hard to believe some of these details on objects actually have benefit.

[Mu-yi-Zhou]

I think one curb object can apply to more than one curb zone. For exmaple, a street cleanning sign applies to the whole street block that contains several curb zones (ADA parking zone, bike station, commercial loading...). So proposing change curb_zone_id into a list of curb_zone_ids

[jacobmalleau]

My latest commit looks to address some of the previous conversations had over the last several meetings. This includes the following:

• Emphasizing that the object type list is not exhaustive and can be added to by cities
• Removed any details on specific object type attributes, leaving this for a future version of the specification to avoid including too much detail before the value of this is seen.

[jacobmalleau]

There have been several different comments relating to how Curb Objects should relate to Curb Zones, Spaces, and Areas. This includes having multiple Zones relate to an Object, have an Object be standalone, etc.

For version 1.0, are there any potential issues with making all options possible: i.e. having Curb Zones, Curb Spaces, and Curb Areas all be optional values as arrays? This way cities can choose to associate Objects with other aspects of the curb without breaking the standard. I think this covers the wide range of how cities have expressed they want to use the Curb Objects end point. I think a future version where object_types are further defined could include certain requirements for relating specific object types to the curb. For example, an EV charging station or paid parking sign Curb Object should have to relate to a Curb Space or Curb Zone, but a bench shouldn’t have to. In the meantime, I think optional values provides a good V1.0 solution.

[schnuerle]

I would like to hear from folks if having everything optional is ok as suggested by @jacobmalleau or does that fact that it is even possible at all make the scope of this difficult for you and your clients @aydarrat ?

I also like @Mu-yi-Zhou's ideas to make it apply to curb_zone_ids plural, but does anyone think this is a bad idea?

[LaurentG-AMD]

Isn't @Mu-yi-Zhou's included in @jacobmalleau's propositions of Curb Zones, Curb Spaces, and Curb Areas as arrays? The way I understand the proposition, we would have curb_zone_ids, curb_area_ids, and curb_space_ids as optional values.

I think that proposition is the only solution for now: spaces and areas are optional in the spec so we can't really force a user who chose not to implement them to then use them as references for Curb Objects.

[mschwartzie]

The optional approach would work for INRIX and is similar to how we are thinking about assets

[alkhoury-elias]

I support the optional approach

[emburnett207]

The optional approach also makes sense to me here. I appreciate @aydarrat's comments about the scope for things like this, too- it may be helpful to discuss at some point to define what qualifies as necessary curb management objects.

[jiffyclub]

Linking over to #147, it seems like the Curb Object concept could also be a useful way to inventory sensors that are monitoring the curb, and the meters/paystations people use to pay at the curb.