mobility-data-specification icon indicating copy to clipboard operation
mobility-data-specification copied to clipboard

[Policy API] support utilization policies

Open jean-populus opened this issue 4 years ago • 6 comments

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

A few cities have policies around minimum utilization (# rides / # vehicles) but this isn't currently possible to convey using the rule_types which are: count, time, speed, rate, user. In this case we need two different counts - one for trips and one for total vehicles - and the policy is a ratio of the two counts. Cities also would like to specify a time period over which to measure - for example, is it a daily min or a 7 day average min?

Describe the solution you'd like

Is this a breaking change

  • I'm not sure

Impacted Spec

  • policy

Describe alternatives you've considered

Additional context

jean-populus avatar Jan 30 '21 01:01 jean-populus

here are some examples we found in our initial survey, some may no longer be current:

  • Austin: Minimum average of 2 trips per day, over a month
  • Santa Monica: "Minimum Utilization Rate (MUR)" is minimum average number of daily rides per device that an operator must achieve in order to maintain or increase fleet size. Utilization is calculated by dividing the sum of total daily rides within the jurisdiction over a one-week period by the total devices available daily during the same timeframe.
  • San Francisco: The SFMTA will monitor the number of trips/scooter/day for the entire Service Area, as well as subareas. Based on these observations, the SFMTA will develop a trips/scooter/day threshold. To be eligible for a fleet size expansion, permittees must demonstrate strong device usage by achieving a monthly average above this threshold, verified using the SFMTA’s Emerging Mobility Application Programming Interface. The SFMTA will use a monthly average of each day’s total number of trips divided by the operator’s total permitted fleet.
  • Tucson: Minimum Utilization Rate: Minimum average number of daily rides per device calculated by dividing the sum of total daily rides within City over a 7-day period by the total devices, excluding devices deployed in Opportunity Areas, available daily during the same timeframe. For Dynamic Capping purposes, the MUR for Electric Scooters is three (3) rides per day per device for expansion.

jean-populus avatar Feb 04 '21 21:02 jean-populus

  • Austin: 2 trips per day per vehicle? What happens if the provider falls below that threshold?
  • Santa Monica: do you have specific numbers for their minimum rate, and how exceeding that rate translates into a larger fleet size cap?
  • San Francisco: this looks like a Metrics application more than a Policy application, maybe? What idea would you try to express in Policy?
  • Tucson: Seems very similar to Austin and Santa Monica, is that accurate?

marie-x avatar Feb 05 '21 03:02 marie-x

Notes from the working group meeting discussions.

  • Even trickier since this involves two counts: trips and devices
  • Using a Metrics API could make this easier. However, some metrics may be difficult to support. What are the simplest things to be measured vs complex
  • Should we restrict Policy to rules that can be calculated via Metrics? But don’t want to replicate Metrics in policy.
  • In order of complexity: Could 1) add things into policy 2) add well established metrics 3) dynamic metrics calculations
  • Jean offered to share what Populus has been tracking policy-wise pulled from all cities

@jean-populus if you can answer the questions above, maybe @karcass can see if these scenarios are possible now in Policy with some examples?

schnuerle avatar Feb 12 '21 15:02 schnuerle

The examples were pulled from publicly available policies in 2019 so I'm not sure how accurate they still are and I don't have any further details other than what's been described.

It feels to me like we could have advanced rules where we could define a relationship between two sub-rules. For example, "set the ratio of rule1: rule2 to minimum X". This could then also work for distribution by %.

On Fri, Feb 12, 2021 at 7:25 AM Michael Schnuerle [email protected] wrote:

Notes from the working group meeting https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2021.02.04-(Joint-Working-Group) discussions.

  • Even trickier since this involves two counts: trips and devices
  • Using a Metrics API could make this easier. However, some metrics may be difficult to support. What are the simplest things to be measured vs complex
  • Should we restrict Policy to rules that can be calculated via Metrics? But don’t want to replicate Metrics in policy.
  • In order of complexity: Could 1) add things into policy 2) add well established metrics 3) dynamic metrics calculations
  • Jean offered to share what Populus has been tracking policy-wise pulled from all cities

@jean-populus https://github.com/jean-populus if you can answer the questions above, maybe @karcass https://github.com/karcass can see if these scenarios are possible now in Policy with some examples?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openmobilityfoundation/mobility-data-specification/issues/620#issuecomment-778260316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN6R4GADMGXN5J3MMG4KFUDS6VB6NANCNFSM4WZZDNZA .

jean-populus avatar Feb 12 '21 20:02 jean-populus

@avatarneil and @karcass Could you take a look at this, like you mentioned on the WG call last week? Thank you.

schnuerle avatar Apr 05 '21 18:04 schnuerle

Posting an update from presentation MDS Policy Extensions 15 July 2021

  • Until we can rigorously define “utilization” it will be difficult to have a utilization policy
  • Raises interesting possibilities for metrics-based Rules, “measure against this Metric”
  • Proposal: Move forward on Metrics-based Rules (possibly 1.2 timeframe, if not, then 2.0)
  • Question: Can we compose Metrics inside Policy, if not, how do we refer-to/recycle the Metrics definitions? Should Metrics definitions be separated from the Metrics API?

FYI I'd be in favor of deferring this for now as Utilization is not currently a part of metrics and seems like we should have a larger convo about metrics & policy.

jean-populus avatar Jul 19 '21 22:07 jean-populus