Policy: add "rates" (fees + subsidies)

[quicklywilliam]

Context for this PR

Many policies that govern mobility programs are related to fees. These fees can be simple or complex, including geographic or time-based restrictions. Note that we distinguish fees from fines, which are punitive in nature and are not addressed with this proposal.

While most cities are using MDS data to assess fees, the fees themselves are not currently represented in MDS. Policy enables agencies to communicate policy rules to providers and update those rules over time, but it does not yet provide a way to describe fees. This proposal adds the ability to fully represent real-world agency fees in the policy API. It supports three types of fees based on the fee's recurrence:

• Fees charged once per event. For example, per-trip "Street Use fees" are charged for each trip. Cities using these types of fees include Austin, Hoboken, Oakland, Portland and others.
• Fees charged once for each_time_unit. For example, "Right of Way fees" that are charged once for each day a vehicle is deployed. Cities using these types of fees include Portland and Santa Monica.
• Fees that are charged per_complete_time_unit. For example, "Metered fees" that are charged for each hour a vehicle is parked. One city using this type of fee for micromobility is Charlotte. These types of fees may be more common for moped, car-sharing etc.

Lastly, this proposal generalizes from describing fees to describing rates- which includes fees but also subsidies. As micromobility evolves, particularly under COVID, subsidies are a growing area of discussion and are addressed in this proposal simply by allowing the rate_amount to be a negative.

Is this a breaking change

No.

Impacted Spec

Which spec(s) will this pull request impact?
policy

[CLAassistant]

All committers have signed the CLA.

[quicklywilliam]

This pull request addresses #472

[Retzoh]

@mike-mcdonald, Charles Noling, @karcass please add comments about your use-cases, concerns and remarks.

[mike-mcdonald]

Need for fees in MDS

👍

We (Portland Bureau of Transportation) currently charge shared electric scooter operators a daily fee for parking in different areas of the city to provide some relative incentive for not placing all shared electric scooters in what is essentially our downtown area. That use case is fully addresed by this pull request. As a larger variety of vehicles use MDS, we want to express our parking regulations and policies such as parking meter zones and other curb regulations. The policy API and this pull request seem to be able to express those regulations to a high degree.

Creating parking garage functionality

My comment in the city services working group call last week (April 30, 2020) discussed creating more complex pricing structures than what is documented here. Thinking over what I want to express some more, I think what I was trying to say amounts to expressing parking garages, at least a concept of them, and their fee structures within the policy API. The current rates for SmartPark garages in Portland don't fall neatly within the examples here, although they are close. Going further, I think that our curb space could be analagous to a parking garage for scooters, where some curbs are preferred and follow a different fee structure than other less preferred curbs, and having a way to express more complex fee structures may be a way to promote good behaviors, especially when used to subsidise or waive parking in preferred areas.

[schnuerle]

@mike-mcdonald It would be great to have this PR address your use cases for the 1.0.0 release if the changes are minor. Or at least the next release. Can you explain more what it would take to align the proposal to your needs? Would you use it in its current form?

[mike-mcdonald]

@schnuerle For most if not all of our current usage fees for e-scooters, we can use this addition.

[schnuerle]

Some discussion on the call today about this. Agreed it's useful and close to being ready as is.

Discussed the possibility of flagging this as a beta feature, or adding a sentence to clarify that an agreement on usage of rates should happen between cities and providers prior to using and relying on it.

We will discuss at our next Provider WG call. Edit: Next City Services WG call.

[schnuerle]

Final discussion on this is during this week's City Services call.

@quicklywilliam Can you add some language to clarify that an agreement on usage of rates should happen between cities and providers prior to them using and relying on it?

Also can you flag this as a beta feature, and link to that description with "Beta feature: Yes (as of 1.0.0)". See the vehicles endpoint for an example.

You may also want to pull the latest 'dev' branch to your repo to resolve any conflicts.

[jfh01]

Suggested change

| `rate` | **[Beta feature](/general-information.md#beta-features):** Yes (as of 1.0.0). Fees or subsidies based on regions and time spent in one or more vehicle-states. Rule `rate_amount` refers to the rate charged according to the [Rate Recurrence](#rate_recurrence). Agencies and Providers must agree on terms of use prior to utilizing the `rate` rule type. |

| `rate` | **[Beta feature](/general-information.md#beta-features):** Yes (as of 1.0.0). Fees or subsidies based on regions and time spent in one or more vehicle-states. Rule `rate_amount` refers to the rate charged according to the [Rate Recurrence](#rate_recurrence). As this is a beta feature, agencies are strongly advised to communicate with providers about how they intended to use the `rate` rule prior to implementation. |

[bhandzo]

I prefer the earlier language, but understand it may give providers more say than cities are willing to give. If "communicate" was changed to "consult" that makes it feel more like the needs of providers should be considered when implementing.

[jfh01]

"Consult" sounds fine to me. We'll highlight this language for the Board too when they do their review of the release.

[jfh01]

Suggested some changes to the language regarding communication between agencies and providers on the use of rates here:

https://github.com/openmobilityfoundation/mobility-data-specification/pull/484/files#r445699437

Would love to get input from cities and providers on the specific verbiage.

@mike-mcdonald @bhandzo @dirkdk

[schnuerle]

@quicklywilliam Can you rebase your branch against the OMF dev branch since we've pushed a lot of changes this week for 1.0.0 and there are now conflicts? If you can do this by Monday that would be ideal since that's the day we are making the release candidate for approval.

[schnuerle]

Ready for 1.0.0 release candidate. We can highlight the communicate/consult language questions during the review process.