Optimize for unreliable Location Services at frequent locations

Arc App Support
1

Hi,

I moved to a new city last year and find out the Location Services is extremely inaccurate at my home location. I’m talking about more than 100 meters off regularly with occasional KILOMETERS OFF. The worst part is when location is “stable” it always have an offset of 10 meters from actual location.

My Android phone can give more accurate location, which likely because Google has much better algorithms for the nearby WiFi based positioning.

This issue resulting Arc will record that I leave home for a walk 5-10 times a day but I’m actually at home entire day. I have to spend many time cleaning up hundreds of small segments each day!

I understand this is not an issue of the app itself, but could there be an option to deal with this situation? What I can think about is allow fixing a frequent location with a center and radius, once user or model assigns a sample or segment to it, if it’s out of radius mark as bogus.

I believe many people living in big cities have this problem to some extent, so I really hope there’s a solution.

1 Like
2

Hi again @extrawdw!

It could also be that your Android phone has better GPS/GNSS hardware, depending on model of Android phone and iPhone. Newer iPhones and Android phones often have dual frequency GNSS hardware, which does a lot to improve these kinds of situations, and that’s typically the biggest differentiator in location data quality, at least in recent years.

This is often a sign of single frequency GPS - building shadows. This is an almost universal problem in built up city areas! The signals are reflected, or line of sight to satellites on a consistent side of the sky are blocked, and the location is consistently offset. Dual band GPS hardware goes a long way to fixing that.

I’m not sure which iPhone model first introduced dual band, nor which Android phones have it either. But it’s definitely something worth checking, because the messy data can be quite an annoyance, as I’m sure you’re already well aware :joy:

Anyway, leaving aside the technicals of what can cause this kind of problem, let’s look at solutions!

Arc’s built in workarounds for are 1) the “bogus” activity type, and 2) the Trust Factor system.

When there’s location data that’s more than let’s say 100 metres from the real location, your best bet is to split those segments out using the segment splitting view, and mark those portions as “bogus”. That will train the classifier to recognise location data in those areas with those patterns as being bogus automatically. That then stops those samples from being included in various calculations, and also assists the timeline processing engine in keeping the timeline more clean and sensible.

When the location data is drifty but within about 100 metres of the correct location, explicitly mark it as “stationary”. That then trains the classifiers to recognise drifting data in that area as stationary rather than a moving type, but also trains the Trust Factor system to recognise moving location data as untrustworthy in that area. The Trust Factor system then adjusts the reported accuracy of the data.

For example if the phone is reporting “this location data is accurate to within 30 metres”, but Trust Factor now knows that location data around there drifts all over the place, it’ll change that value to be let’s say 130 metres. So now all the algorithms treat that “30 metres accuracy” to instead be “130 metres accuracy” - much lower trust. That then allows the moving/stationary state detection to do a much better job, and the filtering algorithms to know to more aggressively filter it for nonsense.

The combination of those two systems can often result in this problem going away, or at least the problem significantly reduced.

Oh for the 100 metres threshold as to whether to use bogus or stationary, that’s more of a rule of thumb. In practice I tend to use geographic boundaries. Like, if the samples are completely past the other side of the road, then I think “nah, that’s shit, I’m gonna mark it bogus”. So in that case I use the wide road outside my hotel as the boundary. I basically play it by ear, deciding a case by case threshold for which samples are “close enough” and which fall into the “nah that’s useless nonsense” basket.

Oh also, if you’re not already using the Arc Editor public betas, I recommend trying those. Arc Editor’s totally rebuilt LocoKit2 recording engine is significantly better at intelligently filtering location data. So it’d be interesting to see how much of the problem goes away simply by having a better recording engine dealing with it at the lower levels.

1 Like
3

Oh, a minor note on Arc Editor: Its LocoKit2 recording engine doesn’t yet have the Trust Factor system built in. But in practice what I’m finding is that its more intelligent Kalman filter does such a better job than the old one in old LocoKit (in old Arc Timeline app) that it still often does a better job than old Arc Timeline with its use of Trust Factor.

Though I will eventually add the Trust Factor system to LocoKit2 / Arc Editor too. That adjustment based on human feedback is still valuable, and something that automatic filtering algorithms can’t learn/know on their own.

4

Hi Matt,

Thanks for explaining the issue!

I do use an iPhone with dual band GPS (currently 17 Pro), and I do feel the huge improvement when I switched from 13 mini to 15 Pro which do have dual band GPS. I believe it is indeed the reflection issue because the GPS is always “off” to only one direction (That’s why it frustrates me a lot as my home location yellow circle will have a large offset). However “nearby WiFi SSID/BSSID based location service” definitely contributes to the inaccuracy of the location service, because when I use a device without GPS hardware like MacBook it always give that “offed” location. I believe for battery Apple does not use GPS all the time, and since the nearby network based location is crowdsourced from iPhones including old models with single frequency GPS, that could be why it is less accurate.

I’m currently marking all location samples that is more than 30 meters away as bogus, which is tedious. Should I increase that threshold? Because if I don’t mark out “the most common incorrect location that location services gives”, which is at about 30 meters away, it seem to make my yellow circle off.

I haven’t tried Arc Editor a lot, will definitely try (will having both running constantly drain battery too much? Or it is more recommenced to run it on a secondary device that I also carry during the beta?).

5

Nice! Yeah once you get a dual band device the difference is really noticeable eh. I noticed it first when I got an Apple Watch Ultra (dual band) but still had an older iPhone on single band. The Watch was getting much cleaner location data, even in built up city areas. It doesn’t fully solve the problem, but it significantly reduces the scale of it.

Yeah definitely could be a factor. Though I’d still expect Apple’s wifi hotspots database to be comprehensive enough, it will depend as you say on what locations those reporting iPhones are giving when they see the hotspots. Older phones with single band GPS will be feeding the database with more nonsense values. Though the same would be true of older Android phones feeding into Google’s database too I guess.

Samples marked as stationary will feed the Trust Factor system, while samples marked as bogus will train the classifiers to better detect bogus. Though in practice I don’t tend to think in those technical terms when I decide myself. I tend to judge it more on how I want that Visit’s data to look on the map - the aesthetics of it on a case by case basis.

If the Visit radius is too large or too offset in a way that’s visually displeasing, I get more aggressive with marking portions bogus. I really don’t think about it technically, so I’m probably not getting the best value out of those two systems :joy:

Though in terms of those two systems, the Trust Factor one is the one that does the most work in this particular “building shadow” / built up city area’s dodgy location data situation. The crux of the data problem is that the phones are providing wildly wrong location data while incorrectly reporting good accuracy (like reporting “30 metres accuracy” while providing locations that are 200 metres away from the real location - that’s a guaranteed recipe for data processing disaster).

So yeah, I guess I do keep that in mind implicitly when I’m deciding. Marking more as stationary will feed more “drifty/untrustworthy” data knowledge into the Trust Factor system. But I balance that with the desire to not include samples in the Visit that just make it look an annoying mess.

On a 17 Pro you should notice no battery difference at all I think.

For all of the Arc Family apps, when they’re in the background recording they use very little battery at all. Their high battery cost time is when they’re in the foreground, loading data into the UI, showing it on the map, updating the map, that kind of thing. All that UI work is 10 to 50 times more battery expensive than recording in the background.

So just leaving them running in the background, recording away and doing their thing, that’s very low battery impact. And running both Arc Timeline and Arc Editor should make little to no difference.

1 Like
6

I don’t know how much related is such. After many years of use I find I still need to confirm home. Such despite likely no other visits such as to neighbors or anything else close. Maybe there is bogus location data from previous visits yet such might be hard to find.

From what I recall, when viewing total visits there are multiple circles that perhaps reach out maybe a few dozen meters in each direction outside the limits of home, perhaps visits such as being outside or in driveway.

Perhaps other users may have apartments or homes with valid neighbor visits. In various cases perhaps some new AI model for such as mentioned could someday help.

7

That sounds like a separate issue. Well, possibly. But yeah, if you’re still having to confirm… oh wait, is it showing as “unconfirmed” or “uncertain”? If it’s only “unconfirmed” then that’s expected and normal.

The current unconfirmed vs uncertain flow on the Confirm List view was introduced earlier this year (I think?), with the change being that any items that haven’t been explicitly confirmed will show up in that list, even if Arc is confident in its auto assignments. The purpose there being to allow you to definitively lock in the assignment, so that Arc isn’t allowed to change it automatically later.

So yeah, it’s normal for the Home place to show up in the unconfirmed list. But it would be a problem / potential bug if it’s showing up as uncertain.

For a Home place there should be enough data that those occasional oddly sized/positioned ones shouldn’t cause certainty problems. But if your Home place really is being marked “uncertain”, then those oddly sized/positioned Visits would be a good place to start looking first, for sure.

Yeah, I’m hoping so! Really looking forward to having time to explore that stuff. With all the AI powers available now it would be silly for Arc to not be trying to make use of them. It’s a very “machine learning / artificial intelligence” kind of app, so it should be trying to make best use of all the most advanced tools available.

8

I think home mostly unconfirmed though I will observe to be sure.

Perhaps related to such, some places I do visit fairly often remain uncertain. Perhaps large retail spaces that sometimes might be multiple places or sometimes one large store with large parking lot. Sometimes it may show as one visit yet other times or places could show up with multiple visits with beta marking such as car when it is walking.

Over the years I may have marked such walking as stationary for either home or visits elsewhere. Stationary then merges to show one visit. Whether it is me or someone else, not sure what is ideal yet perhaps since a user may chose any option and perhaps cannot be expected to know and change may not be possible, maybe the app currently handles such well or could be better.

All these specifics may have been covered before or not. Perhaps some so called FAQ or online manual is perhaps worth creating? Perhaps answering each questions may still be required yet something to refer to might help.

9

Yeah Arc does need better documentation. For now the documentation is largely just me answering questions on the forum. Which isn’t the most sensible approach.

For large places like malls, that can go either way - either one big visits or lots of brief ones with walks between. And which way it goes can be influenced both by user editing patterns in the past, and also the changes in location data accuracy while inside the mall.

In some malls the location data can actually be reported as quite high accuracy. Possibly the mall has … what are they called … like mini location marker devices, that stores and telcos use to detect proximity and provide alerts when entering stores, that sort of thing. So those mini location markers (I really need to remember the name of them!) end up leading to higher reported accuracy. Oh also all the wifi hotspots inside the mall can “improve” accuracy as well.

So if the mall is one of those ones then the phone will think it’s getting quite high accuracy, and Arc will then record it as lots of brief stops (eg one for each store you stop in), with walking between.

But if it’s an older mall, perhaps fewer wifi hotspots, none of those location marker devices, then the phone will report worse location accuracy, and Arc will end up recording it as one big visit.