Web Conference 2021.09.07 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 status (5 min) - Michael Schnuerle, OMF
  3. CDS Metrics API Discussion (40 min) - Populus

Organizers

  • Hosts: Brian Hamlin (SDOT), Populus, Michael Schnuerle (OMF)
  • Note Taker: Brian Hamlin
  • Facilitator: Angela Giacchetti (OMF)
  • Outreach: Brian Hamlin

Minutes

Notes

Action Items

  • Review GitHub Curbs API document
  • Provide feedback or comment on 5 Events discussion topics
  • Thoughts on curb productivity index?
  • What part of CDS would land use data be included (if included at all)?
  • Decision: data returned as dynamic queryable API endpoint (by combinations of date range, time, geography, Area/Zone/Space)

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 CDS meeting is scheduled for Sept 22 (Wednesday) and the topic is TBD. Curbs, Events, Metrics API Status (Michael Schnuerle)
  • Michael provided an overview of the CDS API outputs and how they are connected.
  • Update on CDS. Architectural decisions, curbs use case document. Lists common use cases for CDS and how to implement those use cases using CDS
  • We now have a first draft of the Curbs API. It is now in GitHub and ready for everyone to review
  • 6 high level discussions about the design of Curb API, we’ve reached a consensus and these have been included in the Architectural Decisions document
  • Events API
    • The decisions that have been made are included in arch doc
    • 5 discussion topics need more feedback
    • WGSC needs to create endpoints and examples in the Spec Draft document
  • Metrics API
    • Some listed in comments will not be possible to be included in API
    • Plan to have more discussion topics after today’s meeting

CDS Metrics API Discussion (Jean Kao, Populus)

  • Jean led the discussion on how Populus measures success at the curb. Put together ideas on what common metrics consistently pop up during conversations.
  • Many different types of curb uses and curb use case areas. Land use and location of the curb.
    • 1st version will be access for people and access for goods.
    • Different based on curb location. No one metric can capture everything.
    • Successful curbs are based on how the city prioritizes that curb and if it is being used the way it is prioritized
    • Key Metrics
      • Total Events: total events that happen over a specific time period. (many cities don’t actually have this data)
      • Turnover: how many events are happening per hour
      • Average Dwell time: average amount of time a vehicle is spending at the curb. Great metric to know if the curbspace is being used as intended
      • Occupancy percent: amount of dwell time divided by the duration. Cities want to make sure the zones are well used but they are still available when needed
      • Curb productivity index: Interest in measuring curb productivity. Based on Fehr & Peer’s study. Measuring the number of passengers being served at the curb. Challenging to use for other types of loading because there are so many variables. Took the idea and normalized based on length and dwell time. Occupancy as a function of both time and space. Initial proposal to start the discussion.
  • Michael: Should the Metrics be served up in a machine readable way and an endpoint (3a) or just provide methodology and publish static data reports in a spreadsheet format (3b)?
  • Sarah Abel (ITE): Should go queryable API. Shoutout for ITE curbside management tool which is manual. Need to move towards highest and best use. We are missing land use.
  • Sarah: Types of uses adjacent to the curb depend on the demand at the curb. Dynamic curb management is highest and best use of the curb space. Some building have VERY high demand while other buildings have NO demand for the curb. One way to capture this could be FAR for the different types of buildings. DC example of shared loading docks/areas. Could be a model for how to do this.
  • Jacob (CurbIQ): How will static data allow for more granular data? You would need access to everything if you wanted.
  • Michael: Option 3b would possibly need to provide all of the raw data. People could get different results with the same data if the metrics are not pre-canned
  • Akshay (Philly): Prefers 3a. Dynamic aspect of Curb Management is a fairly new concept. Hard to pin down what we actually need. Would like a slide rule to measure specific areas and not others. Need to be able to capture a lot of contextual issues (nearby construction, closures, etc). 3a would be needed in order to capture and filter these issues out to be able to present accurate data
  • Kenya (SFMTA): Dynamic endpoint makes the data more accessible to other groups. (researchers, consultants, etc.) Need to think about how we capture throughput in the future
  • Sarah (ITE): Trip generation manual, shifting from vehicle to person trips. (to measure site development) Could reference this new document coming out in September. There is a consistent metric for cars. More consistent then less is recommended. Other countries measure all modes consistently. We could look towards that. Shift from person trips to vehicle trips.
  • Michael: Is anyone doing counts of people and/or goods? Are there sensors that can capture this?
  • Regina (Populus): Pilots around e-cargo bikes. Measuring mode is very important. How to incentivize more efficient deliveries? Lower pricing, better hours, etc. If a delivery company is using a certain type of vehicle.
  • Elias (San Jose): Program that provides free parking at a meter if you are using a clean air vehicle. Program likely going away soon because so many trips are now being done with clean air vehicles.
  • Tom (LADOT): Zero emission delivery zone pilot. 1k zones worth of data collected to find the most used load zones and then seeing how these zones line up with communities with poor air quality. Plans to scale it up with lessons learned from the pilot.
  • Michael: Curb productivity index, any feedback?
  • Akshay: Events metric, is it like bundling up bookings, cancellations? Will those be able to be parsed out?
  • Brian: If you have access to the events you should be able to pull the bookings and cancellation data
  • Michael: Out of 4-5 metrics shown, is there a big metric that anyone feels is missing?
  • Elias (San Jose): Likes it because it is a unique and new concept
  • Kenya (SFMTA): would also be very useful. You could take it a step further by including the land use information into the calculations because your productivity will vary greatly depending on where you are.
  • John Good (Ford): Very valid contextually information of land use. We need to be context aware. Would the land use data be included in the Curb API
  • Brian (SDOT): We would likely include land use info within the Curb API/endpoint