Skip to content

Web Conference 2021.10.19 Curb

Jump to bottom
Michael Schnuerle edited this page Oct 26, 2021 · 9 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 (2 min) - Brian Hamlin, SDOT
  2. Regulation/Event/Metrics status (2 min) - Michael Schnuerle, OMF
  3. City Use Case (10 mins) - Kim Lucas, Pittsburgh
  4. CDS Metrics Discussion (40 min) - Brian Hamlin

Organizers

  • Hosts: Brian Hamlin (SDOT), Jascha Franklin-Hodge (OMF)
  • Note Taker: Marisa Mangan (SANDAG)
  • Facilitator: Michael Schnuerle (OMF)
  • Outreach: Brian Hamlin

Minutes

Notes

Action Items

  • Need to determine common/standard units of measurements which will help define metrics (Sarah (ITE)/Jacob (COORD)/Jacob (CurbIQ)/Regina (Populus)) like we do with MDS. Things like: Time unit, Occupancy per car/non-car/linear feet
    • Defining how to go from Events to Metrics is needed
  • A flat file seems to be agreed on being needed, maybe option for dynamic API if a city wants/needs it. Flat file still allows export/tooling/maps/dashboards.
  • Comment period for Metrics in document/discussions - propose to SC w/ deadlines: 3 weeks for Metrics
  • Leave feedback at Github Open Discussion

CDS Overview

  • CDS development purpose and timeline reviewed with beta spec by end of the calendar year
  • CDS use cases for CDS curbs developed to help explain what the CDS can do to benefit public agencies
  • CCS in pilot projects reviews some best practices in pilot design
  • CDS visual chart conveying spec structure and how all 3 APIs relate to one another. Past meeting recording and slides includes a step by step overview of this structure by Michael Schnuerle, OMF

Curb Policy Use Case - Kimberly Lucas, City of Pittsburgh Dept of Mobility and Infrastructure

  • Curb as a vital resource to city generating 0M in annual revenue to city so important to get curb use right
  • Curb needs and use records are incomplete; no centralized database; piecemeal neighborhood-based studies only
  • Coord experience 2 summers ago - interns collected data using Coord platform, helped to display curb data on map, assess occupancy and revenue, compare to bike facility connections existing and potential
  • Automotus pilot in the works now - to implement smart loading zones. Barrier is that we can't mail a parking citation - it needs to be hand delivered within a short period of time. Need to work thru legislative changes to enable sending tix by mail to allow for automates enforcement to occur as part of the pilot
  • Residential parking permit program - working to allocate zones as RPP and metered zones
  • Micromobility corrals were deployed on curb in unused, no parking zones to enable more mobility options. Still see scooters outside of the zone, though
  • Other CDS opportunities identified by colleague Tosh Chambers - could help city develop own internal tool to build more sophistication in-house; autonomous vehicles will need to rely on the data; more and more services are accessing the curb for short periods so efficiently monitored zones will be key

Questions

  • Akshay Malik - any thought about pricing structure for curb pilot? Kim - Yes, are thinking about it and aim to keep it affordable while recognizing there are large corporations and mom & pop businesses accessing the curb
  • Marcus Flores, Passport - how important are e-tickets and biggest hurdles for achieving that? Kim - Still trying to catch up on mail tickets and barriers collecting payments
  • May need to have actual citations come later in the Automotus pilot
  • Brian Hamlin - do you charge for any loading zones currently? Kim - Not currently

CDS Metrics API Discussion - 5 open questions. Some responses added to Github threads

1. Use cases for curb metrics - what are your data use cases for your curb management program? What are you trying to measure and use the data for?

  • Brian Hamlin, SDOT - cities try to accommodate various uses allowed in same curb area. If we can collect the activity over the course of the day, it can help inform changes to permitted uses for certain hours. Cities can adjust regulations based on metrics data that indicates curb events and performance
  • Michael S, OMF - double parking can be defined in the curb zones. Can you get the data for these activities to ensure the metrics are meaningful?

2. Producers and consumers of metrics - who will be collecting the event data? Cities will be consuming data potentially with the help of a 3rd party or use of IT dept. Do any non-cities think they will consume the data?

  • Sarah Abel, ITE - data from other departments within an agency is critical and a good test. For ex, police enforcing the curb and monitor safety at intersections but other departments may not be thinking about curbside management
  • Stephen Hanrahan, DDOT - What would incentivize a curb user to consume events data? What incentivizes good curb behavior of deliveries aside from parking enforcement? An incentive may be to legally park/load given rules in place
  • Jascha Franklin-Hodge, OMF - How many cities see themselves producing metrics directly by analyzing event data vs. working with a 3rd party company to do the analysis? Second, For cities consuming metrics data, is an API the right form to get the data v. other ways the data can be transmitted?
    • Elias Khoury, San Jose DOT - it depends...often we do not have the tools internally to do that ourselves...sometimes it would be a mixture of both
    • Ken Husting, LA - LA may be a mixture of both.
    • Kenya Wheeler, SFMTA - In SF we would likely produce metrics in house, possibly after having a 3rd party assist with setup.

3. Methodology to calculate raw Metrics numbers

  • Michael S, OMF - seeking to keep the conversion simple while relying on a representative sample of the data. Curb SC us thinking of adding this caveat to the spec.
    • Sarah Abel, ITE - I think you have to allow it to be as opened ended input data as possible maybe with common units, but premature for metrics?
  • Jason Baskin, Coord - is this the right time to do metrics?
    • Michael S, OMF - it might be early but there is some value in having an initial set
    • Elias Koury, Sam Jose DOT - keep it as simple as possible
    • Jacob Baskin, Coord - what do we get by standardizing it at this point in the process? Can standardize the data format, for ex how we define occupancy. What are we standardizing in OMF at this time?
    • Jacob Malleau, CurbIQ - Agrees with Jacob - seems like this is something this city can decide. Does MDS have standard metrics that are provided via API?
  • Michael S, OMF - is may still be useful to have these 5 metrics aggregated over time
  • Jacob Baskin, Coord - these definitions don’t work based on how spec is written now
  • Sarah Abel, ITE - need a common unit of measure for time, same for occupancy is it per car, per non-car, linear feet? Cities want the ability to manipulate their standard which the ITE tool isn't equipped to do
  • Stephen H, DDOT - Measurement: time + length. Measure should also include zones not being used, negative curb, IE double parking
    • Michael - that should be included
  • Michael - how essential is it to compare metrics across cities? Can version 1 allow cities and 3rd parties define details?
  • Jacob - this speaks to standard data format. Comparability is something we need to focus on whether city by city or vendor by vendor. How can we get numbers that are not biased one way or another by data collection or enforcement methodology
    • Sarah Abel, ITE - for occupancy need to set a common set of values to collect. Occupancy percentage to total linear footage? Allow flexibility but ensure everyone inputs data in the same way.
    • Jacob Baskin, Coord - especially if cities hire more than one vendor
  • Regina Clewlow, Populus - I think that the key challenge most cities face is that there is a dearth of data, so we are attempting to define metrics for data that is (in many cases) “to be collected” not already in hand. I do think that it is useful to start this conversation now, as many cities embark on pilots, and as new data sources (as in with Populus) are being collected so that we are converging on a common way to measure the curb

4. Can Metrics be a flat data file or must it be dynamic? Flat file example in github discussion - for every defined areas, there's a lot of events. WG seems to be leaning to flat file. Is there any reason a city would want to filter on the fly instead of accessing data all at once?

  • Brian - setting up a dynamic API is not a trivial thing and cities would need to rely heavily on 3rd party vendors to do this. Also, don’t want flat files to sit on a shelf
  • Michael - flat file can be loaded into powerbi or tableau

5. Are real-time calculated metrics needed? WG is leaning toward not being real time by default and leave it up to agency to return data a soon as desired

  • Sarah Abel, ITE - Leave update to city based on resources
  • Brandon Patocka, City of Omaha - We have been speaking internally that companies should be billed based on the total number of trips/deliveries per (day/week/month) falling within a timeframe, i.e. (short 30 mins or less, long 30 mins or more) vs a charge by length/duration since not all areas will be suited to fit all vehicles. Also, the amount of time needed per vehicle will vary. Working with Populus - vehicles taking up same amount of space but not same amount of time. How to treat them differently
  • Michael S, OMF - can determine duration and vehicle length. Do you need it to come through in a metric or instead, calculate it from the events data you ingest as opposed to having it in metrics
    • Sarah Abel, ITE thinks it should be a metric

CDS logo

CDS Links

1.0.0 Release

Clone this wiki locally