Skip to content

Web Conference 2022.01.11 Curb

Jump to bottom
Michael Schnuerle edited this page Jan 19, 2022 · 13 revisions

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 (10 min) - Jacob Larson, City of Omaha
  2. Major CDS topic recap and discussions - (45 min) - Michael Schnuerle (OMF)

Organizers

  • Hosts: Jacob Larson, City of Omaha
  • Note Taker: Eric Mai, Lacuna
  • Facilitator: Michael Schnuerle (OMF)
  • Outreach: N/A

Recap

Notes

Action Items

  1. Insert session_id as optional field and post for comment
    • Clarify what a session is in CDS, and that it's not the same as a payment session. Duration, not payment.
    • Completed. See this comment
  2. Open a discussion for how to implement pagination given that zones and policies are separate objects returned in the same /curbs/zone API response.
  3. Specify the order that events should be returned from the GET events endpoint (e.g., reverse chronological?). Refer to MDS.
    • Added an Event Times section and linked to it from Events. Pulled mostly from MDS.
  4. Gather use cases for unique vehicle identifiers
    • Added to Privacy Guide
  5. Feedback on event_expected_duration field before adding.
    • Awaiting WG feedback before adding. May wait until later. Agreed to wait to next release.
  6. Add more examples based on use cases
    • Work in progress during RC review

Minutes

Welcome and Overview (Jacob Larson)

CDS Connections to MDS (Michael Schnuerle)

  • MDS Overview
    • Companies operate vehicles in the public right of way.
    • Cities publish policies that regulate how those vehicles can operate.
    • MDS connects those two entities and allows them to share data about the system back and forth.
    • CDS intentionally has a different scope from MDS. The goal was to start designing CDS without the constraints of MDS.
  • CDS and MDS have a lot in common
    • They're both consumed by cities.
    • Generally, the same private companies interact with both MDS and CDS.
    • Generally, the same cities contribute to both specs through the OMF.
    • They're both consistent with the OMF's architectural landscape document.
    • They're both subject to the same OMF governance process.
  • CDS connections to MDS
    • There are no direct connections (no shared specs or objects, no linking of IDs, etc.). This was by design as we didn't want CDS to be limited by MDS in any way.
    • However, there are intentional similarities. CDS references policies, vehicles, and vehicle propulsion types, which are concepts that appear in MDS as well.
    • CDS and MDS have similar processes (e.g., in terms of licensing and how releases are published).
  • There may be opportunities for additional connections between CDS and MDS in the future
    • We may want direct connections between CDS Curb IDs and MDS trips.
    • MDS is also adding new modes which may interact with the curb.
    • Policies, metrics, shared global identifiers (e.g., provider_id), and vehicle properties could potentially be pulled into a shared space between MDS and CDS.

Outstanding CDS Discussion Topics (Michael Schnuerle)

  • Session ID
    • A vehicle session begins when the vehicle enters the curb space and ends when it leaves.
    • We initially pulled session_id out of the draft but there is interest in putting it back in as an optional property.
    • Some companies who track information at the curb already think in sessions and have a session_id.
    • The initial idea was to reconstruct sessions based on vehicle ID and events, but if providers already have a session_id they might as well include it in the events they send.
    • Should we include session_id as an optional field in the event spec?
    • Jacob Malleau: Parking payment apps are an example of where session_id is known because the payment events clearly bound the session.
    • Harris Lummis: A session_id would be helpful. But the definition of a session should be the same regardless of its source (payment or sensor events), or it should be clearly distinguished based on its source.
    • Michael Schnuerle: We could clarify that in the field definition.
  • Event expected_duration field
    • In some scenarios, there is an advance estimate of how long a vehicle will stay at the curb. It may be different from the duration of time that was paid for. This information could be useful for analysis.
    • Is there any value in adding this as an optional field? Any problems with recording it?
    • Jacob Malleau: Let's clearly define what this field would mean.
    • Marisa Mangan: So there would be three durations: The duration of curb time that was paid for, the expected duration, and the actual duration. Is that overkill?
    • Michael Schnuerle: Yes, three durations. But expected duration would be optional.
    • Brian Hamlin: It seems pretty niche from the public sector perspective, but as long as it's optional and others could use it we might as well include it.
    • Nate Deshmukh: It could be useful for both historical and predictive analysis.
    • Michael Schnuerle: If a city publishes realtime information on what is happening at the curb, someone could use that data feed to visualize occupancy as well as predict future occupancy which could be useful.
    • Michael Schnuerle: Please leave any thoughts as a reply on this discussion.
  • Examples for each API
    • The three APIs now have at least two examples each, with request and response payloads.
    • We want both robust and common examples, based on our use case document.
    • Are these examples useful? What kinds of examples would you like to see?
    • Zane Clark: How would we implement pagination given that policies and zones are split apart? Would policies be duplicated across pages of data?
      • Michael Schnuerle: That's a good question, we might need to think about that more. There's not a clear analogue in MDS. That's an action item - we'll open a discussion.
    • These examples are basic, simplified, and minimal. The events example shows what kinds of information fleet operators have.
    • Zane Clark: Is there a default sort order? Are most recent events returned first?
      • Michael Schnuerle: It's probably most recent to least recent. We should check how it's defined in MDS and make sure it's clear in CDS.
    • The metrics example is CSV instead of JSON. This format should be easily importable into data visualization software like tableau. Any questions?
    • Events example: What are your use cases for the unique vehicle identifiers in event properties (e.g., vehicle_license_plate)?
      • Brian Hamlin: We need license plate for manual compliance efforts and ALPRs.
      • Eliot Mueting: Vehicle IDs are essential for payments and enforcement so we know which vehicles can use the space.
      • Marisa Mangan: Permit ID could be helpful if license plates don't exist (e.g., San Diego pedicabs, a potentially growing vehicle type)
      • Kenya Wheeler: +1 to Marisa's point about Permit ID
      • Michael Schnuerle: We need to document use cases around some of these fields to justify their inclusion in the spec. Leave comments in the Zoom chat or in Github.

CDS Launch Overview (Angela Giacchetti)

  • This will be an overview of the release process. We'll deep dive on it in the next meeting.
  • What is a launch? We need to define some terms.
  • Next week we'll launch the release candidate.
  • The release candidate is a version of the spec that has been approved by the steering committee. It's ready for implementation but hasn't completely made it through the full process. It's like announcing your candidacy for office but not having been voted in yet.
  • We're excited about the release candidate because people can begin implementing it. We want people to start playing with it.
  • There may be changes or clarifications from the approval process along the way but they should be minor for now.
  • This is the first version of the spec! We will learn and grow from here, and we want to learn from people's feedback from starting to use it.
  • The release candidate will be ready on January 25th.
  • For a release candidate to become an official release, there is a formal process with feedback from people across the public and private sectors.
  • Our open source process ensures that we release specifications that have been stress tested. There's a lot of buy in by the time it becomes official.
  • The process:
    1. Approval by working group steering committee.
    2. Review by privacy committee and strategy committee.
    3. Revisions and approval by technology council (senior technologists; both public and private but skewing toward private sector).
    4. Revisions and approval by board of directors (senior officials from transportation agencies).
  • So there may be some additional documentation and minor revisions from that process but we're excited to get early feedback.
  • We also have a blog post about this process.
  • The steering committee will vote next week. The week after we'll provide more public information.
  • This is all just the beginning, we'll deliver more webinars, documentation, and resources. Let us know if anything is lacking; we're looking to learn at this early stage!

CDS logo

CDS Links

1.0.0 Release

Clone this wiki locally