the same location is mentioned twice with overlapping times (???)
the arrival time for the bottom location is wrong. Should be around 16:24
the end-time of the bottom location is wrong. This is actually the time I got home after cycling home
the bottom location has incorrect GPS data and I have not even been there. On the map it is the dot right above Rijnsburg, but it is actually the dot in the top of the map. So it is not only inventing a location, it is also naming it the same as a totally different location
The cycling activity of 1h 9 min is wrong. This is the time I spent at the location
when I edit the individual segments for this activity, I cannot delete the bogus data
So it is a real mess. No idea what happened here, but I have not succeeded in cleaning it up.
Hope this makes sense to you…
Ok, there’s a few things going on there! I’ll try and address them one by one.
For this one, go into that visit and then into Individual Segments view, and find the segment(s) for the incorrect GPS data, then tap on them and mark then as Bogus. that will remove them, and hopefully allow the processing to clean up around it.
The Place classifier uses more than just location to determine its place matches. It also uses common arrival times and common durations.
Though it could also be a case of the incorrectly assigned Place having an overly large place radius. So you can tap into the visit and look for the orange circle on the map. That orange circle indicates the Place’s centre and radius, based on all confirmed visits to that Place. If the orange circle is much larger than it should be, and/or the centre of the circle is off, it will mean one or more visits have been incorrectly assigned and confirmed to that Place, which will be throwing off the classifier. In that case, it’s worth tapping through to “Total visits” on the item details view, to look for potentially incorrect visit assignments that you can then correct.
This one looks like a genuine bug, though one that the processing engine will often self correct either immediately or some time later. But if it hasn’t self corrected it, you can go into the Individual Segments of each of the two visits, and do a little bit of cleanup, and that will usually help the processing engine to spot the mistake and then fix up the duplication itself.
I’m still hunting for the cause of that bug. It’s a really tricky one. But I’ll get it eventually.
There’ll likely be a stationary segment at the end of the cycling item, again findable in the Individual Segments view. This mistake is likely a side effect of the same bug as the duplicate overlapping visits. So hopefully once I find the cause of one I’ll be able to fix both. Anyway, you’ll almost certainly be able to clean it up in the Individual Segments view.
Bogus data isn’t actually deleted, it’s just marked as bogus and removed from all calculations for the visit/trip. Keeping it in the database allows the classifier to learn to identify common bogus data at specific locations (for example a building that produces the same kinds of nonsense data every day, which the classifier can then automatically identify and mark as bogus for you).
The segments for the Cycling activity are just the bogus of 58 min. and the actual cycling of 9 min. Since I cannot delete the bogus data, the incorrect timing remains
Note: it would be nice to have an “Undo” to reverse unfortunate edits
Aah ok. Then in that case you might be able to trick it by tapping on the cycling segment and choosing cycling again. (Changing the assigned type of a segment will always split it out as a separate timeline item, and it doesn’t check to see whether you actually chose a different type or not).
If the processing engine still merges the bogus and cycling back together after that… You can try splitting the cycling segment so that the very last sample is stationary instead of cycling, and then that’ll give you a stationary segment that you can assign to the proper place. Doing that will force the bogus to be a separate timeline item between the main visit and the new single sample one, which will result in the processing engine merging those three together.
Yeah, before you say it, I agree these workarounds are a fiddly mess. It shouldn’t be this hard. There’s a lot of friction points around bad data that could still be greatly smoothed out, and this is one of them. Someday if Arc ever earns enough to support two developers, I’d love to go back to this lower level stuff and spend time on fixing all of these edge case annoyances.
Thanks for that. I changed the bogus data to “stationary” and Arc automatically deleted it and kept the cycling activity with correct duration. So I’m happy
On the bright side: it is possible to edit, so …
