Is your feature request related to a problem? Please describe.
Sharing a few thoughts on relating Curb Object, Curb Zone, and Curb Policy:
1 curb object relates to 1 or many policies (SF has dual use zone with different policies by time of day indicated by sign)
1 curb object relates to 1 or more curb zones (e.g. street cleanning signs applies to all curb zones of a street block)
1 curb zone relates to 1 or more policies (meter policy and street cleanning apply to a curb zone)
1 curb zone realtes to 1 or more curb objects (a disabled parking sign and a strecth of blue curb paint at a curb zone)
1 policy relates to 1 or more curb objects (a disabled parking sign and a strecth of blue curb paint at a curb zone imply same policy)
Describe the solution you'd like
when 1-to-many relationship is allowed, will we have records of 1-to-1 relations (e.g. curb_object_id and curb_zone_id), or will we have one record of 1-to-many relationship with an array field to store a series of ids (e.g. curb_object_id and curb_zone_ids)?
Is this a breaking change
A breaking change would require consumers or implementors of an API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
Is your feature request related to a problem? Please describe.
Sharing a few thoughts on relating Curb Object, Curb Zone, and Curb Policy:
Describe the solution you'd like
when 1-to-many relationship is allowed, will we have records of 1-to-1 relations (e.g. curb_object_id and curb_zone_id), or will we have one record of 1-to-many relationship with an array field to store a series of ids (e.g. curb_object_id and curb_zone_ids)?
Is this a breaking change
A breaking change would require consumers or implementors of an API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
Impacted Spec
For which spec is this feature being requested?
Curbs