About half of the time, Arc alleges that I am residing at the park next to my house, rather than my house.
If there was a way to automatically say that any visit to the park over an hour should be remarked as my house instead, that would help.
Are duration of visits being used in the categorisation intelligence?
Cross-posted from Move all visits of a place to another | Arc App on changemap
Yes, definitely!
However when a Place is first automatically assigned to a Visit, it will be done just before the recording engine goes into sleep mode. (It needs to know what Place you’re at to know how likely you are to leave, thus how deeply it should sleep). So when it first assigns a Place, the Visit will likely only be a few minutes long.
However when you open the app later, the automatic Place assignments will be reassessed, and if the previous best match is no longer appropriate, it’ll get automatically changed. (Note that this doesn’t happen for manually confirmed Place assignments - those stay as you confirmed them).
So if you open the app to check the Place assignment shortly after arriving somewhere, it might still have an inappropriate assignment, if there’s another commonly visited Place nearby that better matches short visits. But when you reopen the app to check the timeline later on, it will be automatically updated to the better match.
More specifically to this problem, it’s likely that some Visits have been incorrectly confirmed as being to the park, which will be confusing the models. (The models base their choices only on assignments you have explicitly confirmed - automatic assignments don’t influence the models at all).
The easiest way to fix this is to go into the details view for one of those park visits, scroll down to “Common duration”, and tap through to that view. The bar graph in there lets you tap on different common durations, then below you can tap “Visits” to see a list of all visits that fall within that duration. Then you can quickly identify visits that have clearly been incorrectly assigned, and correct them. For example if you’re only ever at the park for 5-20 minutes, but there’s a bar for 6 hour visits, you can know that all those 6 hour visits are incorrectly assigned, and now have quick access to correcting them.
Once those corrections are done, the models will be much less likely to make the same mistake again. (Though it will take up to a day for the models to get updated in the background).
Unfortunately after about one or two reassignments the Arc app crashes, tried this when you posted that and still continues today. Does it automatically send a report or shall I send a video of do something else?
Crash reports do come through automatically, so I’ll have a sift through and see if I can find the crashes.
Though it’s likely an intermittent crash, so I’d recommend trying to do the reassignments again. Or alternatively you can wait for the next Arc release, which will include the “move all visits to another place” feature. I’m working on finishing up that feature this week 
Happens everytime. Here’s a video and the debug information.
arc: 3.11.0 (3110002), dev: iPhone12,3 (16.5.1) en-AU
id: true, qe: false, bf: false, tt: false, bl: true, br: true, no: true
ro: true, cs: true, ib: true
ic: ready, mi: false
i: EE8CAFE9-B512-4A24-B6B9-8F8125C0066C
r: DBF4A431-DCEF-486A-9B00-C10632EB2BED
Unfortunately for visits less than an hour I am probably at the park.
Ugh. Then yeah, the “move all visits” feature isn’t going to work for you. You will have to do gradual cleanup from the “Common durations” view. Which means I really need to find that crash!
I’ve had another look, and can’t yet find any common crash that might be it. I’ll keep looking.
Oh, I just noticed from your video that you’re going into the “All visits” view rather than the “Common durations” view first. Though it might not make any difference, given the view it appears to be crashing on would be the same view in both cases (either the Visits List view or the Item Details view).
But just to double check, do try going through the “Common Durations” view first, then tapping on a histogram bar for a duration that you know will contain visits you want to reassign, then tap the “Visits” bar at the bottom, to get to the Visits List view from there.
Whether I go into that the Visits List and Item Details views from “All Visits” or “Common Durations”, I can’t replicate the crash on my phone. Hmm. I’ll keep hunting for the crash report in Crashlytics, and will also see if I can spot any potential culprits in the relevant code. I happen to be working on code around that area at the moment, in preparation for the “move visits” feature.
Happy to jump on a call if that’ll help.
So the new update fixes the crashes, however it does not remove updated places from the place list, and the delay in applying place relocations makes the place list very confusing. See video
Glad to hear it fixed the crash!
I’m not sure what you mean by “remove updated places from the place list”. I think I’m having a slow brain morning. Oh I think maybe I get it - you’re going through the visits list and changing the visit’s assigned place, but then when you tap back it’s still in the “All Visits” list. Yeah ok, that makes sense. (Well, not sense - I agree it shouldn’t really do that).
Ok so I think what I need to do is make the “All Visits” view update its list on appear, so that when you tap back to it it updates the list. I’m thinking that should be harmless/safe to do, without causing issues. I’ll add it to the todos 
Yep, that todo is correct.
I’m thinking the most user friendly solution to this would be the ability to be able to on select multiple entries on the entry listing page via two finger select or swipe to select or tap edit then tap checkbox, then have a mass relocate button. Akin to how ios reminders or mail apps work.
That way I could just select all the few hundred problem entries at once and relocate them.