When walking to a shop and making a short stop (i.e. to buy a coffee or drop something off) then carrying on home, Arc tends to record this as one continuous walk. This is especially the case if I’m walking around the shop (so not physically stationary for more than a minute). Is there any way to tell Arc manually that this shop is a ‘location’? The only way to do it retrospectively seems to involve ‘splitting’ the activity, which can be done by time only (which means I have to take a note of the time I arrived and left). If it were possible to point out the location on the map view, it would be easier. I would appreciate any tips on this. Thank you!
1 Like
I find that splitting still works to separate out Stationary location elements, even if you dont know the exact time, if you use the Nudge arrow, because Arc will zoom in on the split. Also, if you already set one part of the split to Stationary, it will show a location circle, which you can check for size.
1 Like
I think @Palmin has covered everything I would have said. So I’ll just offer the extra of suggesting you vote for this feature request: Insert Visit | Arc App on changemap
Basically the idea is that this new feature would simplify the process of extracting back out these short visits. It could potentially also be made to auto detect stationary segments, for cases where the activity type classifier failed to identify the movement as being “stationary” type.
With enough votes I can justify building the feature sooner rather than later!
To circle back to the original question, there is one useful piece of technical information: Arc’s timeline processing engine will preserve short visits in the timeline as long as they are at least 2 minutes long. So it’s typically only those brief under-2-minute visits that disappear and require this little segment splitting / segment extracting dance. But for things like convenience stores (or in my case the bike stand outside my condo) it can be a regular occurrence, so hopefully the feature will get enough votes to justify working on it soon!
Thank you; I’ve voted for the feature now!
1 Like
There is a sort of a similar (but definitely distinct) issue I’ve noticed: when reviewing an unconfirmed activity (like a walk or drive), small stops might actually be displayed within the activity, but if you attempt to name them, the only options are to choose from nearby locations or create your own private place; there’s no one-time visit option for these visits until a stationary point makes it to the full timeline (usually via those two options, after which you can rename it). Would be really nice to be able to have all the place naming options in the unconfirmed activity view.
I’ve just created a suggestion request on changemap, but figured I’d let you know on here as well.
1 Like
Yeah, this has been on my todos to fix for literally years. It annoys the hell out of me. But I only ever run into it on rare occasions, and those occasions are typically when I’m out and about, so by the time I get home I’ve forgotten all about it 
I’ll find the todo now and move it into the “Today” category, so that I can’t forget it so easily this time.
2 Likes
Bumping this suggestion up (as if I haven’t been bumping oodles of import suggestions up already!) as I’m running into this a lot while correcting imported data. The worst part is, Arc also seems to then default to that randomly selected location in other uncertain places even after I’ve switched the stationary point to a one-time location name.
Hm. Sounds like it’s not queuing the place for update again, after the visit is switched to a one time title. I’ll add that to the todos to check.
Aside: The rebuild of the Confirm/Edit view’s header in the coming update (hopefully arriving today) was done in part to make it easier to add those one time visit title options to other menus/views.
Arc has become quite an old application now (the first public beta was in 2016!) so a lot of the code has become pretty archaic and out of date. Arc has lived through several major transitions in iPhone app building “Best Practices”, which means a lot of the code was built in the “best way” at the time but is extremely difficult to make changes to now.
Pretty much the entirety of that Confirm/Edit view fell into that camp So I’ve been gradually ripping it apart, to modernise the code and make the various bits easier to reuse elsewhere in the app.
Thank you for this, it looks great! I love the way the prior and next locations are displayed as well to help with context around the segment we’re confirming / editing.
1 Like