curb-data-specification
curb-data-specification copied to clipboard
openmobilityfoundation
Establish between 1-3 Standardized Naming Schemas for Zone Names
Is your feature request related to a problem? Please describe.
The current Name field is optional in the CDS curbs API and when "CDS" is implemented at scale, it makes it very hard to remember Zone Names when manually created, and using the UUID is next to impossible.
Describe the solution you'd like
We would like to establish a few different naming Schemas that utilize various curb zone variables in CDS to generate the name. This would include the type of Zone (Parking, No Parking, Bus, Commercial, etc.) as well as the compass direction, cross streets, etc. The idea would be that you could look at the name of the zone and understand the type of zone, and where it is located. This would help in when looking at the zones on a map as well as making it much easier to read in reporting and analytics.
We are also factoring in the zone updating, deleting and creation rules in the Curbs rules so that when number of spaces are changed or the policy is changed, the name will reflect those changes according to the update rules.
Is this a breaking change
- No, not breaking - The "Name" field is Optional, and we are simply providing this as a recommended way for cities to name curbs at scale and still make them understandable and manageable.
For which spec is this feature being requested?
Curbs
Describe alternatives you've considered
We have tried a few simple ways to name the zones but when done at scale it is next to impossible to keep them unique and understand what purpose they serve when done at scale.
I do generally agree with an 'easy-to-read' way to define Curb Zones and I think that was the original purpose of the 'name' field. I don't think this necessarily has to be completely unique, if anything this name field is to be used in conjunction with curb_zone_ID or user_zone_ID to uniquely define the zone. I also think cities have so many different ways that they currently define their curbs, it may be hard to define a universal format for this field (although we could recommend one). Some examples of how we used these fields previously just to show the range of how these are used.
- Seattle: name = elementkey (a unqiue block identifier), userzoneID = objectID (basic GIS identifier), and then we also had some additional custom attributes to define space number, block face ID, and other info.
- Arlington: name = blockface (which can be repeated for zones on same block face), userzoneID = a unique object identifier that is an integer.
- LA: many of the curb zones created did not have existing data to reference. However, a similar process is being done for paid parking areas and parking meters as Curb Objects. We used name = unique spaceID and description = concatenated list of BlockFace, MeterType, RateType, RateRange, MeteredTimeLimit.
A potential solution - similar to Curb Objects, we add a "description" field for Curb Zones which would be "A more detailed description of the zone if needed."
Yes I agree it would be a heavy lift to create a naming convention that would work in all cities globally and work for all curb zone use cases/locations.
Like @jacobmalleau suggests, maybe a description field which can describe this in free form text.
And/or a unique_identifier field that can be used as cities see fit. Something that is unique to the zone, no spaces, and can be more useful and identifiable for cities than just a random UUID. MDS has this with vehicle_id field in the Vehicles object, as a 'String' with a description of "A unique vehicle identifier (visible code, license plate, etc)...".
We will be talking about this Issue and Pull Request to review specific change proposals in the Working Group meeting tomorrow. Thanks!
In an attempt to keep our eyes from bleeding and having to repeat UUID's when on calls discussing CDS zones or Assets, we are proposing our first version of a naming convention that utilizes data from the CURBS API Elements. Nothing in the API is being changed. This is just a quality-of-life idea for naming zones.
CDS Naming Standard Proposal 1
Schema: "STREET_BLOCK_DIRECTION_TYPE(s)"
Example: Main St_100_N_[PP][CLZ][NP]
Main St — street name. 100 — block (could represent a block or zone number). N — direction (North). CVLZ — zone type (Commercial Vehicle Loading Zone).
Examples of Zone Types used in the zone (TYPE) (In order of use through out the day)
CLZ — Commercial Vehicle Loading Zone. RZ — Residential Zone. PP — Paid Parking. NP — No Parking. PL — Passenger Loading. BS — Bus Stop.
Looking forward to hearing everyone's thoughts on this ;)
@rneubauer I think your proposal here for a unique_identifier field can work fine for you and your cities. I think each city can define how they want to do this, as opposed to having to come up with a global unique naming convention in the spec.
@mplsmitch make sure to add unique_identifier to the PR today.
We have been doing quite a bit of work on this in conjunction with the zone coloring issue #168 and have come up with this approach to a naming schema. It also happens to solve another issue with regards to gridding events in travel lanes by providing the address of an event in later versions.
We have met with multiple cities on this and the consensus is the same: They want a simple approach to naming zones that provides them with minimal, but enough information about the zone to understand what they are looking at.
We have come up with this:
Example 1: Reverse Geocoded: 350 S 1st St Policy: Paid Parking (PP) - derived form the color and abbreviation mapping done in ticket #168 Zone Name: 350 S 1st St - PP
Example 2: Reverse Geocoded: 455 N Clark St Policy: Commercial Loading Zone (CLZ) Zone Name: 455 N Clark St - CLZ
Example 3: Reverse Geocoded: 110 E San Fernando St. Policy 1: 9a-5p Paid Parking (PP) Policy 2: 5p-10p No Parking - Tow Away (NPTZ) Zone Name: 110 E San Fernando St PP-NPTZ
- We calculate the lat/long of the center of a zone.
- We use the US Census Bureau Tiger GIS: https://geocoding.geo.census.gov/geocoder/ - to generate the Street address. This provides us with an address that can be used in Google maps, Bing, and any other mapping system and it will take you right to the center of the zone. It also tells you which side of the road it is on by its odd/even number.
- The Address then allows us to know EXACTLY where a zone is located on the street.
NEEDS: we need to add a StreetNum Attribute to Zone Object which is the street number so it can be generated and included as part of the zone data.
From our Curb Working Group meeting today:
-
Need to add a new
street_numberfield to Zones to better reflect location of zone in street grid - String - could be a single number (112) or a range (112-116). -
Examples of name shown will be added to the existing
namefield in Zones -
Geocoding is up to the CDS Curbs creator (city/vendor) comes from their own process/system
-
Canada 'civic number' start/center/end for example, means address - note in description any variations
-
Action: Umojo create new PR to add street_number to Zones. Maybe address_number is a better term to align with Canada too, and make sure description is clear.
As part of #192, created this commit, with new address_number, description fields, and name examples.