Force accuracy for region enter where the location±accuracy is still not inside the region #841
Comments
|
Another example which I ran into earlier:
Distance from center, according to Core Location's distance math: |
zacwest
added a commit
that referenced
this issue
Aug 20, 2020
- Fires `ios.zone_entered` and `ios.zone_exited` directly from monitored regions. This will include keys `"zone" = zone.xyz"` and sometimes `"multi_region_zone_id" = "180"` when the zone (<100m at the time of writing this) require multiple regions. Refs #924 which asked for this. - Fixes passive beacon zones being sent up as definite zones, rather than GPS producers. I'm not sure when this regressed, this behavior looks the same to my eye to before it was reported broken, but it's an easy fix. Fixes #924. - Fixes cases where a region monitoring enter event might not produce an in-region location update when the accuracy and position do not show the current location as being in the region. When this occurs, we fudge the accuracy to be larger than given such that the GPS location is inside the region. Fixes #841.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example, from a user's logs:
104.880609681798754.880609681798754.864775783559363100.0158338980.015833898What we should send is
max(4.864775783559363, 4.864775783559363 + 0.015833898)or4.880609682, probably rounded up. The active zone check on the core side of things uses accuracy when deciding whether the user is in a zone, and fibbing the accuracy a bit feels a lot better than the location.The text was updated successfully, but these errors were encountered: