Skip to content

Web Conference 2021.06.15 Curb

Jump to bottom
Brian Hamlin edited this page Jun 18, 2021 · 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 (5 min) - Michael Schnuerle, OMF
  2. Curb policy use case (10 min) - Kenya Wheeler, SFMTA
  3. Regulation spec recap (5 min) - Michael Schnuerle, OMF
    • draft document: polygon areas, linear referencing decisions, spec creation
  4. Events spec discussion (40 min) - Harris Lummis, Automotus
    • Data included in each event
    • Data sources possible
    • Pull vs Push API setup

Organizers

Minutes

Notes

Michael Schnuerle (OMF) provided a brief introduction and detailed the working group process

  • OMF Vision
  • Implementation phase background
  • Short-term scope – CDS focusing on commercial loading activities
  • Today’s call will be focused on CDS Events spec
  • Upcoming meeting will be on June 30 (Weds) meeting will recap Events and begin discussion on Metrics specification

Curb Policy Use Case: Kenya Wheeler (SFMTA, WGSC member) discussed how SFMTA is using the curb digitally and how CDS could help improve their workflow

  • Lack of loading space creates safety hazards
  • Mismatch between curb allocation and how people get around. 90% of curb space is dedicated to storage of vehicles. This does not align wit SF’s goals
  • New curb management strategy created an updated curb hierarchy which prioritizes active uses of the curb
  • Shared Spaces Program allowed SF to test new prioritization model
  • Would like to use CDS to help with SFMTA to develop a holistic curb asset data model
    • This will also include public facing tools and APIs to interact with curb data

Regulations Spec Recap: Michael Schnuerle (OMF) led the recap from last weeks Regulation Spec discussion

  • CDS will be starting out with a polygon definition of curb areas
  • Use of linear references will be optional but strongly encouraged. Being optional will allow more to participate
  • CDS will use UUIDs to uniquely identify all areas
  • Drafting of CDS will take place in a working Google doc here. It will eventually be moved to Github for a more formal review
  • Geometry graphic shown. Jacob Baskin (COORD, WGSC member) suggests calling curb Curb Zone
  • Marie Maxham (E&A) recommends that the regulations and areas should definitely be separate
  • Michael recommends that comments on Google doc should be provided by end of June or by July 13th meeting at latest

Event Specification overview led by Harris Lummis (Automotus, WGSC member)

  • Main Points:
    • What data is included in each event
    • Enumerate the types of data sources
    • Standard way to send event data
  • Events will include real-time and historic data
    • This will be a standard way to send event data
  • Automotus submitted an Event Spec and what it might look like (early draft)
    • Highly encourages everyone to provide feedback on what and why certain things are included in the Event Spec
  • Jacob (CurbIQ): Arrive and depart time, should there be a status attribute?
    • Harris: This is included in the spec. Graphic was just showing the historical event
    • Michael: Envisions that Events will come in as they change rather than being able to ping the space to see if a vehicle is occupying it
  • Ryan (Fantasmo)
    • What happens when the space itself changes? (curb change to dining or something different?)
      • Michael: These changes would be captured in the Regulations side of the spec
      • Jacob (COORD): There are great discussions on this topic on the wiki page.
  • Jascha (OMF)
    • It might make sense to document the specific types of sensors that would generate Event data.
      • We can validate what type of data is actually needed
      • What do we want to measure from the space?
      • How does ALPR mounted on trucks work with this?
        • Might provide point in time data that should be included
  • Mary Catherine Snyder (SDOT)
    • Different vehicles length that could occupy the curb?
      • Harris: Absolutely incorporated in spec.
        • 2-ways to report occupancy
            1. Counting the number and type of vehicles occupy a curb
        • 2 ways to measure occupancy
            1. Curb zones that are subdivided
            1. Curb zones that are not subdivided
        • Computing occupancy was not incorporated as part of the event spec. It is see as separate and up to the owners to decide
          • Michael: Realtime occupancy is always optional. If reported out on it can be included in regulations
    • How do you handle sensors, vehicles and other devices being on different sides of the road with only GPS?
      • Michael: Devices should know what the curb area is and vehicles will report which curb area they are using. GPS locations and what side of street is taken care of events processing referencing the regulations
    • Turning events into occupancy
      • Jacob (COORD): This is out of scope. OMF could see what everyone aligns on though and just adopt
  • Events Spec: Push vs Pull?
    • Pull
      • City (or agency/third party) checks source
      • This mirrors provider API in MDS
      • City can get historical data whenever they want
      • Issues:
        • Maintain an inventory of all of the source operates and have to pull from all of those. This can be complex from implementation perspective. Lose “real-timeness”
      • Lacuna is more favorable to push style
    • Push
      • Operators of event sources publish to an endpoint that is defined and operated by the city
      • City operates a single end point
      • Benefits:
        • Less complex, and less redundancy, more “real-time”
    • Jacob (COORD): Push can be complex when you have to manage fan-out and retries and registration
      • Usually people default to pull. If database goes down, push will lose all of the data
    • Jack Reilly: Is there a proposal for both push and pull?
      • Michael: MDS has both. It has become cumbersome as spec grown, and he would prefer to just pick up.
      • Ryan Measel: Requests that both are included

Next Steps Michael:

  • If you are interested in participating there are a list of ways and options. Please check last slide of PPT

CDS logo

CDS Links

1.0.0 Release

Clone this wiki locally