# Merging two adjacent 'walking' segments

**URL:** <https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555>\
**Category:** Arc App Support\
**Created:** [22 August 2023 07:11 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555 "2023-08-22T07:11:58Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![fra](https://avatars.discourse-cdn.com/v4/letter/f/a6a055/32.png) [@fra](https://support.bigpaua.com/u/fra)\
**Post date:** [22 August 2023 07:11 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/1 "2023-08-22T07:11:59Z")

</div>

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?

 ![Screenshot 2023-08-22 at 7.09.50 PM](https://europe1.discourse-cdn.com/flex013/uploads/bigpaua/original/1X/d6ea4490c0a1f1bc2001053f1984ae26a3757951.png)

---

<div class="post-metadata">

**Author:** ![Astra](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/astra/32/445_2.png) [@Astra](https://support.bigpaua.com/u/Astra)\
**Post date:** [22 August 2023 07:29 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/2 "2023-08-22T07:29:47Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![matt](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/matt/32/3_2.png) [@matt](https://support.bigpaua.com/u/matt)\
**Post date:** [23 August 2023 01:18 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/3 "2023-08-23T01:18:11Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![matt](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/matt/32/3_2.png) [@matt](https://support.bigpaua.com/u/matt)\
**Post date:** [23 August 2023 01:22 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/4 "2023-08-23T01:22:41Z")

</div>

You can actually see all those rules in [LocoKit’s source code](https://github.com/sobri909/LocoKit/blob/master/LocoKit/Timelines/MergeScores.swift), 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!

---

<div class="post-metadata">

**Author:** ![fra](https://avatars.discourse-cdn.com/v4/letter/f/a6a055/32.png) [@fra](https://support.bigpaua.com/u/fra)\
**Post date:** [23 August 2023 02:55 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/5 "2023-08-23T02:55:54Z")

</div>

> [@Astra](#):
>
> Yep, you can select each of them and mark them as “walking” in the edit menu and they will merge.

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.

---

<div class="post-metadata">

**Author:** ![matt](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/matt/32/3_2.png) [@matt](https://support.bigpaua.com/u/matt)\
**Post date:** [24 August 2023 01:28 UTC](https://support.bigpaua.com/t/merging-two-adjacent-walking-segments/555/6 "2023-08-24T01:28:59Z")

</div>

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:

```swift
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:

```swift
// 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 😂