Curb Architectural Decisions
As the Curb Working Group creates and refines the first draft of the Curb Data Specification (CDS), many architectural decisions are made along the way by the Working Group Steering Committee based on community discussions.
This is a point-in-time document to explain some of the key decision points and why they were made.
Separating policy details from zone definitions allows for cross-referencing objects, a more modular design, alignment with MDS, accessing only the data you need, easier bulk changes, and smaller file sizes.
- see discussion
JSON is the format of all endpoints, for maximum flexibility and alignment with MDS. Endpoints with geographic elements will contain a GeoJSON object that can be manually or programmatically extracted. A converter may be made to swap the geographic object to a higher level in a GeoJSON file and move the JSON into properties, allowing easy geographic visualizations. We will look to usage of CDS in the real world to see if there is a demand for a native GeoJSON option.
- see discussion
Dynamic endpoints will be required for this release, but more advanced and complex querying will be left out to make it easier to implement. The need for more dynamic querying, or completely static files, will be evaluated during pilots for the next release.
- see discussion
Each zone, policy, area, and space are given their own unique UUID, just like in MDS. This allows items to be easily cross referenced and UUIDs are unique, easy to generate, and widely supported.
- See discussion
Per the scope for the first release of CDS, it is designed to stand alone and not reference MDS directly. Using parts of MDS now during pilot projects could add unnecessary complexity for implementors, and MDS was too far into its 1.2 release to add feature needed for the curb. However, we are aligning where possible now and in future releases. Here is what we are considering, in order of complexity:
- Name coherence (this release) - using the same endpoints, field names and data types where possible. Eg, policy endpoint, end_date, UUIDs
- Architectural alignment (this release) - structuring the endpoints and file formats to be similar. Eg, JSON structure
- Update MDS (next release) - change MDS to match what is needed in CDS. Eg, with policy rate, geographies, etc
- Reference MDS (next release) - directly reference parts of MDS. Eg, Policy, Geography, or Jurisdiction APIs
Part of MDS 2.0 will include a re-evaluation of the Policy API, and since it will be a major release, support for CDS needs can be added at that time.
The use of centimeter units allows integer (non-decimal) values for all measurements, clearer conversion from meters or feet, and alignment with MDS design principles to use the smallest reasonable integer units possible for fields (eg, milliseconds, cents, etc).
- see discussion
...
...
