So, every day in my timeline there are several “trips” ~5 minutes long, usually from my house to some place 50-100 meters away and back, random direction, in a straight line. These occur at random times, and always when I’m stationary. I keep cleaning them up, marking segments as bogus, but they keep happening.
Nothing like that happened with my previous iPhone 13. I’m wondering what could be the cause for these? Surely, phone being a month old now, any calibration/learning on the iOS part should’ve been completed by now? Anything I can do to stop this from happening?
Ah the annoying old drifting data problem. This is usually more associated with an iOS version than an iPhone version, but newer iPhone models have tended to reduce the problem on average.
I recommend marking the drifting segments as stationary instead of bogus, if they’re within about 100 metres or so of the real location. That way they train the “Trust Factor” system, teaching Arc’s recording engine that location data in that area tends to drift outside of the reported accuracy distance, and that Arc should put lower trust in what iOS tells it.
If you instead mark the data as bogus, the Trust Factor system can’t learn from it, because it doesn’t know whether you intended that to mean you were stationary at that time or not. It’s best to only mark data bogus if it’s drifted much more significantly from the real location, and need to remove it from the timeline completely.
You can also use the new “clean up” buttons, from the more/ellipsis menus on Visit Details view and Visit Edit view, which will automatically mark drifting segments inside the visit as either stationary or bogus, depending on how far they are away from the visit centre/radius.
As to what’s actually causing this drifting data, it’s hard to know, and likely impossible for either of us to fix. It could be something like some new wifi hotspots being added nearby, which were previously in a different location and thus have outdated location information attached in Apple’s wifi hotspot triangulation database. Or it could be due to some cell tower changes nearby, or new buildings changing the way that GPS/GNSS satellites are being blocked or exposed in line of sight. Basically a whole bunch of potential data source variations and impediments, that might be adding up to confuse the phone.
To add a little more detail on the Trust Factor system, a little background:
When iOS reports the location to an app, it provides a “horizontal accuracy” value along with that reported coordinate. For example it might be saying “here’s the device’s current location, and this given location is believed to be within 50 metres of the real location”.
Where things break down and fall apart is when that reported accuracy is overly optimistic, for example it says “this location is within 10 metres of the real location” but in reality the real location is 100 metres away. At that point Arc’s algorithms break down, because they’re essentially being lied to. A circle with radius of 10 metres around the given location will be 90 metres away from the real location! You can’t maths your way out of that.
That’s where the Trust Factor comes in. If Arc is told by the user that the device was actually stationary that whole time, even though the location data was drifting around over 100 metres (while reporting accuracy of 10 metres. grr), Arc then knows that it was lied to, and can calculate a reduced Trust Factor for incoming location data at that location.
Then next time when the device says “this is accurate to within 10 metres” Arc can think “yeah right, same as last time eh? you’re not going to fool me like that again! i’ll mark that down as 100 metres instead of 10”. Then the algorithms start to work again, and noisy data gets sensibly cleansed and smoothed out, as nature intended.
Thanks for the explanation, I can try marking them as stationary. However, I looked again more closely at it and it’s actually more like ~300 meters (500 yesterday!) Marking that as stationary is probably not great?
Yeah if it’s that far out it’s probably best to mark it bogus. Otherwise it’ll make a mess of your timeline, no doubt!
The “clean up” button will take care of deciding between stationary and bogus if it’s data inside the correct visit/place, but if it’s drifted that far it almost certainly won’t be. Which means having to do it the old tedious manual way, of marking the drifted segments as bogus.
Basically, use the “clean up” feature for data that’s inside the correct visit/place, and for anything else manually mark it either stationary or bogus depending on how far it is away from the real location, with the rule of thumb of less than about 100 metres is best to mark stationary, and more than 100 best to mark bogus. (Though I often just feel it out intuitively, based on how distant it looks on the map, which varies depending on the density of the city area, the size of the building, etc - basically just eyeballing it).
Aside: This drifting data problem got extremely bad a few years back, happening far too frequently, and often drifting over up to a kilometre or more, for sometimes hours at a time. So I raised it as an issue with Apple. It did then improve significantly in future iOS updates, but in typical Apple fashion they never replied to my bug report, so no explanation of either the cause or the corrective actions taken were provided.
Since then it’s occasionally come and gone, but usually not to anywhere near as bad a degree as it had in the first year of the bug. Sometimes there’ll be a reasonable proximal cause that can be guessed at, like an iOS update or a new phone (thus fresh iOS install), or a building with a particular combination of GPS/GNSS line of sight issues. But without clear answers from Apple we’re unfortunately just left guessing, and working around it as best we can in Arc, mostly by marking the data stationary (if appropriate) and relying on Arc’s Trust Factor system. Definitely not ideal!