Bogus Data when stationary

Hi,
When i am stationary for days, App is showing wrong data like “Car” or “Bike cycle”.
I can edit individual segments, but is it something that can be fixed?
Also when moving in car it records random wrong data sometimes “Air-plane”. And when in traffic it consider car as a “bike cycle” or “walking”
Can it intelligently understand that people dont go from car to cycling or airplane for short distance and come back in car.
I can always edit individual segments though

By editing you are fixing it :wink: Arc is a learning engine, which means that every confirmation and correction you make is an act of teaching Arc’s models to better understand your activities, and thus improve its accuracy in auto detecting them next time.

There will always be a bit of noise in the segments, but the more corrections you do, the less it will happen.

For nonsense segments inside visits, correcting those to “stationary” also trains the recording engine’s “Trust Factor” system, which lets it know how much to trust what the phone tells it about movement at that location.

Location data from phones always has some degree of drift in it, even when stationary. The raw location data drifts around endlessly, sometimes over 10s or 100s of metres while inside buildings. The phone provides “horizontal accuracy” values for each sample of location data, for example “10 metres accuracy” or “100 metres accuracy”, meaning that the phone thinks that coordinate is within 10 or 100 metres of the real location. Arc’s recording engine then uses those reported accuracy levels to automatically smooth / filter out the drift. But sometimes (ok, often) the phone’s reported accuracy values are not true, and are instead significantly wrong.

That’s where “Trust Factor” comes in. By marking that segment as “stationary” Arc can know that any drift in the data at that location was nonsense, and because that drift wasn’t already filtered out based on the phone’s reported accuracy, it means that that reported accuracy wasn’t trustworthy. So the Trust Factor for that coordinate region is recalculated, lowered, and in future the recording engine will add a fudge factor to what it’s told when the phone reports current accuracy. So the phone might say “this is within 10 metres of the real location”, but Arc’s Trust Factor says “nah, we really don’t trust what the phone says in this area”, so it will be treated as being within 100 metres of the real location instead (as just rough examples - the real numbers are much fiddlier).

So by correcting those nonsense segments inside visits you are a) teaching Arc that you don’t travel by car inside your house (duh :joy:), but you’re also teaching it not to trust the phone’s reported accuracy inside your house either, and that Arc should much more aggressively filter out drift at that location. Very quickly that will mean the drift will disappear (in subsequently recorded data), and you will see more consistent stationary segments, with less nonsense drifting/moving data inside visits to that place.

Now to nonsense segments inside trips: while these can be reduced significantly by Arc learning from your corrections, you don’t actually want all of these fixed. Why? Because sometimes you will genuinely do things like that. For example you’re cycling, you come to an awkward area where you need to briefly walk, so you walk for 10-20 metres, then you jump back on your bike. Walking and cycling can look very similar to the activity type classifier (they have quite similar accelerometer data and other model factors, especially at slow speeds). So if the classifier aggressively tried to keep every segment within the trip to the most dominant type, it would filter out those walking segments and classify the whole thing as cycling. But now you’ve got wrong data and no easy way to fix it. When the “possibly a different type” segments are kept, there’s still an easy way for you to split those segments out if you want to.

The cycling → walking → cycling example is perhaps not one where you’d care, but there’s lots of cases where having the opposite happen (ie it all merged together into a single segment of one type) is a hassle, because the only way to fix it is to go into the “Split Segment” view, which means fiddly work nudging back and forth with individual samples.

Oh, I missed the most common case: brief stationary segments inside trips. Any stationary segment that’s shorter than 2 minutes will be merged into the trip rather than being split out as a separate timeline item (2 minutes being the “keeper” threshold for Visit durations). Having those stationary segments preserved in the trip’s segments view means you can still see and potentially work with the brief stops along a trip.

This is super useful for things like walking through a market and stopping at individual stalls for brief looks, then being able to match those stationary segment times up with the times of your photos. Or perhaps you were stuck in stop-start traffic, and the stationary segments show you clearly which portions of the trip that happened in.

If you tap on a brief stationary segment inside a trip, you can then assign a Place to it, which will split it out as a separate timeline item, even if it’s shorter than 2 minutes. (Visits with manually assigned Places are considered “keepers”, regardless of their duration). So that’s a handy way to split out little things like the above example of individual stalls in a market, for times when you really want to keep those details (and doubly handy if you took photos at the stalls, because then you’ll see the photos in your timeline view, tidily shown with the correct stall names).

With all that said, I do still want to improve this system so that we see less of the clearly nonsense segments. Correcting them will teach Arc to be smarter about them in future, so Arc will make increasingly tidy and correct data over time, as it learns, but there is still going to be some data that a human eye knows is obviously nonsense but a computer doesn’t.

I have planned a major upgrade of the underlying ML (Machine Learning) engines inside Arc. However because they’re already very complex systems, detailing with data and models over the whole world, from global scale right down to street level, it’s going to be quite a project. I’ve already got a fairly well fleshed out and solid plan for it, but it’s going to chew up a big chunk of time and testing. So it’ll have to come after the other big projects that are already underway (eg Arc v4, Arc Mini, and the new backups system).

Anyway, I hope that goes some way to help and explain!

Cheers,
Matt

Thanks Matt.
After editing segments for all days, i am not seeing wrong data when i am stationary

1 Like

@warefe8068 Glad to hear!

You may still see the data go a bit nonsense from time to time while stationary. There’s some mystery things that happen with iOS / iPhones occasionally, that cause the location data to temporarily go to shit, and it’s most likely to happen while you’re at home or work (or any place you typically spend a lot of hours). There’s no known reason for that - it’s just iOS being weird - but thankfully it’s usually just a once off thing, that comes right on its own, typically within a few hours :man_shrugging:t2: