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

Web Conference - Curb Working Group

  • Every other week Tuesday call at 9am PT / 12pm ET / 6pm CET

Conference Call Info

Meeting ID: 898 5980 7668 - Passcode 320307
https://us02web.zoom.us/j/89859807668?pwd=ZzJrbEpTNVB4WkNqNiszcmFYVzBwZz09

One tap mobile: +13126266799,,89859807668#,,,,*320307# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Agenda

Main Topics

  1. Welcome and process (5 min) - Brian Hamlin, SDOT
  2. Regulation/Event/Metrics spec recap (5 min) - Michael Schnuerle, OMF
  3. CDS Events API Discussion (50 min) - Harris Lummis (Automotus)

Organizers

  • Hosts: Brian Hamlin (SDOT), Harris Lummis (Automotus), Michael Schnuerle (OMF)
  • Note Taker: Tomas Carranza, LADOT
  • Facilitator: Angela Giacchetti (OMF)
  • Outreach: Brian Hamlin

Minutes

Notes

Action Items

  1. New Discussion Areas
    • Event Types and Vehicle States - event_type and vehicle_states - what to add, how to structure - what can you measure + what do you want to measure
    • Endpoints: Events and Status - Endpoints for GET /events (list of events by recency, therefore RT and historic) and GET /status (current state of curb usage)
    • Provider IDs - global like MDS, or per city? - How are provider IDs handled? Globally unique like MDS in a file? Locally unique and managed by each agency as fleet registration happens? Does every company get 1 ID, or could company divisions (Freight, Ground, etc) have their own IDs?
    • Vehicle IDs possible - What types of vehicle IDs are possible? License place number, unique UUID provided by provider like MDS, VINs, registration number, etc. Could be an ID that is agreed upon by city and operator.
    • Vehicle Properties - Add vehicle properties - what properties need to be added? Permit number (optional and sent only in company feed)? Already have length. Class. Loading side. Back ramp. Drones deployable.
  2. Add examples in doc for data sources (sensors, company feed, cam, etc) to show how optional fields can be used.
  3. Clarify that policies are not active or enforced except between the start/end times listed in the policy.

Decisions

May need to add this to the Architectural Decisions doc.

  • Curb Areas can overlap. Add language, make array in Events
  • Endpoint Push is too hard for this version, so everything needs to be Pull
  • Sensor status should come through in this feed to make it easy for consumers (no cross checking needed) to know sensor operational status
  • Mimic MDS/GBFS structure for vehicle_type and propulsion_type, starting with what's in MDS/GBFS, but defining values here in CDS, then aligning them more directly with the future MDS 2.0

Minutes

Working Group Process (Brian Hamlin)

  • Brian welcomed the attendees and provided the group with background and an update on the Curb Working Group.
  • The CWG has moved into the implementation phase which includes the expected release of the beta version of the new Curb Data Specification (CDS) at the end of the calendar year.
  • CDS outputs will include 3 main focus areas - curbs, events, and metrics. Today’s focus is on events.
  • The next CWG meeting is scheduled for Sept 7 and will focus on the Metrics API.

Curbs, Events, Metrics API Status (Michael Schnuerle)

  • Michael provided an overview of the CDS API outputs and how they are connected.
  • 6 high-level discussions on key topics for the group are available on GitHub for Curbs API. While some issues have been resolved in these discussion threads, comments and feedback is still encouraged.
  • One item that would benefit from group discussion is related to establishing a push versus pull system. How should we standardize the way data is sent from companies or sensors to agencies for Events API? (Note we end up deciding on Pull later in the meeting)
  • The Steering Committee would also like feedback on which metrics should be included in the Metrics API. What do we want to see measured?

CDS Events API Discussion (Harris Lummis)

  • Harris (Automotus) led the discussion on the Events API and how agencies using CDS can potentially collect curb-related real-time and historic events data.
  • Each recorded event can be captured as an object. Event information includes a unique identifier, type, category, source, location, and time.
  • Event types can include several values and depend on the communications protocol from the agency or event organizer. Event types are the possible transitions between some vehicle states (i.e., drop off, pick up, reservation, trip start, trip end, etc.).
  • Michael: we should strive to align the events with MDS eventually in a future release, and add vehicle_states
  • Regina Clewlow (Populus): the initial orientation seems to be on sensors placed in the public right of way, so data would be coming from cameras or sensors and not from vehicles. This can lead to challenges and complexities.
  • Jacob (Coord): one consideration in establishing the Events API is to follow the lead of traditional parking studies and what these studies collect and observe.
  • Jacob: with the Events API, we should see what’s happening now and collect information on when things change, like a vehicle starts to move.
  • Harris: Curb event object fields include vehicle occupancy and the occupancy fields contain vehicle type, length, and location.
  • Jacob: would the current structure being proposed be able to accommodate historical event data?
  • Question from the group: how will the data be used? For the collection of historic information or to inform real-time decisions. The system would allow you to pull information (say, every 30 seconds) and see if there are any changes.
  • Jascha (OMF): it seems like some metrics would be easier to derive from polled “current status” data (occupancy level) while others would benefit from event data (dwell time). We should consider finding a way to represent both, depending on the data source.
  • Jacob: we may not want to exclude a “push” system in the 1st CDS version due to its complexities but create a spec that doesn’t preclude us from integrating a push system in the future.
  • Jascha: do we want to start with a system that is more focused on individual data sources and see how we can coagulate it into a single spec?
  • Michael: lots of fields but some are optional or conditionally optional. There can be flexibility and we can set up a system that just sends out what’s relevant. But we first need to flesh out some examples to see if the spec actually offers flexibility. Otherwise we will have to define spec differences for each curb user or event data source.
  • Harris: curb event object fields include geographic properties – zone, area, and space. Not all curb zones are demarcated into stalls. Every curb space is inside of a zone. Can Areas overlap?
  • Another curb event field is a provider ID – a unique ID of the provider responsible for operating the vehicle at the time of the event, and provider name. Capturing provider names includes several complexities too.
  • Akshay Malik (Philadelphia): Philadelphia has a fleet registration program – if you have more than 3 vehicles in your fleet, then you register and your vehicles are given a unique identifier. But companies are concerned with this data becoming public.
  • Harris: for curb event object fields, vehicle information would be sent by the company or by a sensor. Vehicle attribute information could include vehicle ID, length, type of vehicle, propulsion type, and lane type.
  • Events API was not meant to be a tool to get the status of your sensors. There is a “communication lost” field that can be included as a possible curb event type. This gives you information if a sensor is down. However, let's agree this is useful and will be included.
  • Michael: we will strive for alignment on vehicle and propulsion types when MDS goes to 2.0. The first release of CDS will be developed independently to accommodate CDS and MDS use cases, but CDS will align with MDS design principles.
  • Akshay: there is a gap in cities when we notify people of a regulation change to when that regulation takes effect to include a grace period for enforcement. How can we deal with this? New regulations can be input with start dates to deal with this gap.