Relational Curb Object, Curb Zone, and Curb Policy (1-to-1 or 1-to-many)

[Mu-yi-Zhou]

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).

• I'm not sure

Impacted Spec

For which spec is this feature being requested?

• Curbs

[schnuerle]

This might be connected to what @rneubauerb is thinking about Curb Objects #123 too.

[schnuerle]

Hi @Mu-yi-Zhou, does the outcome of the discussion at the working group resolve all of this for you all? Please review the comment and new PR details here