Recommended rule type for policy

[robinef]

Is your feature request related to a problem? Please describe.

We would like to implement policy API to not only restrict some behaviours but also encourage them. We have several use cases where cities want's to dynamically propose some preferred parking spots to encourage users to park in dedicated areas. Actually the policy API rule type list does not allow us to propose that.

Describe the solution you'd like

We would like to propose 2 changes in the current specification to be able to cover those new use cases :

• add a new rule type called recommended. This type is showing the city preference for certain statuses
• change statuses to provide a list of event_type_reason rather than event_type which is too generic. We believe that event_type_reason is much more detailed and mandatory of our scenario

For example, if a city wants to encourage parking zone, we can have a new policy like

{
  "policy_id": "39a653be-7180-4188-b1a6-cae33c280341",
  "name": "Recommended Dockless Zones",
  "description": "Recommended areas for dockless vehicles within the City of Los Angeles for the LADOT Dockless On-Demand Personal Mobility Program",
  "provider_ids": null,
  "start_date": 1552678594428,
  "end_date": null,
  "published_date": 1552678594428,
  "prev_policies": null,
  "rules": [{
      "name": "Recommended Dockless Zones",
      "rule_id": "8ad39dc3-005b-4348-9d61-c830c54c161b",
      "rule_type": "recommended",
      "geographies": [
        "c0591267-bb6a-4f28-a612-ff7f4a8f8b2a"
      ],
      "statuses": {
        "user_drop_off": [],
      },
      "vehicle_types": [
        "bicycle",
        "scooter"
      ],
      "maximum": 0
  }]
}

Is this a breaking change

It could be a breaking change for the statuses field. But since an event_type_reason is always attached to an event_type, there is a compatibility since it will be easy to find the parent by defining the child.

Impacted Spec

For which spec is this feature being requested?

• policy

Describe alternatives you've considered

We are not considering any other simple alternative, everything will be more complex and need a longer study.

Additional context

The current context is for the City of Zurich.

[quicklywilliam]

Thanks @robinef, this is super interesting. Could you share a bit more about how Zurich actually incentives operators to follow these recommendations?

[schnuerle]

FYI we do have an issue open for adding Stops to Policy, see #554.

Instead of replacing the rule_type field which is used to define what the rule is, maybe there could be a new optional field (called necessity or requirement or flexibility) that has values like recommended, required, optional, and testing for each rule.

states is currently a required field listing what state the vehicle is in for the rule to apply. But you are saying that statuses would better with the event_type_reason. Though in the scenario of parking, couldn't the on_trip state be used to then communicate you want a rider to park in certain stop?

I see how the event_type_reason, ie, the transition between 2 states, could be useful in rule making and is worth exploring. Though I think you would have to not only define the event_type_reason, but both the starting and ending states since some event_type_reasons are used across multiple state transitions.

I'd also like to know more about how Zurich is using these currently with operators to help come up with a solution that meets your needs.

[avatarneil]

Very interesting! Would love to dig into this more. A quick note: as of MDS 1.0.0 event_type_reason is deprecated, and instead has been replaced with more specific event_types. You can see the new event_types enumerated here.

[robinef]

Thanks a lot @quicklywilliam and @schnuerle for your positive feedback ! I find that your proposal to add an optional field necessity could totally fit with our use case.

I'm not very familiar with the on_trip state, at Vianova we are mainly connected to providers api in Europe with MDS version 0.2, 0.3, 0.4 So we are considering to use the event_type_reason from status_changes as the main source so we can match user_drop_off with the proposed policy and understand better operators compliance regarding city rules.

I forgot to mention that the first city willing to implement that use case on our side is Bruxelles (Zurich will be later) : the operators would nudge users behaviour into parking in these parking hotspots. This will be through financial incentives or fees

[tybaltspark]

@quicklywilliam - Today Bruxelles wouldn't have specific programs to incentivise operators to deploy vehicles in these zones, except trust and communication. The regulation does not allow today for specific enforcement. However, it is expected that operators use nudging to incentivise users to finish their rides in these zones.

Coming back to our discussion, I don't think rule_type should be used here, as it wouldn't fit with the design of the Policy API and the purpose of the field.

In case of drop-off zones / parking corrals where parking is recommended / enforced, one case uses the new stops proposition for the geography. One would then have to forbid parking everywhere except in these geographies. It works, but unless I'm missing something, I don't think it is a very elegant implementation (count = 0, event_type = available or unavailable for the whole map except the Stops).

Also a fair question here is whether by default we assume (as industry) that any policies coming out of the policy API are enforced. Given the little maturity of regulations / legal framework in cities, it would be difficult to assume this. Operators would need to understand which policies are enforced, and which ones are recommended (for instance guiding users behaviour) All policies would need to be tracked anyway, so potentially a recommended policy can become required (enforced legally), given the KPIs collected by the city. Do we thus assume that all policies coming out of the Policy API are enforced legally & should be communicated as such to operators?

Also, regarding the use case drop-off zones / parking corrals, a city can enforce operators (re)-deployment in these zones but not user drop-offs. I think a rule should apply to the new event_type as described in 1.0.0 https://github.com/openmobilityfoundation/mobility-data-specification/blob/release-1.0.0/general-information.md#vehicle-state-events.

@karcass also discussed using the field "Info", i believe he meant user. "Information for users, e.g. about helmet laws. Generally can't be enforced via events and telemetry." Does this mean it can't be enforced technically or legally ? Otherwise I'm struggling to understand the fit for this use case.

1/ Are policies coming out of the Policy API automatically enforced legally ? Or could there be implemented to guide behaviours before being enforced for instance ? The optional field requirement then makes sense @schnuerle . 2/ I'd like to discuss the implementation of Stops within the Policy API, specifically for dedicated dropoff zones Happy to present/discuss it in a next meeting

[schnuerle]

I will work on a PR to add an optional field called requirement or necessity for rule types.

[schnuerle]

In PR #605 I added a new rule optional field called necessity which enumerates some options for policy makers to attach to a rule:

• required (default)
• recommended
• optional

I'm not totally happy with the necessity field name, but it does seem to make some sense, describing how necessary the rule is. Other options could be requirement, enforcement, importance, etc.

Note the 3 enumerated values may require more explanation, or others could be added, like testing.

Let me know your thoughts on this and if it will address your use cases.

[quicklywilliam]

I'm concerned that we are jumping too quickly to solutions with this one. I'm concerned that "recommended" or "optional" rules have implicit meaning, and I believe that Policy should always strive to be explicit when possible. What specifically is being required, and in what sense is a rule optional or recommended?

I've heard some several use cases for recommended rules, but in each case it seems like a more explicit policy is possible.

Let's take the example of parking corrals.

1. Suppose the city installs some corrals. Initially, the City is OK with scooters parked elsewhere, and would merely like to make information about corrals available to encourage their use. In this case, the City isn't really hasn't expressed a rule at all – they are merely describing a feature of the right of way. They would do this simply by creating a list of Stops.

2. Now suppose after 3 months the city sees that corral usage is low. In fact, some providers have not even bothered to show the corrals in the app. To address this, the city might wish to express a Rule with a list of stops that requires providers to expose these stops in their app. This might work similarly to how Policy can currently be used to require helmet law notifications.

3. Another 3 months go by and the city is still getting complaints downtown. To address this, the City decides to make a 25 cent fee for parking outside corrals downtown. They do this by adding a Rule for a 25 cent parking fee downtown, and a separate Rule making a 0 cent parking fee in corrals.

In each of these three stages, corrals are in some sense optional or recommended. However, an optional or recommended field isn't needed to express this fact – and might in fact confuse the situation. In two of the cases above, there is also an explicit requirement attached.

As a next step, I'd suggest we solicit and work through further examples, applying the principle of being as explicit as possible and seeing what challenges we encounter in practice.

[marie-x]

I am aligned with @quicklywilliam on this topic

[schnuerle]

Ok so it sounds like in the examples @quicklywilliam has put forth, everything a city could do around rules from making them optional to required to incentivized can be done now with MDS. @robinef are you following this, and do you agree?

Maybe what is needed in the spec is more clarification and examples of how cities can do this. Do you all think this should be done in the spec, maybe in a new section about how to use MDS to create stages of rule, or maybe just in the examples area that can be linked to from the spec?

I do think if the enumeration values are clearly defined and thought out in the spec an idea like this could be good and eliminate some confusion (though potentially creating new confusion if done poorly).

[quicklywilliam]

@schnuerle I could be wrong but I don't think it is currently possible to do #2 (require providers to show stops in their apps). It seems like a fairly straightforward extension of the user Rule Type though.

And yes, I agree that more examples and linking to them from the spec would be good! There are a lot of really common use cases that require you to combine multiple Policy rules in ways that are not immediately intuitive/obvious.

[robinef]

@schnuerle yes, i'm following, and it triggers a lot of discussion internally. Generally speaking I agree that having a clear list of simple use cases with attached MDS policy (with sometimes complex multi-layer) could really help everybody in the community to better understand and adopt policies. But I still believe that we need more granularity in the way cities could express their wishes/needs, especially in some context that are lacking regulatory frameworks.

[schnuerle]

See PR #605 for some conversations about this. Lots of discussions but not full consensus.

[schnuerle]

Per the final release discussions yesterday, agreed that this needs more conversations and move to next release.

• Need cities to consider legal considerations of requiring all policy, especially in Europe
• Need cities in the discussion for use cases and how this could be implemented, especially in Europe
• Is there liability for cities by publishing Policy API and implying that everything listed is required by law?

[schnuerle]

Tagging this for 2.0 since it aligns with Policy reworking. Please leave your thoughts here if have some new ones to share one year later.

[jean-populus]

Is this still a pressing issue we want to address or is it ok to close it for now?

[schnuerle]

Moving to a future release