ArcApp merges few transport types into one about locokit

[sobri909]

Weird!

I don't think it'll be because of the 2.2.0 update. Nothing with timeline processing has changed recently. I think you'll be seeing an old bug, but for the first time.

From the video, my hunch is that TimelineProcessor is ... well, if I had a good guess at what it's doing, I'd have fixed it already 😏 But the way it reassigns the samples back to the path in visible steps (rather than as a single action) suggests that it's the result of visit/path edge cleansing.

But it doesn't really make sense in that context, as it's paths aligned with paths, rather than paths with visits. So I'm struggling to see the cause there. Usually you'd only see those visible steps of reverting when it's a change on a visit/path edge.

You could try "confirming" one of the other segments first, ie tapping on one of the walking segments and reassigning it to walking, to see if that gets around it. But that wouldn't explain why it's happening.

There's something mysterious going on there. The processing engine looks like it knows something we don't, so it thinks it's doing the right thing. But from where I'm sitting, it looks like it's quite mistaken.

[bionicl]

Trying to split by clicking 'walking' (in the case of this video) doesn't do anything different.

One experiment I tried, was changing 'train' to different type I haven't used before - for example 'boat' - it was successful! But changing back to train/car caused the same as in the video. I had a few same examples, each one behaved the same.

I'll check in the free time if there is something unusual in moves json day files, but I don't think that's the case

[sobri909]

Wow. If it acted differently when assigned to boat, then ... I'm very confused. The assigned type shouldn't make any difference, as long as it's not the same as the type as the item it's being split out from.

The processing engine always reprocesses after any manual change, thus reapplying it's own rules. It's not allowed to override our manual ActivityType and Place assignments, but it will reassert control over TimelineItem boundaries and sample/segment ownership. So when an ItemSegment is split out, the processing engine might decide that the new arrangement isn't workable, and either partially of fully merge things back together again.

But in the case in your video... I just can't see how it would believe that's the right thing to do. It doesn't fit with any of the rules. Either there's something unacceptably wrong with the data that we're not seeing, or there's a weird bug / logic fail in the processing engine rules. The video really doesn't show any hints of problems with the data, so it must be a processing engine rule failure somehow. But... how? Heh. Perplexing.

[sobri909]

For a path-path merge, I'd normally expect the answer to be in here:

https://github.com/sobri909/LocoKit/blob/develop/LocoKit/Base/Timelines/MergeScores.swift#L114-L150

But in this case none of those rules look like they could possibly have been triggered. And the fact that the merge happens in stages, rather than a single act, means that it must surely be a visit edge cleanse. So maybe the answer lies in a visit item on one of the ends of the resulting mega path. Something fishy going on in the visit's data, perhaps.