The app does not correctly handle the merging of Stationary segments when I assign them the same location as an adjacent segment. The merge happens briefly, then the segments progressively split apart again.
Steps to reproduce:
Open the Timeline with the following sequence:
• Location A (arrival 7pm)
• Cycling segment (44 min)
• Location B
Open the details of the Cycling segment, which actually contains:
• 1 Cycling sub-segment of 34 min
• 1 Stationary sub-segment of 8 min with no assigned location
Assign to the Stationary sub-segment the same location already shown in the Timeline
Observed behavior:
The two segments merge at first, then gradually “un-merge” back into two separate segments.
Expected behavior:
Once the location is assigned, the segments should remain stably merged.
A note on what’s happening: when you assigned the location to that stationary segment, you effectively moved those edge samples from the trip into the adjacent visit. Then timeline processing ran and ejected them back out — that’s “edge stealing”, the mechanism that decides which samples belong to which visit by checking each one against the visit’s “gravity well” (centre + radius). Samples falling outside that well get redistributed back to the adjacent trip.
Edge stealing usually does useful work, cleaning up visit boundaries automatically — but the current thresholds are too aggressive, ejecting samples that genuinely belong. So your manual cleanup is being undone by a refinement step that’s currently over-tuned.
Filed as BIG-408 (High priority, on the to-do list).
I suppose this is also the explanation for the same behaviour but the other way round?
For instance: I board a train and it leaves the station at exactly 22:17 but the iPhone doesn’t feed accurate location data to Arc because the train is partially shielding the GPS signal. The next location sample is then picked up further down the line (and from then on, for some reason, it is very accurate) but that causes the Timeline to say that I went with a ridiculous speed because a bit of the journey keeps sticking to the start-location. It can be remedied if you single out one sample and mark it as bogus. Then it still glitches slightly but it’s less aggressive.
And there are other occurrences of this stubborn “the user clearly doesn’t know what he is doing and this section actually belongs where I put it first, not with where the user put it” behaviour.
I just figured it’s just the data model still learning. Glad to hear that it actually is a bug and you’re working on a fix!
This sounds like something I do sometimes see myself, and yeah train stations are a common way to trigger the poor behaviour. One useful datapoint would be how long you were at the train station before departure, and how close that duration was to the Common Durations peaks.
Like, if it’s a station you use frequently, the most common duration is around 5 minutes, and you did leave at around 5 minutes, then the dynamic sleep cycles would’ve been at minimum (6 seconds) so LocoKit2 would be on its toes, ready to jump back to recording mode quickly.
But if for example most common duration is 5 minutes and you didn’t leave until 15 minutes (which has no match in the durations histogram), then the dynamic sleep cycles might’ve been unhelpfully more like 60 seconds. That’d then lead to potentially a full 60 seconds of no samples at all
And then when it did finally manage to wake up, it’d be struggling with low quality location data, the Kalman filter fumbling about trying to sensibly update, likely some nonsense speed calculations, etc.
Which then leads into the situation which, yeah, does have some overlap with BIG-408. In that these now not very helpful samples will refuse to stay where they most sensibly should be. But an even worse situation, due to there not being really any samples to work with in the critical Visit->Trip transition zone.
@trackerminerfs Yep, definitely (well I’m pretty sure) the same thing as in your other thread.
My hunch is that BIG-408 will only improve the situation, and won’t be the ultimate fix for it. It’ll be tweaking of some thresholds, to make the edge stealing behaviour less “really? come on, dumb call Mr Timeline Processor”. Instead it’ll end up more like “k I still disagree with you there Mr Processor, but at least you didn’t make as much of a mess as you used to”.
Aside: I don’t know why I like to think of all the subsystems as people I guess it makes it easier for me to conceptualise their decision processes, and also frame them in terms of what we would be thinking and how we’d be deciding. Which can often lead to clearer ideas of how to improve the code.
Anyway yeah, BIG-408 first (I’m quietly hoping to sneak it into the next update), then ultimately something smarter and more conclusive will arrive later.
Thanks for the thorough reply, always appreciate the deep dives.
As for this specific visit and day… no, this train station is not commonly frequented by me. I mostly pass through, if I go on that train line at all. I changed trains there earlier that day but I had to run between platforms so there was no actual visit there. And the last proper visit there must have been a year ago or so. On that specific night, I was stranded there because severe weather conditions had grounded all trains further up the line. So I spent over an hour there wandering around the platform, getting a snack from McDonald’s downstairs, and wandering around again (shaking my fist at the display with the ever increasing “delayed by” number). My wandering around (with all the funky GPS jumps) is grouped together in that visit, which probably makes the model think even more that I was just still in the station, only to teleport some kilometres down the line later. It would be nice if it would take user input as “more close to the truth” somehow… as if user corrections are weighted more heavily in the decision making of sorts, if that makes sense.
Anyway… it’s no biggie. Just a bit of a data-nerd itch to know that it’s inaccurate. Otherwise, the data is there: the visit to the station, the train ride, etc…
@JanVanOostenrijk Yeah that sounds very much the shape of the poor place model matching / too long sleep cycle durations that I was speculating. An existing gap in the “learning”, where results are worse than you’d hope when the models aren’t fleshed out enough yet (or are entirely absent, for new places). I want to eventually get to more generalised improvements in that area at some stage. Though I don’t have any especially clear ideas yet!
This kind of loosely maps to something we do have filed for the future! Ticket number BIG-174.
That one is about places rather than visits, but the gist of it is… multi centred places. Like, right now places are just a centre and a radius, that’s it. And same for visits - centre and radius. If samples fall outside of that “gravity well” they’re kicked out (the BIG-408 refinement work).
But if places (and ideally also visits) could be more real world shaped, either multi centred or something else smarter (we’ll get to dreaming up various clearer ideas once the task gets started, no doubt), then that would in principle permit that action of assigning the stationary segment to the visit being signal for “actually this visit/place isn’t as simple a shape as you currently think”. That would be the user action → higher trust signal, of a sort.
Oh tangent: we’re doing the underground train work at the moment, over the past few days, and getting some promising results! It’s still an incredibly tricky one, given that it’s most often only cell tower triangulation data available (with 1km+ accuracies), and sometimes not even that. But the next update should at least substantially better than the current build!
Not entirely the same issue, but almost the reverse issue: Back in the old version when for example flying on a plane (or also travelling longer distances on a train) where at best a few locations are picked up along the way (in the worst case only start and finish), these were then connected by. straight line between the start and end point. This gave at least some overview of these travels, while now only the few actual recorded locations remain visible. Is there a way to convince Arc to connect such trips again?
I feel like for my issue we probably just need some sort of awareness of whether a sample is assigned to a place automatically or manually. If the assignment had happened automatically, then sure kick out those samples outside the gravity well. But if the assignment had happened manually, then we should expand the gravity well by increasing the radius for that place. The manual assignment is basically the user saying the sample is part of the place, so the app should respect that. The app probably doesn’t have a good idea of how large that place is; a large building may not have multiple Google Places listing, so the user just assigns all samples to that single place.
@geoviews — Matt asked me to take this one because the explanation gets into some technical nuance about the merge logic he thought I’d describe more reliably.
First, a workaround you can try (with honest caveats up front): tap into one of the airplane items, into its individual segments view, tap a segment, and re-confirm “Airplane” as the activity type. That triggers an extract-and-reprocess cycle, which gives Arc another chance to evaluate merges across the surrounding items. Some of the fragments may merge back into larger airplane items as a result. Worth trying on each of the items.
Why “may” rather than “will”: the underlying issue is that Arc’s trip-merge logic has a plausibility check that looks at the trips’ computed speeds + time-separation, and gates merging based on whether the actual distance between them is plausible given that math. For sparse-sample trips (like long-haul flights, where iOS only captures a handful of points across many hours), those computed speeds end up noisy or sometimes artificially zero — which makes the plausibility budget unreliable. Sometimes it allows the merge; sometimes it blocks it for inputs that would clearly be the same trip if we had decent samples.
The tiny “Airplane · 20 secs, 0 m” items between your real airplane segments are part of the same shape — each one’s likely a single isolated location sample iOS managed to capture mid-flight, now sitting as its own micro-trip-item. The merge logic struggles to absorb them too.
Old Arc’s “drew a straight line” behaviour was effectively the result of these sparse samples merging more aggressively into a single trip item (which, on the map, would naturally render as approximately a straight line between the few known points). AT4’s stricter merge logic — generally more correct overall, less prone to bad merges in regular cases — falls short here for the inherently-sparse-sample activity types like flights and long trains.
Filed as BIG-570 — sparse-sample cases like this are a known weak spot of the current merge logic, and improving it is on the list. We want to do better there.
Yeah exactly. Though how best to do this in code and schema is… going to be tricky.
And there’s nuance to how much we can trust user actions. For the situations we’re describing here we’re confident the user is making the right call. But there’s plenty of cases where people either don’t have as much understanding about the data, or just plain accidentally tap the wrong thing and didn’t mean it. So timeline processing still has to have some authority to say “actually no, what you’ve done there, I don’t accept it. that’s going to make a horrific mess”.
The challenge is finding the middle ground (and the schema and code shapes), so that we’re getting more explicit control than we have now, but the system can still intelligently overrule when appropriate. Right now it’s overruling too aggressively, and has no information about the user’s intent. But yeah… we’ll get there eventually!
I’m looking forward to both of these pain points getting some love! Multi-centered visits especially. The number of times I got into a stubborn rut with Arc just trying to convince it somehow to retain my place designation instead of kicking it out and adding it to the walk before/after… and yes I tried many times despite seeing that it wasn’t working, hence “stubborn rut”
@Fly Hah, yeah, Arc can be quite opinionated! And if it strongly disagrees, we can’t win, even if it’s clearly wrong and we’re right.
Though that opinionated processing is quietly a good thing most of the time. It’s one of those “never notice it when it’s working correctly” things, doing high value work that doesn’t stand out until it goes wrong. The timeline processor’s rules enforcement takes messy raw data and reshapes it into (usually) sensible timeline shapes.
Anyway yeah hopefully the multi centre thing will be the big win. And the near term thresholds adjustment work should help in the meantime too. I’m hoping to have a new build shipped soon! Though now that I say that… I’m not sure what’s going to make it into that build just yet. Will have to get my ducks in a row today, get a sense of what’s making it in.
Yeah same issue here, sometimes you just can’t seperate a stationary segment out of a walking/car etc. segment, since after you confirm them, the stationary segment went back. I’d propose users should be able to overide default system processing. When we are manually editing things, usually it means the system is wrong, so if the system still reverts the edit, what’s the point of the edit then. Oh one behavior I observe is that the segment don’t merge back until you confirm your edits, so if leaving it as unconfirmed it does stay seperated, though it wouldn’t merge with adjacent stationary segment which is still a problem. For instance here, the two stationary segment around the walking are results of my manual edits (confirm stationary segment in the walking segment, hence seperated out), but then they stay seperated while unconfirmed, and the if you confirm, they merge back to the walking segment instead of the two stationary segment.
This is the most noticeable problem I encountered as it appeared multiple times now, hopefully it’ll be fixed soon by applying “our edits should override system defaults”, or something similar
@dyang886 thanks for adding your experience here. There’s actually a workaround that holds up today, which might help in the meantime: the revert happens because you’re assigning that stationary stretch to the same place as the main visit — so the two merge (same place), and then the processing shunts the edge samples back out. If instead you assign that stretch to a different place, they can’t merge, and the split sticks. It’s why Matt keeps a few private places like “Parking” or “Lobby/Reception” for exactly this.
The caveat: that’s only worth doing when the stretch genuinely belongs to a distinct place. Sometimes those edge samples are just the location settling as you moved inside a building (the track catching up while you were already indoors), and forcing a separate place there is adding detail you didn’t ask for. But when it is a real separate spot, you often get a more accurate timeline as a bonus.
On the underlying behaviour: what you’re hitting is filed as BIG-408 (the thresholds being too eager to revert — a near-term fix), with the broader handling tracked alongside it. It’s come up from a few people now, so your report adds to the case for prioritising it.
I guess it makes it easier for me to conceptualise their decision processes, and also frame them in terms of what we would be thinking and how we’d be deciding. Which can often lead to clearer ideas of how to improve the code.
