Is there a way to tell Arc to expand its radius for a location and get it to stick?
Specifically I’m encountering this issue. I’ll use a movie theater as an example:
walk to the theater
wait for a friend in the movie theater lobby.
walk to the specific movie theater auditorium.
stay stationary in that movie theater auditorium.
Arc tends to ignore the lobby wait and bundle it into the prior walk which makes for a very long and inaccurate walk time.
I can find the stationary lobby wait and push it to the main timeline no problem.
if I keep the walk from the lobby to the auditorium as walking, Arc is fine keeping both the lobby and the auditorium labeled as the movie theater.
BUT if I try to classify that walk as stationary so that it’s cleaner, ie I can see the time I entered then left the movie theater (so that the typical start/leave/duration times are more accurate), I can see Arc getting confused on the main timeline…
** it’ll initially bundle the lobby, walk, and auditorium into the stationary Movie Theater Location.
** but as I sit there watching, the walk to the movie theater slowly starts taking over and “pulls” into it the lobby time and the walk to the auditorium.
It’s funny because I have the reverse issue where I’m trying to make a location smaller in radius so it doesn’t keep getting applied to other locations. But sometimes it’s impossible to get Arc to acknowledge a wider radius for a location!
I’m mostly just sticking to keeping the walk in between the lobby and auditorium separate for now, as I’m more annoyed by seeing an exorbitantly long walk to the movie theater than seeing two “entries” for the movie theater with a tiny walk in between. But I’d love to not have to have them separate.
@Fly I have exactly the same problem, and I have a solution in mind!
A little background: The reason this happens is because Arc decides which samples stay in / get kicked out of a Visit based on the Visit’s centre and radius, creating a sort of gravity / orbital distance effect. If the sample is far enough away from the visit’s gravitational pull, it’ll get ejected out of the visit.
So as more samples build up inside the cinema, the centre of gravity shifts away from the lobby samples and they start to fall outside the gravitational pull.
If then you try to push them back in, by assigning them back to the Place, the processing engine will do the merge as requested, but then immediately eject the samples back out. Not helpful.
As you already know, the workaround is to assign them to separate places - lobby and cinema. But that’s forcing a timeline structure on you that you don’t necessarily want. Which is where my proposed solution comes in:
My idea is to allow visits to have multiple centres of gravity instead of just one. I haven’t worked out the full details yet, but I’m expecting that this will have both automatic and manual pathways. Meaning that a visit should automatically detect clustering of samples, and identify them as separate centres. But it should also work so that if you assign those lobby samples to the cinema place, that should add a manual new centre to the visit, so that they don’t get ejected back out again.
I’ve just double checked I’ve got that one in the tasks lists. It’s something I’ve been meaning to get around to for literally years
I wouldn’t recommend doing this @midor. Bogus should be reserved for only samples that have wildly wrong location data, ie a location that’s more than 100 metres from the real location. Otherwise the activity type classifier will start incorrectly classifying valid samples as bogus.
