Closed hunterowens closed 3 months ago
I think we should be careful to distinguish between policy ("We would like this behavior to happen in this area") and compliance ("Is this user currently violating the policy?" or "Did this provider's users, in aggregate, follow the policy?"). Some tools may not be appropriate for measuring or enforcing compliance with some policies, but that doesn't make the policies themselves invalid.
For example, if an agency wants to limit parking to specific corrals in a given neighborhood, they can use paint to create arbitrarily-small rectangles on the pavement, and they can use the Policy API to describe those rectangles to a high level of precision so that the providers know where they are. What they can't do is use GPS to reliably judge whether users are complying with the policy. However, the API can still be a valuable tool for communicating with providers and setting user expectations even if there's no intention to use GPS for enforcement at all.
It may be the case that the inability to enforce a given policy with GPS data means the city would be better off choosing a different policy, but that seems like a judgment call and a subject for discussion between the city and providers as opposed to something that the Policy API itself should need to worry about.
closing unless people have concern about this in practice over the last 5+ years of use.
Is your feature request related to a problem? Please describe.
Currently, the Policy API is
deterministic
, in the sense that the geographies files imply either an "inside" or "outside" the zone. For example, an errornous reading that a device was on the Santa Monica boardwalk could result in a shutdown / slowdown on Ocean Boulevard.However, GPS devices devices have some amount of uncertainity in any given read. In other portions of the spec, we use accuracy to describe the level of certainty a given operator has about a GPS measurement.
Describe the solution you'd like
Honestly, no clue. Ideas / brainstorm would be appreciated.
Is this a breaking change
Provider
oragency
For which API is this feature being requested:
policy
Describe alternatives you've considered
Continuing to use the existing framework with out account for uncertainity can cause issues.
Additional context
Add any other context or screenshots about the feature request here.