Skip to content

Web Conference 2021.10.05 Curb

Jump to bottom
Michael Schnuerle edited this page Oct 18, 2021 · 11 revisions

Web Conference - Curb Working Group

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

Conference Call Info

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZ0lcuCgrjwsHNyZRagmc86b12iCmWGBHfjq

Agenda

Main Topics

  1. Welcome and process (5 min) - Brian Hamlin, SDOT
  2. Curbs/Events/Metrics status (5 min) - Michael Schnuerle, OMF
  3. Use Case Presentation (10 min) - ITE, Sarah Abel
  4. Discuss open Events API Questions (40 min)

Organizers

  • Hosts: Brian Hamlin (SDOT), Michael Schnuerle (OMF)
  • Note Taker: John Good (Ford AV)
  • Facilitator: Angela Giacchetti (OMF)
  • Outreach: Brian Hamlin

Minutes

Notes

Overview of Meeting, provided by Michael Schnuerle (OMF)

  • Meeting to focus on the Events API (today)
  • Next meeting Oct 19 will be on Metrics
  • Next target date: November 2 - review state of APIs on Github
  • Need to review all the potential use cases, and the modular nature of CDS to apply to each (see structure diagram in slides)
  • Also, introducing a pilot project guide; on the technical side of things, quite useful to describe how you can do something with CDS in your city
  • Documenting our architectural decisions for CDS, why we came to our decision (some technical, some in/out of scope decisions)
  • For Curbs API: A number of discussions we have already reached consensus on. Within the next week, we will merge that to the main branch
  • For Events API: we have already have had some discussions on key topics, e.g. data sources. A lot of the remaining 5 discussions – we will fill in additional information at the end of today’s discussion
  • For Metrics API: a big open question - how dynamic should it be? Should it facilitate all combinations of location/type, etc? Or should it be a more static file where end-users could combine data on their own? Next meeting.

Guest Presentation: Sarah Abel, ITE (a presentation on ITE's own curb work)

  • ITE Curbside Management Tool: A lot of what we are trying to
  • ITE + FHWA = open-source and free tool / a GIS plugin tool that you can find in Github
  • You can find the tool on the ITE website, search curbside management (https://www.ite.org/technical-resources/topics/complete-streets/curbside-management-resources/)
  • A sample dataset from Pittsburgh is provided
  • A sample data worksheet from 2 different agencies
  • Note: This tool currently uses the SharedStreets API for linear references.
  • Temporal weighted networks: Recommends a set of curb treatment priority options, gives you a scale of different priorities.

Tool Components

  • TO – Get SS Features
  • T1 – Convert CurbLR to Feature Class (with Dashboard)
  • T2 - Prepare Linear Reference Correspondence
  • T3 - Generate Curbside Statistics
  • T4 - Curbside Treatment Options (with Dashboard)

[shows example of tool]

  • This is what the dashboard looks like, it runs in ESRI ArcGIS Pro

  • The current statistics – recommended treatment allocation

  • The right-hand side

  • Adding a bike lane, street trees, etc.

  • Weights them, based on the priority it thinks you should give them

  • Sample: It gives you more options than you can allocate along the available curbside space

  • ArcGIS Collector – for Curb Inventories

  • Mobile Data Collection Tool

  • If you were to run the tool as a script, suggested outputs under Tool Component 4

  • How this is allocated, based on field names/descriptions

  • This is an ongoing discussion I know

Question from Michael: on Slide 4, you explain how something like SharedStreets would fit in

  • I’m trying to think about how CDS would fit in, as we are not intending for CDS to be a complete replacement

  • CDS sits on top of SharedStreets or any other LR system. We mostly relied on CurbLR, but we offered agencies a way to manually input data.

  • Do you have how a thought about how other tools could be integrated? Response from Sarah: we would need a conversation to see how CDS could best fit in to our process

  • We do not have funding to host and maintain the tool

  • CDS could fit in as an option under Tool Component 0

  • We ran our tool against CurbIQ as a way to compare it

  • Sample worksheet in Canada leveraged this comparison

  • We want to have this process be able to be leveraged in case some of the data formats go away

  • Question from Danielle: much of our actual decisions, realistically, are more coarse/broad. We would actually allocate an entire block to one use, because logistically that is all that is possible. How would the tool work to recommended uses to be allocated at this scale?

  • Response from Sarah: you can run the tool at a larger scale, so it’s not a block-by-block analysis per se. Vancouver example – a corridor-scale level, which may be more realistic. If you are really looking more at just analysis of current events, then you can stop it without having finished all steps

  • Question from Matt Davis, Populus: does this incorporate any other data rather than agency sourced curb usage data? For example, would it incorporate vehicle movement data on the street?

  • Response from Sarah: no, it would be primarily focused on agency-provided data

  • Matt: how would the tool make decisions? Is there a training set of data? Given street geometry, this would be an optimal set of policies? For example, you entered bike ridership data, so therefore you should consider a bike lane, etc.

  • Sarah: It would not recommend parking/storage if you don’t provide relevant vehicle parking data

  • Question from Brian (Seattle DOT): So the policy recommendations, how are they inputted? Through a table?

  • Response from Sarah – so the tool would have generate Curbside Inventory Report + Practitioner Guide. This analysis is not customizable based on agency policies/objectives

  • Question from Kenya (SFMTA): so you don’t have the ability to customize if possible based on available agency policies? You mentioned that this is built for ArcGIS, is there any talk about a fork to qGIS or other open-source spatial tools?

  • Response from Sarah – unfortunately, we do not have funding to integrate with other tools beyond what was done in this project. We hope to upgrade it in the future to be able to integrate it with this evolving field, one of the reasons we are keeping tabs on the evolution of CDS

CDS Events API Discussion

  • Primary Speaker/Facilitator: Harris Lumus, Automotus, Co-Founder/CTO
  • (Harris introduces himself and the focus of Automotus: Curb management company that uses computer vision to monitor/operate the curb)
  • We want to focus today’s discussion on five open questions:

Question 1: What sort of Vehicle IDs be sent?

  • License plate number?

  • Unique UUID provided by operators, like MDS?

  • VINs (not likely)?

  • City parking registration number? Could be an ID that is agreed upon by city and operator during permitting.

  • Per the discussions, it seems the working group is leaning toward:

  • A required UUID, if the data comes directly from a commercial curb user

  • An optional vehicle identifier, painted on the side of the physical vehicle

  • No VIN or license plate number

Vehicle_id – currently in the spec – what about this?

  • Michael – what about this?

  • Harris – this is going to have to be optional, because certain data sources (e.g. puck sensor) won’t be able to identify a specific vehicle ID

  • Beyond that, we need to be able to accommodate the broadest variety of event sources

  • For privacy reasons, we don’t want to expose license plate information – we are in agreement with the broader group there

  • Some form of hashed value/derivable from license plate would be ideal

  • To capture license plate information, then use that to encode that a specific vehicle ID

  • That would be the ideal situation from our end

  • That being said, that would also allow vehicle to sensor communication

  • The operator could generate this data; what sorts of protocol could be used?

  • We don’t have any specific opinion about the types of protocol to be used

  • Michael – hash+salt on a specific license plate number, which could be recreated

  • This is meant to be a private feed of course

  • Maybe this maintains the privacy problem – if you knew a license plate number, you could potential scan the database if you utilize the same

  • Jascha – would the UUID actually be required?

  • Less privacy issues in a commercial fleet

  • Instead, I would think there would be a lot of views about commercial sensitivity – being able to identify the route of vehicles

  • A UUID that is both required and persistent would open up other potential roadblocks for fleets to share data

  • As another option, UUIDs could not be persistent, and could be rotated

  • Could be back reference-able for audit purposes; vehicle identifier could be linked

  • The other way is to have it optional by default, and have cities then negotiate with fleets on ways to make it required if needed

  • Sarah – maybe it might be good to make this a pilot for commercial vehicles: You run into privacy issues with personal vehicles, and I can understand why it might be an issue with app-based delivery services.

  • Michael – we envision this as a commercial fleet requirement, would choose to send it

  • Sarah – the companies may not want to share it, because they don’t want the violation to be known as a behavior, they don’t want a tool like this to learn that behavior over time

  • Michael (OMF): envisioning how this might work in the real world

  • In order to access the curb, it may be a required element for companies to share

  • But if the field is just optional, then no companies may want to share

  • Brian: to jump in, maybe tangentially. If it is a commercial load zone, we would want to track it in the Event data, to make sure that the vehicle has a proper tag to access the space

  • Henry Espinosa – for companies, we sometimes sell electronic permits to park on the curb

  • Whatever decision is made, it doesn’t preclude us from doing this

  • Michael: Each individual city and the relevant operators, it would be up to them

  • Kenya (SFMTA): Some of the commercial operators use private cars (like couriers), in that situation we would definitely have privacy concerns

  • That has definitely been an issue, especially if there is a specific city privacy ordinance that regulates how much data we can collect

  • We would be careful about how this API might propagate certain expectations/standards for Doordash or Grubhub, etc.

  • The second option – we can still get this from a sensor, if it is setup to do that, that may still happen

  • Do you still need a way to get back to the individual vehicle?

  • For example, do you need a to know a specific FedEx truck or UPS truck pulled up here?

  • You might still have the ability to track effective usage, but it might limit the ability to audit after the fact

  • Sarah (ITE): carsharing (e.g. Zipcar) might be an interesting use case, with limited markings – would computer vision sensors be able to accurately ID them?

  • Harris: just to understand, if there is no trade dress on the vehicle, then we would need some kind of communication with the operator itself, like a list of license plates on the service, etc.

  • Michael: yes, that would be a solution. It would be a combination of sensor and a vehicle owner passing information through an API

  • Elias (San Jose): would it be just a matter of opting in/opting out of this requirement?

  • Should it be a matter of opting in, if you want to use this curb for the specified use of commercial usage, then the fleet would need to opt in

  • Michael – according to Jascha, then this might be potentially be required

  • Constant or rotating ID?

  • If it is a matter a matter of privacy

  • Couldn’t you effectively replicate this with Automotus?

  • Jascha: do we want CDS to be that vehicle through which that information is conveyed?

  • We want to create a mechanism to facilitate data sharing in case that is needed

  • Could be used to facilitate single-location billing transaction that exposes selectively, without the ability to track over time

  • But we should have a wide range of flexibility: I don’t want to add a bunch of requirements that mandate the maximal use case – in many use cases, that won’t be required, and it moreover creates an obstacle for mutually agreed data sharing

  • Michael: why do you need any vehicle ID?

  • Jascha: there are some use cases where you do need to identify, e.g. zero-emission delivery zones, where you need pre-registration to access certain areas, you would need to validate

  • But not every city, not every circumstance

  • CDS should be flexible, to choose to use it when there is a legitimate policy purpose, but not mandate it where it is not needed

  • Michael: you could then go back to the company to audit a specific event

  • Jascha: there might be a need for a flexible ID field, the city could establish a linkage between CDS data and other information about the vehicle, they could decide how they link it together and mandate it if needed

  • Anil Merchant (Automotus): do people envision a real-time enforcement use case?

  • Michael: if you don’t have a specific ID, that would limit that possibility

  • Jascha – some cities might use a UUID

  • Provide people a field to put one in

  • Enumerate a license plate, it could be flexible ID, etc.

  • it could be a permit number issued by the city, and then given back to the city when requested

Question 2 – which vehicle properties are essential to know about?

  • Harris – length, class of vehicle, type of vehicle (e.g. freight/pickup truck), propulsion of the powertrain - What do we need?

  • Michael (OMF): how flexible do we make this?

  • Is it more controlled, with specific drop-down boxes?

  • Out of those, which of these properties do we need?

  • Harris (Automotus):this would depend again on the data source

  • Any kind of operator would directly report data. But a billing fee, sensor – may not have this data

  • In terms of requiring attributes, we would need to be flexible

  • Conditional depending on the capabilities of the event data source

  • Right now, it is an array, with the ability to contribute the data that might be required

Action Items

  • Michael – each of these remaining questions is a specific discussion item on Github. Leave your feedback there.
  • Are Provider IDs universal?
  • Status endpoint in addition to Events?
  • Per discussions, it seems like Status would be good to get the status of sensors
  • What sorts of Events Types and States should be tracked for vehicles?
  • For next steps, we will try to synthesize things and move forward, keep leaving comments on the Github discussions

CDS logo

CDS Links

1.0.0 Release

Clone this wiki locally