Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on how MDS should compute dwell time duration #711

Closed
nelsonsantryl opened this issue Oct 26, 2021 · 4 comments
Closed

Clarification on how MDS should compute dwell time duration #711

nelsonsantryl opened this issue Oct 26, 2021 · 4 comments
Labels
Policy Specific to the Policy API

Comments

@nelsonsantryl
Copy link

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

@schnuerle schnuerle added the Policy Specific to the Policy API label Oct 27, 2021
@schnuerle schnuerle added this to the 2.0.0 milestone Oct 27, 2021
@jyeo17
Copy link
Contributor

jyeo17 commented Oct 31, 2022

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

@pierre-bouffort
Copy link
Collaborator

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.

@schnuerle
Copy link
Member

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

@schnuerle schnuerle modified the milestones: 2.0.0, Future Jan 9, 2023
schnuerle added a commit that referenced this issue Mar 30, 2023
@schnuerle
Copy link
Member

If this is still relevant after the MDS 2.0 changes, please comment and we can reopen.

@schnuerle schnuerle removed this from the Future milestone May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Policy Specific to the Policy API
Projects
None yet
Development

No branches or pull requests

4 participants