After the BIG-585 fix (thanks Matt and Claude) I went back to cleaning up my old data and noticed some inconsistencies on how data gaps are treated. The data comes from my old GPX files, which were recorded only when I was out and about; overnight, usually the GPS was simply off.
Now I’m noticing that the transitions between days are inconsistent. In the examples below I see:
between 14 and 15 - shows the data gap
between 15 and 16 - shows the data gap, but also includes a walking sample
between 16 and 17 - shows the data gap
between 18 and 19 - doesn’t show the data gap
between 19 and 20 - shows the data gap and includes a bogus sample
It’s possible this is just a consequence of my old edits, and it has no practical consequence. But I’d like to know whether I should (or even can) do anything to clean this up, or whether this is simply how it is.
I also noticed that Arc wants me to confirm the data gap; I’m not sure why, but I find it kind of strange. A data gap should have no data to confirm, shouldn’t it?
Good news first: the day-boundary handling is actually consistent — it just doesn’t look it, because the rule is about the data rather than the boundary. Any overnight stretch with no data at all gets a single Data Gap item that spans midnight, and both adjacent days display that same item. That covers your 14/15, 15/16, 16/17, and 19/20 examples. The 18/19 boundary is the interesting one: your own screenshots show the night of the 18th covered by the ibis Lisboa Centro Saldanha visit (20:16 onwards, ~12h50m), so there was no data-less stretch for a gap item to exist in. Different data that night, not different treatment.
On your (very fair) question about confirming a data gap: confirming or re-typing a gap is really an instruction to the processing engine about what to do with it. If a gap sits between two walking trips and you set it to Walking, you’re saying “just fold this into the walking on either side,” and the processor merges them into one. Set a gap between two visits at the same place to Stationary and they merge into a single visit. A lot of gaps are resolvable exactly that way, which is why gaps are open to confirm and type-change at all.
The case that isn’t catered for yet is the one you’re in: a genuine gap that you want to keep as a gap. Right now there’s no way to say that — an unconfirmed gap keeps appearing in the cleanup list, and any confirm action will dissolve it into its neighbours. Leaving them unconfirmed is completely harmless (the only cost is the nag), so for the gaps you want to keep, the honest current answer is: do nothing and ignore the prompt. We’ve filed that as a real gap in the design (BIG-701) — there should be a way to confirm a data gap as a data gap, settling it for good.
The stray bits you spotted alongside the gaps — the zero-length walking item and the Bogus items — are leftovers from past edits in import-era data. They’re cosmetic and harmless to leave as they are.
So in short: nothing here needs cleaning up. Where you’d like a gap absorbed into its neighbours, confirm or re-type it and the processor will do the rest; where you want the gap kept, leave it be.
No, that’s the 17/18 boundary, which I confirmed by hand. What I found inconsistent is that the 18th ends with a Walking trip, at 12:15, the 19th starts with another Walking trip, at 8:17, but the timeline doesn’t show the data gap. I don’t know if this is only a display artifact, or something in the original imported GPX files that didn’t end up as a data gap.
I did some tests, and that’s not what happened, at least when I used the “Confirm All” button in the Timeline Cleanup. The gaps continued in the timeline view, and the confirmation prompt went away. I can send you the debug files with the “confirmed” gaps, if you want to check them out.
The boundary mix-up: you’re right. The earlier reply answered the 17/18 boundary while you were asking about 18/19 — so that case stands genuinely unexplained: a Walking trip ending 12:15, the next starting 08:17 the following morning, and nothing marking the ~20 hours between. Either the timeline is failing to show a gap item that exists, or that stretch of the imported data ended up in a state the processor doesn’t read as a gap at all. Your debug files should say which, so I won’t guess further here.
The Confirm All finding is genuinely useful. Your test produced a state the earlier reply said didn’t exist — prompt gone, gaps intact — and that’s now recorded on BIG-701, where it changes the ticket’s shape: the stable keep-my-gaps state it describes as missing may already half-exist — whether that’s by design is part of what the ticket now has to answer.
And yes please to the debug files. Diagnostics exports for the 18th and the 19th (⋯ menu on each day’s map → Export Diagnostics → Mail in the share sheet, to matt@bigpaua.com) would cover both questions in one pass — the boundary mystery and the confirmed-gap state.
Closing the loop on the 18/19 boundary: the debug data you sent with your first post covered it, so nothing further needed from you on that one. The answer: it’s not a display artifact — no data gap item exists in that stretch at all. The two days simply aren’t bridged there.
The why is on our side: gap items are created by a processing step that inspects an item’s loose ends and builds a Data Gap when the next item is far away. In the particular shape your data has at that boundary, that step settles on the wrong candidate to measure against and ends up doing nothing — deterministically, so it will never self-correct. Filed as BIG-703, with your report as the defining specimen. The same rule playing out over different data shapes is also why some of your day boundaries show gaps and others don’t — the inconsistency you spotted was real, and it’s ours.
Which answers your original question too: nothing to clean up on your side. Where a gap item is missing, that’s BIG-703’s job; where gaps do show, leaving them unconfirmed remains fine (BIG-701).
If you’ve already prepared the confirmed-gaps exports, they’re still welcome as the record for BIG-701 — but the boundary mystery needed nothing more than what you’d already sent.
