Just to follow up — when you mention "good coverage for regions", could you please clarify what exactly defines "good coverage"?
Region monitoring is primarily driven by WiFi location data, which has three consequences (one of which is less obvious).
-
It works pretty well when WiFi density is fairly "high". That obviously includes most urban environments, but also tends to include most residential areas (since home WiFi networks are common).
-
It doesn't work well when WiFi density is low/non-existent. There are some special cases for things like users’ "home"* but, in general, region monitoring doesn't work well in rural environments, wilderness, etc.
-
(less obvious) The nature of WiFi location data means that it can fail in weird/unexpected ways.
*There are on-device heuristics which track broad usage patterns which are then used to improve things. So, the "home location", for example, is something like "the WiFi network the device is connected to for ~8-12 hours a day, ~8+ of which are idle (because the user is asleep)". That then means the device only needs that ONE network to know the device is "home", not the more typical collection of APs that WiFi location normally uses.
Expanding on 3, this isn't a case of any particular failure pattern you can predict or account for (if it was, we'd have already done that), but simply that the AP tracking WiFi location relies on opens the door to "odd" behavior. Two examples (note both of these were many years ago and don't necessarily represent what would happen today):
-
A developer once managed to drive 3+ hours while CoreLocation returned the device as stationary the entire time. After a lot of discussion, we eventually figured out that he'd placed his phone in a bag behind and under the seat of his car (blocking both GPS and cellular access) but directly underneath a personal hotspot he'd been using at home for a "long" time. As best we could determine, the hotspot had been registered at a location (his home) and that lack of any other data source meant that it was treated as "the truth"... so he never moved.
-
A more real-world case is that I've weird region monitoring issues in places that maintain large-scale WiFi networks, particularly "mid-sized" business campuses or small businesses with multiple locations. What happens is that the WiFi network is set up, the access point location gets registered, and then the access points get shifted around without being fully reset or otherwise modified. This is particularly true on larger "campuses", where the physical space can be big enough that ALL of the APs are owned/managed by the same organizations, so there aren't any "external" APs which would hint that the configuration had changed.
Note that there are systems in place so that #2 will self-correct but that process can take a while, particularly if other factors (poor cellular connectivity, bad GPS data, etc.) complicate that process.
Does it refer to GPS ****** strength, the presence of Wi-Fi or Bluetooth beacons, or other factors?
As I noted above, this is almost entirely about WiFi location.
However, one special note here is that iBeacons need to be understood as a completely different solution to a (superficially) similar problem. iBeacons do NOT provide "location" data and they never have- that is, CoreLocation does not derive locations from iBeacons, nor is there any mechanism for the iBeacon to say "this is my GPS position".
What iBeacons provide is PROXIMITY information ("the device is near this beacon"), NOT location ("this is where the device is on Earth"). What makes this distinction critical is that there are LOTS of use cases where "proximity" is what you actually wanted, not location. Businesses trying to detect location arrivals are generally much better off using iBeacons, as they avoid all of the complexity/risk location can introduce and you can manipulate things like beacon positioning to get exactly the user experience you want.
I’m asking because in Moscow, where these regions are located, the current conditions often lead to incorrect GPS positioning. It's a known and recurring issue: the phone can suddenly jump 20–40 kilometers away from the actual location and stay fixed at that false position for a while, even when the device hasn’t moved.
That's certainly more extreme than the common case, but one of my longstanding recommendations has always been that things like region monitoring configuration work much better when they're based on real-world testing/data, NOT "the map". That is, if you go to enough locations you'll eventually find that there are many locations where the location the device returns simply does not match what the "map" says it "should” be. Similarly, a region configured based on the location the device actually returned will generally work better than a region based on "the map".
**It would be very easy to assume that these are all bugs that the system should simply "fix" but, unfortunately, the world just isn't that simply. All three (WiFi, GPS, cellular) of the system location sources are subject to a variety of edge cases, none of which can easily be accounted for, particularly if power and time are a concern.
Despite the location being obviously incorrect, the system still triggered multiple UNLocationNotificationTriggers within seconds, even though those regions were far apart and shouldn't have been entered simultaneously.
It's hard to know exactly what caused this, but if GPS is regularly showing the kinds of swings/jumps you're describing, I can see how that could end up creating a real issue in the WiFi location. Unfortunately, I don't really see any way we could adjust/account for it either. Cellular isn't accurate enough to be useful, and using GPS would consume more power and, more importantly, wouldn't really help (as you said, the GPS data itself is the problem).
Is there a way to limit or filter this behavior?
I don't see a lot that the system could do, but you could do any/all of this by moving to the lower level CoreLocation API (instead of the notification APIs) and then posting whatever notification(s) you want.
For example:
Restricting location-based notifications to one per hour, regardless of how many regions are entered.
Adding some safeguard to prevent multiple notifications if several regions are entered in a very short time due to GPS anomalies.
Keep in mind that the problem with both of these is that:
-
We don't know which notification was "right", so the notification we discard could very well be the one the user actually needed to see.
-
While the notifications may have "appeared" to occur at the same time, that's probably not what happened at the system level. Preventing the "very short time" case actually means delaying ALL location notifications just in case the "next" one arrives (assuming you don't just drop the later ones).
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
