Policy Mutation Resulting From Partial Time Span Expiration(s)

[zanebclark]

A CDS Policy doesn't have an expiration date on it. An MDS Policy does. CDS instead captures the expiration of a policy on the Time Span. A Policy can have multiple Time Spans. In the case that one of two Time Spans associated with a single policy expires, the Policy will have a different impact one day than it will the next day (when one Time Span expires). Such a change to a policy should likely require a new policy_id. Some potential fixes:

1. (Preferred, matches w/ MDS) Add valid From / To to the Policy object and remove it from the Time Span object
2. (Clunky) Require that all Time Spans associated with a given Policy share the same valid From / To values.

[zanebclark]

@lummish , fyi

[jiffyclub]

It looks like curb Zones do have start_date and end_date, so it is possible to specify the valid date range for that relationship between space and policy. I'm not sure Policies themselves need date ranges of validity since one would remove a Policy from usage by making new Zones that don't reference the Policy. (This is a difference with MDS: in MDS a Policy is a relationship between rules and space, but in CDS Policies are only rules and have no relationship to space until they are included in a Zone. At least that's my understanding.)

I am confused about the from and to fields on Time Spans, though. What are those used for? I would think if one needed to change the Time Spans on a Policy they would make a new Policy, not edit an existing one.

[zanebclark]

@jiffyclub , thanks for explaining the difference in MDS / CDS definitions. That's helpful.

so it is possible to specify the valid date range for that relationship between space and policy.

I didn't realize that, though this relational expiration would need to be repeated for every space / policy relationship that the expiring policy applies to. Having the ability to define the expiration for the policy would allow for more centralized control of expirations that should apply to all space / policy combinations

I would think if one needed to change the Time Spans on a Policy they would make a new Policy, not edit an existing one.

Indeed. I don't think it would be appropriate to apply a Time Span to an existing policy

A curb_policy_id MUST NOT be reused -- once created, it must continue to refer to the identical policy forever

Adding a new Time Span would break the identical policy provision.

If you defined a new Policy with two Time Spans, one that's indefinite and one that has a to value of 12/31/2021, the impact of this policy would change on 1/1/2022 without altering this policy in any way.

[jiffyclub]

Having the ability to define the expiration for the policy would allow for more centralized control of expirations that should apply to all space / policy combinations

I see that, but I'd want to encourage the policy admin to be publishing new zones up-to-date policies in any case. But maybe there's a good use case I'm not thinking of for expiring the policies independently.

If you defined a new Policy with two Time Spans, one that's indefinite and one that has a to value of 12/31/2021, the impact of this policy would change on 1/1/2022 without altering this policy in any way.

Don't think I like that, I'd rather mandate whole new policies to account for that transition.

[schnuerle]

The to/from in Policy time span is optional for very specific policies, likely temporary ones, like a concert, or festival road closure, or special loading for an event, etc. Something you think you may only use once. My guess is most policies would not define these values. We could add some clarifying language or suggestions here if so. Tagging @jacobbaskin and others at Coord who originally added this for some clarity.

Based on the rest of the conversations here, I don't see anything else that needs changing from the way it is in the spec right now, correct? I'm agreeing with @jiffyclub's latest comments.

[brynn]

@schnuerle Yes, that's correct -- and sports events are another common example. Perhaps the to/from naming isn't specific enough though, given the confusion here? What about temp_policy_start and temp_policy_end?

[schnuerle]

I think that naming like that would help clarify its purpose.

Do we need to think about if there is a conflict between the start/end in Policy and start/end in Curbs? Eg, maybe just saying that both have to be aligned for the policy to be active?

Examples of dates over time:

Policy never active  for this curb zone
[----Policy----]
                    [----Curb----]

Policy active first part of curb date range
[----Policy----]
        [----Curb----]

Policy active last part of curb date range
          [----Policy----]
[----Curb----]

Policy active for entire curb date range
[----Policy----]
[----Curb------]

[brynn]

Yeah, I think this makes sense -- so the policy temp start time has to be <= the curb end time or the policy temp end time has to be >= the curb start time for the policy to be active

[schnuerle]

I named them start_date and end_date like we do across the rest of CDS, and added a note below the object table clarifying overlap with Curb. I think this gets at it, but let me know if anyone has changes.

https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/curbs/README.md#time-span