Every now and then, a walk gets split into two ‘walking’ segments, which show next to each other (see photo). Is there a way to merge these into one?
Yep, you can select each of them and mark them as “walking” in the edit menu and they will merge.
Even though they look like they’re marked as such already, confirming it manually gives Arc more confidence to merge them. Also, if you look in the “Edit individual segments” menu, you might see some non-walking segments. They also can prevent Arc from merging the segments, and the aforementioned manual confirmation will mark them all as “walking”.
(the description in the second paragraph may not be entirely correct, but the solution definitely works)
2 Likes
Yep, @Astra’s solution is the one! I do the same.
This situation is the result of a quasi-bug, or rather a weakness in the timeline items processing engine’s heuristics.
One of the rules / heuristics the processing engine uses when deciding whether to merge two adjacent items is something like “do the two adjacent edge samples have the same activity type” or “have a similar enough confidence score for being the same activity type”. (I can’t remember the exact rule, but I think it’s something like that).
What then happens is sometimes the final sample at the end of a walking item might really not look like walking at all, but that sample ended up standing alone as the odd one out, with the subsequent samples again looking very much like walking. So the processing engine first ends up with items like: 1 minute of walking -> 1 lone sample of car/bus/stationary/whatever -> 1 minute of walking. It will then decide to merge in that lone sample into either the preceding or following item, because a single sample on its own doesn’t meet the threshold for being its own timeline item. But then when the processing engine, on next iteration, looks at merging those two walking items it comes up against the edges not matching, and decides it can’t merge them.
Obviously that’s a logical failure in the processing engine heuristics. It shouldn’t be thrown off by something like that. But there it is - it’s happening. I’ve looked into it a few times before and not been able to spot the logic failure. It all looks sane and sensible. So really I need to catch it in the act, then go straight to the debugger and examine the data at that moment, and hopefully have the “ah hah!” moment where I can spot the logic fail.
Aside: The reason why confirming one of the items as walking fixes it is because whichever rule/heuristic is blocking the merge isn’t applied if one or both of the edge samples have a confirmed type (and presumably those types also match).
1 Like
You can actually see all those rules in LocoKit’s source code, for anyone who’s programming language inclined. (It’s presumably the “PATH ← PATH” method).
Though looking at it now, I can’t see the rule I described at all. Although I know something like that does exist somewhere. I’m probably remembering the structure of events wrong in some way. All of this stuff is many years old now - Arc is getting old!
1 Like
Thanks, Astra! That worked perfectly.
And thank you, @matt, for the detailed description of how this works. I really appreciate the great support in these forums.
2 Likes
Thanks @fra!
Looking at the code again, I wonder if my explanation above was totally wrong, and I was thinking of some completely different issue there. I wonder if it’s actually something to do with these lines at the start of the “PATH ← PATH” function:
let consumerType = consumer.modeMovingActivityType ?? consumer.modeActivityType
let consumeeType = consumee.modeMovingActivityType ?? consumee.modeActivityType
From what we can see looking at the items in the app, they’re both classified as walking, which means the modeMovingActivityType should be walking for both items. Which should match the rule:
// perfect type match
if consumeeType == consumerType { return .perfect }
It should be a “perfect” scoring merge. So surely the failure must be one of the items not returning walking for modeMovingActivityType. Hmm. But I wonder if this is why I haven’t been able to find/solve the problem before. That then leads me to code that also looks entirely sane, where I can’t see how it could possibly not return walking for that value. Sigh.
These ones are always “fun”, the really old bugs that hang around forever, because every time I look at the code it all looks perfectly correct 