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

Clarification on how MDS should compute dwell time duration

Open nelsonsantryl opened this issue 3 years ago • 3 comments

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

I’d like to clarify how MDS should compute the duration of dwell time. Given a “time-type” policy like so:

{
    "name": "Greater LA limit dwell time limit for non-op and reserved",
    "rule_id": "a7eb28b9-969e-4c52-b18c-4243a96f7143",
    "rule_type": "time",
    "rule_units": "hours",
    "geographies": [
      "12b3fcf5-22af-4b0d-a169-ac7ac903d3b9"
    ],
    "states": {
      "non_operational": [],
      "reserved": []
    },
    "vehicle_types": [
      "bicycle",
      "scooter"
    ],
    "maximum": 24
  }

My understanding is that a scooter in the ...3b9 geography would match under the following conditions:

  • 24 hours or more continuously in a non_operational state.
  • 24 hours or more continuously in a reserved state.
  • 12 hours in a reserved state, followed by 12 hours or more in a non_operational state (uninterrupted by any other state changes).

Describe the solution you'd like

I want to confirm the following (and add some wording for clarity to the spec): The timer does NOT reset if there is a state change where both states are listed in the rule, and the vehicle has not exited the geography.

Is this a breaking change

A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).

  • Possibly breaking: If users have built their compliance evaluator to restart the timer on a state change.

Impacted Spec

For which spec is this feature being requested?

  • policy

Describe alternatives you've considered

None.

Additional context

nelsonsantryl avatar Oct 26 '21 16:10 nelsonsantryl

Hi @nelsonsantryl @schnuerle @jean-populus We (Blue Systems) already have a way of working with dwell times that we can propose.

jyeo17 avatar Oct 31 '22 16:10 jyeo17

Sorry we didn't follow up on this. The way we work our way to an estimate of dwell time is through the status of the vehicles. What we are currently offering to do is to count the time spent (with the proper policy rule type therefore) that can be spent in the statuses that correspond to a device being on the public right of way, but not in motion. These statuses will typically be available, reserved and non operational. The time spent with the status on trip is of course not counted as dwell time, along with all the statuses that are not in the PROW. The unknown status is up for debate on this. So far, we have let cities decide whether or not to count it as dwell.

pierre-bouffort avatar Dec 08 '22 21:12 pierre-bouffort

This will need to move to a future release unless a PR is made this week.

schnuerle avatar Jan 02 '23 16:01 schnuerle