Activity positive / negative values

[zanebclark]

In our internal implementation of CDS, we're implementing an additional Rule field: activity_allowed and pruning the negative activities (no parking, no loading, and no stopping) from our Activity enumeration. We will still be CDS compliant, appending no to the published activity when activity_allowed is False. This allows us to understand when an activity is negative without parsing a string (e.g. does the activity start w/ no ). It also assumes that every activity can have a negative value. I think that's a valid assumption, but I'm open to being wrong.

[schnuerle]

So activity_allowed is a boolean? And you only use the activities without a 'no' in front of them?

So to say yes to parking but no loading, you would make one rule be activity_allowed = true and activity is parking and a second rule where activity_allowed = false and activity is loading?

Does this account for this line in the spec: 'The reason we have "positive" and "negative" versions of the same activities (like loading and no parking) is due to priorities: a loading rule that is higher priority than a no loading rule, for instance, implies that the Curb Zone does allow loading at the time in question, while a no parking rule would not. If "negative", rate array should be empty.' ?

[zanebclark]

So activity_allowed is a boolean? And you only use the activities without a 'no' in front of them?

That's right

So to say yes to parking but no loading, you would make one rule be activity_allowed = true and activity is parking and a second rule where activity_allowed = false and activity is loading?

Right again!

Does this account for this line in the spec

I think representing a "negative" activity as no stopping is logically the same as representing it as activity: stopping, activity_allowed: false. The no stopping representation is better for my eyes, but it requires me to interrogate a string for a boolean. Internally, we'll be storing the boolean separately. We can serve up the concatenated form (e.g. no stopping) to api users. In fact, we likely should. The no stopping form is very understandable.

[zanebclark]

@schnuerle, if there's a way to close this discussion, feel free to do so. I like the readability of no stopping on a public API

[schnuerle]

I removed the "feedback needed" label which is how we are handling active discussions for now. Thanks!

[jiffyclub]

Good call out about potentially having to do string parsing to figure out the direction of a policy, that's definitely quirky (but doable).