Web Conference 2025.04.22 Curb - openmobilityfoundation/curb-data-specification GitHub Wiki

CDS Working Group

Agenda

Pushing Real Time Events w/ CurbIQ

  • Welcome (5 mins)
  • Announcements (15 mins)
  • Pushing Real Time Events (40 mins) w/ CurbIQ
    • Publishing events via "push" : PR #180, Issue #99
    • Event types for real time enforcement: PR #179, Issue #173
    • New Metric Type to Handle Additional Demand Sources : Issue #174

Organizers

  • Hosts: Jacob Larson - Omaha, Kenya Wheeler - SFMTA
  • Note Taker: Mitch Vars, OMF
  • Facilitator: Michael Schnuerle, OMF
  • Outreach: Michael Schnuerle, OMF

Action Items and Decisions

  • Continue discussion of open PRs on GitHub so we can get these completed in accordance with the release timeline.
  • Deadlines: May 9th -  issue submissions May 31- PR submissions ...

Minutes

Notes

Announcements -  Michael Schuerle (MS)

Open Mobility Mixer coming up in Louisville as well as other events on OMF calendar

CDS 1.1 Release is coming soon

Release plan and deadlines.

  • May 9th -  issue submission deadline

  • May 31- PR deadline

  • July '25 - Release Candidate Finalization

CDS Steering Committee Elections - Call for nominations coming up. OMF members will receive email.

Brain Hamlin ( BH) - Seattle's public CDS APIs Web map and public facing APIs, including Events are now available for use. Event data will be backfilled with data from month of April by end of week. Documentation available. Looking for public feedback.

Pushing Real Time Events (40 mins) w/ CurbIQ - Jacob Malleau (JM)

Adding Enforcement Attributes to Demand Data #179

(MS) Two related issues bundled in this PR, event types for realtime information and new metric to handle additional demand sources. Realtime info includes 3 new types of events: citation given, vehicle read, and vehicle flagged. Metrics for count of total events.

Jacob Malleau (JM) - CurbIQ has a couple of projects requiring enforcement data. The spec lacked enforcement related data fields. The proposal adds new enforcement related event types. In the case of LPR vehicle detection these events could also be used for occupancy.  This PR can be used to add additional event types that users feel CDS doesn't currently capture.

(BH) would this be suitable for surveys of spot time occupancy counts? 

(JM) - Yes, this could be extended to any manual survey where you collect a one time survey of the street without beginning /end to events. Maybe the definition could be made more generic, less focused on LPR. Could be used to make data collected in parking studies more consistent.

Michael Danko ( MD) Suggest changing vehicle_read to something more general,  less tied to LPR such as vehicle_detected. 

JM - Yes, agree, could make it more generic

(MS)  - Could remove mention of LPR from definitions to make more generic, fields could be reordered to make them more logical.

Kenya Wheeler (KW) Maybe vehicle_present. Would it be helpful to have a boolean to indicate if a vehicle is present in a space/zone?

Rick Neubauer ( RN)  We need to distinguish between different event types, camera start, payment event start, payment end, citation start etc which would all be part of one session. 

(MS) Session is calculated by looking at a series of events. Citation array could be added that could associate them with a specific curb zone.

David Von Stroh (DVS) Should there be a place here to include citation categories?  And related to that, a place to indicate tow events, which would help recreate historical status data?

(RN) Citation categories exist in UMOJO backend but no place for them in CDS.

(MS) Would need a citation array to hold data. Someone might want to open a PR to address how citation data could be recorded.

(RN) Could use a separate object for citation information that could be tied to session ID. 

(MS) Citations could be separated from transactions etc with a new object for each. These could be optional and non-breaking. Intentionally left out of first version - Feel free to leave comments on PR.

Publishing events via Push mechanism #99, Push Events Endpoint #180

(MS) Ability to push event data has been talked about fir some time. We now have a PR to add an optional endpoint. Modeled after how this is done in MDS. 

(MD) should be able to handle push of same events more than once

(MS) clarifying could be added to definitions in acceptable responses list

(JM) don't need to specify who would create /use this, would probably be vendors, not city.

(MS) should add some language about who the potential users of this are

(BH) Would this be up to the city to require this? Would this be optional for vendors to decide push vs pull?

(MS) - would be optional as required by cities. If city wants to use push they would require it of vendors, however the  pull method should be preserved so that historical data can continue to be pulled.

(MD) -  Decoupling of what data is being sent with how data is sent. Should CDS mandate the how? Is there a disconnect in how data is transferred in that some APIs require pull?

(MS)  - MDS handles this question with the policy requirements API, allowing cities to specify requirements at endpoint and field levels. Maybe that should be the approach in CDS

(MS) Leave comments of #179 on Github so we can get these completed in accordance with the timeline.

...