Web Conference 2021.07.27 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
- Welcome and process (5 min) - Michael Schnuerle, OMF
- Regulation/Event/Metrics spec recap (5 min) - Michael Schnuerle, OMF
- CDS Regulations API Discussion (40 min) - Review first draft of Regulations API
- It includes regulations, location reference, curb zones, curb areas, and curb spaces.
- This will be a more technical meeting, so bring your tech/product people into the room for discussions.
- Other CDS APIs (Events, Metrics) will be reviewed in future meetings.
- draft document
Organizers
- Hosts: Brian Hamlin, Jacob Baskin, OMF
- Note Taker: Brian Hamlin, OMF
- Facilitator: Angela Giacchetti, OMF
- Outreach: Michael Schnuerle, OMF
Minutes
- 42 Attendees
- Recording and chat log - Passcode: !=xr.&x1
- Main Presentation Slide Deck
Notes
Action Items
- Provide targeted feedback on the 6 discussions topics outlined on GitHub
- Look into creating a separate policy endpoint
Michael Schnuerle (OMF) led a recap on the Curb, Events, and Metrics APIs
- Curb API has been changed from Regulations API to Curb API. There is a lot more than regulations
- Lots of open questions in the Event and Metrics API on the shared Google doc. Please provide comments there if you can Michael Schnuerle (OMF) and Jacob Baskin (COORD) led discussion on CDS Curb API Review
- Jacob has synthesized COORD, CurbLR, and other available sources to create the basis for the Curb API
- Different geometric areas each with their own endpoint. Each will be a GeoJSON
- Area (optional)
- Zone (required)
- Space (optional)
- Area
- Geometric definition
- Name
- Zone
- Regulations and LRS is included here
- Regulation objects similar to CurbLR
- User Class
- Rule
- Time Span
- Rate
- Location Reference objects
- Outlined the requirements
- Always have common regulation along entire extent
- Never span multiple blocks
- Never overlap other curb zones
- Unique ID UUID
- It should NOT be possible to legally park a single vehicle in 2 zones
- Jacob B: This is a should and not a must because sometimes you can park in 2 separate zone
- Space
- Length, width, space number, availability
- Curb API doc has plenty of open discussion questions that we would really like feedback/comments on
Discussion of Curb API
- Henry (Miami): Why cant a zone span multiple blocks?
- Jacob (COORD): Some fields wouldn’t work if it spans multiple blocks, what do you do with intersections
- Henry (Miami): What do you do when there are entire multi-block policies?
- JB(COORD): CDS is meant to be a data exchange format and not define a system architecture for how cities manage their curbs. CDS should be very easy for people to build tools to read spec and connect between cities and provides/users. Standard does not need to be the same between cities. Agnostic to how to build it.
- Jacob (Curb IQ): Give regulations a unique ID
- Jacob (COORD): As a consumer you might not need this implementation detail
- We might be open to changing the spec if there is enough interest but it was not the use case we were building for.
- Jacob (COORD): As a consumer you might not need this implementation detail
- MS (OMF): Built for cities to share out publically and users where the curbspace is and regulations at space. Not meant for cities to store data in this format internally
- Eric (Lacuna): Likes the idea of a separate policy endpoint. Policies will change frequently and geographies will be rarely.
- Jacob (COORD): Geometry lives with the regulated area in some way
- MS (OMF): This is going to be a queryable API dynamic with end points
- Can pass in a bounding box. Person hosting (city) can process and send back what is relevant to that
- Better to put on data producer side. Query against the database. Puts pressure on the hosting entity. MDS has a policy flat file that might not work for CDS
- Jacob (Curb IQ): Common policy ID would make it easier for cities to update the data on their end.
- JB (COORD): Let’s try to have regulations as curb policy object with ID that is queryable by ID, Zone ID, policy ID
- Should be inlined with zones (option to turn off)
- JB (COORD): Let’s try to have regulations as curb policy object with ID that is queryable by ID, Zone ID, policy ID
- MS (OMF): Somethings might be added in the future
- Manzel (SFMTA): Just add an additional field to the current model would be sufficient. We would like to be able to pull up an entire parade route or street cleaning as an example
- JM (CurbIQ): Overlapping curb zones and common regulation. Paid parking/no stopping during rush hour/loading zone
- JB (COORD): Some curb zones will be very very small, it could be smaller than a vehicle. There will be oodles and oodles of curb zones
- JM (CurbIQ): Every space could technically be it’s own zone if demarcated
- Jean (Populus): Uncomfortable of having the spec be a closed ecosystem. If working to help cities. Need to take a stronger stance on how this incorporates with their workflow
- MS (OMF): During discovery phase, this is not part of the initial thought
- How cities store is not in scope, it’s just how we publish
- Pretty sure we cut out internal storage, did not want to define everything (parking etc) Commercial use is much smaller
- JB (COORD): The spec will play well with how cities store their data
- Really trying to make spec compatible with a wide variety of how cities store data in the real world. Curb zone meta data fields. It will not be hard to convert
- Danielle (Minn): Very sophisticated asset management software that many cities are using already and are following local/state laws. CDS will be the interface with how we externally communicate
- MS: There is a way to reference these things but it is separate
- MS (OMF): During discovery phase, this is not part of the initial thought
- Angel Diaz: For the curb we just need to be flexible. Some blocks may be space specific or some blocks will be face specific.
- Akshay (Philly): Concern of operations side. Talks with local operators (including UPS), wide variety of people using the curb. How will this be applied to diversity of systems?
- MS (OMF): Cities publish out, events can send data back to cities, or sensors. Events endpoint would be optional unless there is a specific pilot. Choice to city if they want to use or not.
- Akshay (Philly): Wants a standard way for how they engage with UPS. Standard way to interface. Is willing to share document
- JFH (OMF): One of the big things that is undefined, question on translation layer, how will it exist? Complex regulatory scheme to an individual layer.
- Add a section that explicitly says how we expect data to be created and consumed. Big companies, small user. Technology platform will likely be required. Give people a chance to challenge that assumption if this doesn’t work.
- Akshay (Philly): That would make a lot of sense for someone like UPS, they need to know what the cities role is and what their role is
- MS (OMF): Special doc for roles of the specific entities
- Will be complex for everybody
- Add a section that explicitly says how we expect data to be created and consumed. Big companies, small user. Technology platform will likely be required. Give people a chance to challenge that assumption if this doesn’t work.
- JFH (OMF): Can me move some to GitHub discussion?
- Might create a discussion for bigger comments?
- Keep the google doc cleaner by moving longer threads to GitHib discussion