Improve description field in Policy to require more human readable details

[jyeo17]

New examples for Policy with agreed upon rule types - updated by Justin Yeo after discussion with Jean Kao

---

name: Improve description field description in Policy to require more human readable details
about: Suggest changes to MDS
title: Improve description field description in Policy to require more human readable details

---

MDS Pull Request

Thank you for your contribution! Please review our OMF contributing page to understand guidelines and policies for participation, and our Code of Conduct page.

To avoid complications and help make the Review process as smooth as possible, make sure to:

1. Target dev branch. Please ensure you are targeting dev, not main.
2. Keep the "Allow edits from maintainers" button checked to help us resolve some issues for you.
3. Be ready to resolve any merge conflicts before we approve your Pull Request.
4. Have an up to date profile, per our Github community profile guildance.

Explain pull request

Improve description field description in Policy to require more human readable details

Is this a breaking change

• No, not breaking

Impacted Spec

Which spec(s) will this pull request impact?

• policy

Additional context

Issue from #764
Decided upon in https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2022.06.23-(MDS-Working-Group)

[CLAassistant]

All committers have signed the CLA.

[schnuerle]

Thanks @jyeo17 ! Could you resolve the conflicts with policy/examples/README.md and click here to sign the CLA: https://cla-assistant.io/openmobilityfoundation/mobility-data-specification?pullRequest=786

[jyeo17]

@schnuerle thanks for going through it! I have completed them.
I am not sure who added the 3 examples at the bottom but I have left them there.

[schnuerle]

Could you write this "No Riding" policy example based on what you and @jean-populus think is best?

[S-eb]

yes we will do @schnuerle

[schnuerle]

Currently the PR has these examples defined:

1. Operating Area
2. No Riding
3. No Parking
4. Parking
5. Parking Time Limit
6. Speed Limit
7. Distribution Policies
8. Tiered Parking Fees
9. Provider Caps or Minimums

and in the planning doc we collectively listed these use cases:

1. Operating Area
2. No Riding
3. No Parking
4. Provider Caps or Minimums
5. Distribution Policies
6. Parking Time Limit
7. Speed Limits
8. Per Trip Fees
9. Vehicle Right of Way Fees
10. Metered Parking Fees
11. Required Parking
12. Preferred Parking
13. Tiered Parking Fees
14. Tiered Parking Fees Total
15. Pick-up and Drop-off Fees
16. Emergency Guidance
17. Publish Event Areas
18. Periodic maintenance enforcement
19. Required parking centroid
20. Registration fee

Which leaves these use cases not yet addressed.

1. Per Trip Fees
2. Vehicle Right of Way Fees
3. Metered Parking Fees
4. Tiered Parking Fees Total
5. Pick-up and Drop-off Fees
6. Emergency Guidance
7. Publish Event Areas
8. Periodic maintenance enforcement
9. Required parking centroid
10. Registration fee

And these two which I don't think are covered by just 'Parking':

1. Required Parking (this might be what Parking is in the PR now)
2. Preferred Parking

Do you think you could add these now? @jyeo17 @S-eb @jean-populus

If not we could do it in a future pull request, and I'd like to capture that in issue #764 as a comment.

[S-eb]

Currently the PR has these examples defined:

1. Operating Area
2. No Riding
3. No Parking
4. Parking
5. Parking Time Limit
6. Speed Limit
7. Distribution Policies
8. Tiered Parking Fees
9. Provider Caps or Minim

@schnuerle

The decision was taken at the task force level to tackle only the policies where
1- automation brings efficiency
2- policy rules are likely to change a lot

Therefore the short list for the following policies:

Operating Area

2. No Riding
3. No Parking
4. Parking
5. Parking Time Limit
6. Speed Limit
7. Distribution Policies
8. Tiered Parking Fees
9. Provider Caps or Minim

This has been validated by the WG steering committee.

The decision was also taken to not consider fees as part of the policy taskforce.
the consensus being that fees is probably a different object that should be treated separately from policies.

Thanks

Seb

[jyeo17]

Just a note, Tiered Parking Fees was not part of the discussion and so has been removed.

We have:

1. Operating Area
2. No Riding
3. No Parking
4. Parking
5. Parking Time Limit
6. Speed Limit
7. Distribution Policies
8. Provider Caps or Minimums

[mrsimpson]

@jyeo17 as per how I understood your comment, no riding should not be restricted to the state on_trip, shouldn't it?

You can count vehicles that are on_trip to count the process of riding. This works in most cases as trip telemetry and speed isn't usually measured in real-time.

[schnuerle]

Is the"on_trip": [] state listed here needed, or should it be removed @jyeo17 @jean-populus @S-eb?

[jyeo17]

After the discussion in the working group,
I propose that we keep the definitions of the 2 main definitions of use cases that were discussed:

1. Operating area: The vehicle should stay within the areas of operation defined (Riding area).
   Reasoning: It would be the city's decision if they want to enforce such a policy or allow scooters to ride out of the city. If they allow so, no policy is required. If they want to enforce a boundary around the city, the operating area policy defines the riding area (except for no riding zones within).

2. No parking: The vehicle should not be parked in one of these defined areas in the statuses Available, Reserved and Non-operational.
   Reasoning: In the working group call there was a discussion over whether or not the word 'must' or 'should' should be used. I stand by 'should' as the user should still be able to end a trip outside of a parking bay, triggering a violation. Perhaps some cities might want to implement it so that vehicles cannot be locked unless in parking bays, but it seems like a rare decision made so far.

[schnuerle]

For each of the 8 examples, could you either 1) update the full JSON file examples that appear in this directory or 2) remove the link to the full file for each example and delete the JSON files in the directory?

cc @S-eb @jean-populus

[marie-x]

looks good to me (once @schnuerle's ask is addressed)

[jyeo17]

Done @schnuerle @marie-x @jean-populus

[schnuerle]

Merging this to dev so we can consolidate all the work from task forces and other open PRs.