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.

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.

@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!

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.

@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.

@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.

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

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.

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

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.

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.

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?

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.

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

I support the optional approach

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.