Role of Public Input
Public input plays an important role in the development of the Curb Data Specification (CDS). The Open Mobility Foundation (OMF) follows an open and collaborative development process, encouraging input from public agencies, private sector service providers, technology companies, and other stakeholders. This iterative process ensures that the Curb Data Specification remains flexible, scalable, and meets the needs of all that use it.
Using GitHub as our primary platform for collaboration, OMF ensures that anyone can review the code, raise concerns, or propose changes. Anyone can participate in the discussions on GitHub, including those without a technology background. Whether you’re a city official, resident, or commercial curb user, your feedback can provide insights, highlight potential issues, and suggest improvements.
Open Issues on CDS GitHub
GitHub Issues provide an easy entryway to participation in OMF projects. Issues are a discussion forum for collaborating on changes and additions to the Curb Data Specification. Here are just a few of the Issues we’re currently discussing and looking for feedback on:
#142 Clarity Around User Classes – Disabled Parking Permits
CDS user classes are intended to represent any class of vehicle that is regulated by a city concerning curb space. Several user class values have been designated in CDS, however, there are common regulations like disabled parking which are not clearly defined. What other enhancements to CDS user classes would provide clarity and uniformity across cities?
#146 – Additional Fields for Computer Vision Data
Cities are using computer vision to detect vehicle properties that are not supported by the current specification. Computer vision systems can determine properties like make, model, and color, plus the company operating the vehicle. These data may be useful for auditing, enforcement, or other purposes.
#147 – Add Device Type to the Curbs API
Many CDS “events” can be generated by cameras or sensors, but there is no way to identify the unique device generating that event. Adding a device identifier would allow better tracking and validation of curb events from their capture to their use in CDS metrics.
#148 – Naming Schema for CDS Zones
The CDS Curbs API specifies a UUID for naming CDS Zones, but UUIDs are not human-readable, which makes it difficult to identify zones in CDS data. Could we develop a naming schema using zone properties like the regulation type, compass direction, cross street, or other known values to formalize the naming of CDS zones and make them human-readable?
#149 – Double Parking Events, Mapping Travel Lanes
CDS currently describes events happening in the curb lane. Events of concern, like double parking, happen outside the curb lane. Should the scope of CDS be expanded to model all travel lanesl to pinpoint the location of double parking events and other issues?
These are just a handful of the issues that are currently under consideration. We encourage anyone interested in better in curb management to weigh in on these and others to help us improve CDS and move the collaborative development process forward.
How the Mobility Data Specification evolves to incorporate the best Read more
If you’re thinking about making a contribution to one of Read more
Learn more about how OMF's unique open source model works Read more