Which Vehicle Properties are essential to know about?

[schnuerle]

CDS needs vehicle properties added. What properties need to be added? Is permit number needed (would be optional and sent only in company feed)? Already have vehicle length. Class? Loading side? Back ramp? Drones deployable? Etc.

How would these be added to the Events API? Currently vehicle_length is just a field in /events, but maybe instead it's an array of vehicle_properties in /events we define.

Already have vehicle_type and propulsion_type, like MDS. This would be an additional vehicle_properties object.

[schnuerle]

Per the discussions, it seems the working group is leaning toward:

1. a vehicle_properties array with length, class, type, and propulsion

[marcf08]

I may have missed the discussion here, but can you elaborate on type? One that might be of interest is "TNC," which might represent a private vehicle that is occasionally used as a fleet. Uber and Lyft are common examples here, but they are not the only ones.

[schnuerle]

This should be physical properties about the vehicle itself. For TNC, that would go under passenger_transport in activity_type. See below for a discussion.

[bhamlinSDOT]

I think we are in agreement on what vehicle properties are essential. Vehicle_id I dont think is essential based on comments but we do have it in our spec as an optional field which will still allow cities that have LPR or digital permits to require that information if needed. (Seattle would use this eventually)

For vehicle_type I understand that we want to align with MDS but something we may want to consider is the Urban Freight Lab's Vehicle Typology and Activity Type classification methology. The methodology is outlined on pages 9-12 and Appendix A of the linked report. Seattle has been using this strategy for our parking studies with pretty good success. There are limitations if you want to classify activity types for private vehicles being used for commercial purposes but that could be an optional field? I also noticed that (I think) CDS doesn't have activity type in our Event's data. Should this be something that is included?

[schnuerle]

For vehicle, it looks like this screenshot is for 4+ wheeled larger vehicles, which may be a lot of CDS users but we want to include the other vehicle types out there that MDS and GBFS includes like bike, scooter, cargo bike, moped, etc. This list is almost a sub category of items under 'large vehicle', though doesn't seem to include all large vehicle types cities may be interested in. We may start simple for now with MDS types, and work with UFL and MobilityData to change this up, especially as we get into Modes in MDS 2.0.

Activity type does seem like a good thing to have in Events. Again though I'm not sure these categories break it down in the way cities would like to see. For example, there is not a distinction between food delivery, taxi/passenger PUDO, or package delivery under Commercial. But we should come up with a list and add activity_type as an optional field in Events.

[lummish]

Agreed that activity_type would be a smart inclusion. In terms of enumerating these types, this is what the Automotus team recommends:

• passenger_transport: Picking up and/or dropping off of human passengers
• food_delivery: Delivery of food items ready for consumption
• parcel_delivery: Delivery of parcels
• construction: Construction of hard assets including buildings and roadside infrastructure
• waste_management: Retrieval/disposal of waste
• unspecified: Unknown or unspecified activity type

One remaining unknown is how and when to make the distinction between parcel and food delivery. Our team's position is that food_delivery should be reserved for the delivery of food goods to an end consumer (e.g. a pizza), while the delivery of bulk food goods to a restaurant or other business should be considered a parcel_delivery. The underlying assumption behind this position is that cities will be interested in understanding curb usage of door-to-door food delivery services independently of more commercial-oriented food delivery operations.

We'd love to get some feedback from cities on this matter, but when we do decide it will be important to specify the distinction.

[schnuerle]

Thanks @lummish - these activity types are added here, with some extra description around food/parcel delivery

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/events/README.md#activity-type

[schnuerle]

Talked about adding motorcycle to list of vehicle_types. Will add that now.

Also the current list needs to be reviewed in the truck/van/freight realm. A SFMTA call for 'six wheel vehicles'.

Here's what we have:

truck | A light or heavy duty 4 wheeled truck
van | A van with significant interior cargo space
freight | A large delivery truck with attached cab
other | A device that does not fit in the other categories
unspecified | Unspecified

[schnuerle]

For activity_type, we talked today about adding a lot more to the current list:

passenger_transport | Picking up and/or dropping off of human passengers
food_delivery | Delivery of food items ready for consumption to an end consumer
parcel_delivery | Delivery of parcels, including bulk food goods to a restaurant or other business
construction | Construction of hard assets including buildings and roadside infrastructure
waste_management | Retrieval/disposal of waste
unspecified | Unknown or unspecified activity type

Possible additions include:

emergency_use - includes ambulance, fire truck, police
road_maintenance - includes pothole patching, striping, snow plowing, street sweeping
special_events - includes unloading equipment for concerts, theatre, street events
utility_work - includes public sector activity like sewer, water, telecoms
service_vehicles - includes private sector activity like
vehicle_parking - includes private or commercial vehicle free or paid/metered parking
vehicle_charging - parking for electric vehicles to charge
device_maintenance - includes scooter pickup, drop off, battery swapping

[schnuerle]

I created a new activity_category with high level items, and refined the activity_types. It's written in a way where both are optional, and not depended on each other (eg passenger_transport category and public_transit type are not explicitly connected, but both can be provided).

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/events/README.md#activity-category

[lummish]

We may need to modify the Curb Policy schema to accommodate these activity types. Currently, the list of activity types in the Policy schema are more focused on the interaction of the vehicle and the curb rather than the function that the vehicle is serving (e.g. parking, stopping). I would imagine that the activity type/category as defined here could be relevant for determining how policies are applied to a particular session at the curb––for example, a zone with a "no parking" policy may be a region of red curb designated for firetruck usage. In such a situation, we should consider an activity with category emergency_use and type fire as compliant with the policy. I don't believe the current design accommodates this.

[schnuerle]

Agree, looks like we should consider aligning Curbs API activity with Events API activity_type/activity_category. But couldn't one argue these are different things? Eg the rules being broadcast at the curb (no parking/loading zone) are different than the activity happening at the curb (parking/unloading) and the detail at which you specify both?

Is a related problem here that it's called activity in Curbs, which is maybe confusing and implying a connection to activity_type?

https://github.com/openmobilityfoundation/curb-data-specification/tree/feature-release-work-1/curbs#activities

[schnuerle]

activity_X in Events may be renamed to purpose_X.

It may need to be cut entirely, or at least make it free form (like user_classes in Curbs) with a provided list of suggested or well known values. In the latter, the list should be collapsed into one list instead of type and category, like event_purpose.

It may not always be knowable, but where it is possible this information can be conveyed, and this list provides some recommended known values.

[schnuerle]

I've merged all the listed activities into one list, renamed it event_purpose, added some clarifying language, and made it clear these are well-known values but local users can make up their own (similar to user_classes in Curbs API).

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/events/README.md#event-purpose

[schnuerle]

Should we try to align Curbs API user_classes which has some suggestions but is free-form, with Events API vehicle_type and propulsion_type? Just flagging this for discussion. Maybe user_classes could point to what's in Events and then still allow free form?

This also gets to (like activity types) how connected Curbs and Events are. Do they need to align? Will they be used to enforce activity at the curb, in which case they should align, or is that outside the scope for now?

Curbs:
https://github.com/openmobilityfoundation/curb-data-specification/tree/feature-release-work-1/curbs#user-classes

Events:
https://github.com/openmobilityfoundation/curb-data-specification/tree/feature-release-work-1/events#vehicle-type

[schnuerle]

User classes are currently any combination of mode/activity, vehicle form factor, and propulsion type.

Need to specify this array is 'AND' when listing them together, and create a few more examples in the suggested list for other user classes maybe categorized by category of user class (eg, a list of well-known values). Disclaimer about how it's not a mirror of what's happening in the Events API.

[schnuerle]

Created an organized list of well-known values for user classes, and added clarifying language:

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/curbs/README.md#user-classes