Closed nelsonsantryl closed 1 month ago
Hi @nelsonsantryl @schnuerle @jean-populus We (Blue Systems) already have a way of working with dwell times that we can propose.
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.
This will need to move to a future release unless a PR is made this week.
If this is still relevant after the MDS 2.0 changes, please comment and we can reopen.
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:
My understanding is that a scooter in the ...3b9 geography would match under the following conditions:
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).
Impacted Spec
For which spec is this feature being requested?
policy
Describe alternatives you've considered
None.
Additional context