Policy.default_priority

[zanebclark]

Policy.priority applies to the entire city. This precludes the reversal of policy prioritization for a specific curb zone or curb zones. (I didn't realize this before the 2/22 meeting. Thanks for the heads up, @schnuerle)

Partially due to my misunderstanding, we're implementing this a bit differently at Automotus. We've introduced Policy.default_priority. On our policy/curb zone join table, there's a nullable priority designation that can be used to apply a priority other than the default priority for a given policy/curb zone combo. This might cause some wrinkles w/ CDS, as querying two different curb_zones with the same policy might return two different policy.priority values.

A proposal: Refactor Policy.priority to default_priority in CDS and expose an optional Policy.priority that reflects the priority of the specific curb zone / policy relationship.

[schnuerle]

Maybe this could be added in 1.0. Could you explain a bit more how your proposal could work? If both priority and default_priority fields are at the Policy level city wide, how does that help?

[zanebclark]

🤔 This gets tricky, as the curb_policy_ids field will just return an array of ids. If you were to investigate these policies by calling the policies endpoint, the context of the specific curb_zone would be lost. On the policy object, you could instead include a map of priority_overrides.

{
  "policies": [
    {
      "curb_policy_id": "51f58575-1042-4254-b5fc-fed97124a6c7",
      "default_priority": 2,
      "priority_overrides": {
        "7d8a5885-e949-4ac9-afb7-fa4d43b68530": 1
      }
    },
    {
      "curb_policy_id": "8c0abb35-b8d2-469e-bdb1-b6de52c430ac",
      "default_priority": 1,
      "priority_overrides": {
        "7d8a5885-e949-4ac9-afb7-fa4d43b68530": 2
      }
    }
  ]
}