Timeline ≠ editor

Hello,

I use both the old Arc Timeline and the new Arc Editor. Despite the redesign of the application, I still have to confirm the location of my home every day.

I live in the middle of the countryside and there isn’t much around apart from a few other houses. And when I edit the square in Arc Timeline, it doesn’t show me anything other than my house. So there’s no possible confusion.

However, I notice that the map display is not identical from one application to another. With timeline, see image, I have an orange circle 20 m in diameter followed by a purple circle a few metres long (see first image). On the other hand, with editor, the orange circle is almost 400 m in diameter (see second image). The purple circle is the same size as in timeline.

I should also point out that these images were taken at the same time.

How do you explain this difference between timeline and editor? And why do I still have to confirm my home again and again? Will this situation be corrected in a future editor beta?



Siso

I’m pretty sure the difference will be that in Editor one or more Visits have been incorrectly assigned to the Place, resulting in its various being pushed out inappropriately.

Unfortunately Editor doesn’t have the nice map updating on the Visits List View that makes it easy to find the incorrect assignments and correct them. That’s high on my list of todos, to hopefully fix in the next build!

On this one I’m not entirely sure, but I’m experiencing the same problem. On the maths side the new Place scoring/ranking system in Editor is better than in old Arc Timeline. But in actual use… it feels worse. So I need to keep plugging away at it, doing various tests in different locations, spotting why it’s making worse decisions and fixing it.

I’m pretty sure there’s a mixture of factors - it won’t be just one thing (I’m not that lucky). In some cases it’ll be the weighting of the centre to centre distance scoring, in another case it’ll be the time of day scoring, in another it’ll be the … you get the idea.

In beta 2 I fixed some of it, for one specific case (the place I’m staying at now). But I could tell at the time that I was only fixing that one specific kind of case. It’s going to take more testing to feel out more cases and see where the weighting and scoring is going wrong.

Oh, on the upside, Arc Editor does have the foundations of cool new scoring features. Like, it’s going to be fairly easy for me to add scoring for prior trip and prior place. Like if the timeline is “home → walk → convenience store” or “work → cycle → cafe”, and the cafe and convenience store are right next to each other (making distance scoring not useful enough to tell them apart), then the scoring will be able to look at the walk versus cycle, and home versus work, and say “ok so this visit happened after a home visit and a walk, so it’s much more likely to be the convenience store”.

Arc Timeline doesn’t have any of that smarts. So I’m looking forward to adding those bits to Editor!

Even in Arc Timeline I had to often confirm home despite something like 6+ years of use and perhaps the nearest other visit is some store 1.5 km away. Then again there could be other situations such as someone in a big city with an apartment very close to other visits.

I think some of your sources include categorization such as residential or mixed-use? Perhaps you’re using that already.

@agastya is right, often in cities, the places you visit are close to each other.

Often the same sequence of visits is repeated week after week. For example, on Saturday, house → butcher → supermarket → house. Arc should remember these sequences and not suddenly suggest a walk when it’s usually a car journey. Similarly, it should not ask the user to confirm the car journey. The same goes for the journey from home to work to home, which we make 5 times a week. It’s not right that Arc should still be asking you to confirm this after 7 years of recording. This is what happens with timeline and also with editor.

That kind of mistake will basically always be the result of one or more incorrectly assigned Visits. Whenever you see that happen, that case of “oh it’s chosen a place that’s obviously too far away, when the correct place is right there”, that means there’s almost certainly an incorrect Visit assigned to the Place, messing up its understanding.

In which case you can go into the “All Visits” list view and scroll down to find the mistakes and fix them. Or often you can go into the “Visit Durations” list view, to then narrow down to just Visits that have an obviously wrong duration. Like if it’s a convenience store, so any visit longer than let’s say 20 minutes is almost certainly going to be a mistake.

The catch there is the system has to know what category makes sense in the current context. Though the upcoming model features of “prior Trip” and “prior Place” should help there. That gives it context, to match to a familiar sequential pattern rather than only to a familiar moment in time.

Yep. Exactly! That’s what those upcoming “prior Trip” and “prior Place” features will be for. To give the system that context. It’s basically the same kind of context we use ourselves - when we look at the timeline we’re scanning the sequence, and thinking “well obviously I didn’t go to the hardware store after walking from work; I went to the cafe, because what’s where I walk to every day from the office”.

Yep! The same improvement can be made for ActivityType classifiers too. Though the implementation will be a bit different, but ultimately it’ll be the same kind of context-providing, so that the system can make decisions with more sequential understanding.

Hmm. That mostly already shouldn’t be the case though. Is that a trip where there are genuinely other activities that you might take during that time / that route?

Like for me there’s some routes and times where I might be walking or I might be cycling, and both are similarly plausible. Those ones are the ones where Arc will ask me for confirmation (listing it as “uncertain”). Where as the ones where there’s only one sensible ActivityType match it’ll feel confident in its choice, and merely list it as “unconfirmed”.

Note that “unconfirmed” is only there for your informational purposes. Lots of people like to “lock in” the decisions, so that they can’t be automatically changed later. The “unconfirmed” list is for that purpose - to let you know which ones haven’t been locked in yet.

I had never really used such but since you mentioned it again I checked for some other visits and fixed some. I’ll see how it works now. Very handy.

As for something like home or elsewhere that might have visits over many years, it seems scrolling thru such can be a bit of effort. I see some cases such as being perhaps 15+ meters away on the street, which was maybe me sitting in my car on the street and marking such as home. Not sure if such matters.

If such gets rebuilt someday, maybe there could be some easier alternative? When there are a few visits it’s not so bad, but if there are many, maybe something could be easier to find what needs to be fixed though can’t think of what. Alternatively, being able to see some area or radius on the map and then see all nearby visits to possibly change some if necessary, that might too help.

Yeah it’s a super handy improvement to that view, with the map updating on scroll! It seemed like such a minor thing when I added it, but it turned out to be super useful.

That’s when I tend to use the visit durations graph bars, or visit arrival times. Like, if you know you only ever arrive at work in the morning, then the graph bars for arrival times in the afternoon will definitely be mistaken assignments. So I tap on those bars, then tap to view the visits that match that bar, then I can go through and correct each of those. That gives me a list of only a few visits instead of hundreds.

I have at least one problem with trying to fix previous mis-assigned places. When viewing All visits for certain ones, some are clear of how to re-assign them, but others such as maybe being hundreds of meters away, it might be something like in a car sitting at a stoplight or something else. There are instances of I’m not sure how to re-assign them and I can only know for sure by viewing it within the context of that day, yet I’m unable to.

I might have other problems with trying to fix previous visits but that’s a main one I see at the moment.

With the new Arc Editor I have another issue. One day that is correct in Timeline 3.x but with Editor beta, something went wrong. Maybe it was stopped by iOS, maybe something weird happened such as I deleted a visit so it merged in a weird way. For a particular day, it seems the original data is no longer there so it completely does not show that I visited somewhere. That there is now one travel by car from which there should be a visit but I cannot extract a visit. Maybe I merged it and such original data was deleted, or the app was stopped or something such that there is no ability to create a new visit. Instead a ~30 minute drive somehow appears as only not as a drive but a straight line from something maybe 5 km away to home which seems to not represent that drive at all, because there should be a visit within that but it is in a different adjacent city and the drive path doesn’t go anywhere near there. That somehow it became that.

For this, Editor has one UI improvement that helps. In the All Visits view you can long press on the visit to get to “View in Timeline”. Then if you select that it takes you to that day in timeline view, with a new “Return” button at the top of the screen, to take you back to the All Visits list once you’re done.

That allows you to both quickly tap in and out of visits from the list, while also being able to jump to timeline view to view each one in context, while also getting back to the All Visits list once you’re done.

Unfortunately because Editor still lacks the handy map updating in All Visits view, it’s … only partially there. The cleanup work is still a much slower and more difficult process. I need to get that map updating part done!

For the case of visits that look like they’re maybe “stuck in traffic”, or some other event that doesn’t sensibly fit any Place assignment, the best thing to do is to set a “custom title” on the visit. For example just last night I set an 8 minute visit’s custom title to “Stuck at the lights” (there’s one particular intersection near my place in Bangkok that has the worst lights timings, making taxi rides home a menace).

For this one, I think it’s technically possible that the recorded data has been “lost” in the timeline merging. Though I’m not sure on that… I’ve got the sense that I plugged all those holes in LocoKit2 / Arc Editor. It’s much more resilient to timeline errors than old LocoKit / Arc Timeline. But it’s possible there’s still some gaps I’ve missed.

The technical situation I’m thinking of is “orphaned samples”. Every recorded sample has a “parent” timeline item, eg a Visit item that is the parent to 200 Samples (represented the recorded moments in time during that Visit’s duration).

If somehow some samples get detached from their parent Visit/Trip item, and not reparented to another, they become orphans in the database. That’s one way they can get “lost”. But yeah, I’m not aware of any ways that can happen anymore in Arc Editor. And it’s also designed to actively identify orphans and “adopt” them into either suitable existing parent items, or create new parent items for them if necessary. So that seems… unlikely, but still maybe possible if I’ve missed something.

The other possible case is samples being actually deleted, when they’re inside long Visit items. Like, if the recording engine is recording new samples every 2 to 60 seconds, that bulks out the database massively and unnecessarily in things like overnight Home visits. We don’t need that data for anything - it’s just a waste of space. So the system periodically “prunes” (deletes) the samples inside Visits, when that data meets certain conditions.

The pruning algorithm always preserves the full samples from the first 30 minutes and last 30 minutes of visits. No pruning there - that stuff could be useful info about arriving or departing, or some smaller visit just before or just after.

It also preserves at least one sample for every I think 5 minutes of the visit. So that there should never be a gap in the data of more than 5 minutes inside a visit.

But what you describe sounds like not that case. It sounds like there’s samples missing for much longer than 5 minutes. So my hunch is that Editor simply didn’t record the data. It was either suspended or terminated, or iOS was being a dick and not delivering location data to it even though it was still alive (which does occasionally happen - iOS is sometimes uncool like that).

Of the latter issue, if I recall correctly initially might have accurately shown the drive, I was able to try to extract some visit, yet what would happen was it would briefly show up in the timeline, then auto disappear. I think that was the case and such happened multiple times. It’s been several days so memory is a bit vague. I’m not sure how it got from the state of if I remember, some ability to extract but I wasn’t able to, then later just a straight line that doesn’t represent the drive at all. I think that might be closer to what happened but forgot. Or am I confusing it with Timetime where it shows correctly but forgot if it was as such or I had to change it.

Overall, perhaps I’ll continue to try to fix other visits (unrelated to that) and re-import with a later beta or with release. Not sure. Since dual use with beta, some days are better in Editor so unsure if better to keep or reimport later.

I don’t know of it’s possible to import one day or some interval from Timeline which would then take the place of anything in Editor, without creating any problems. Home from previous evening to that day sometime might be around the same even if exact times not the same. But if it’s possible to just replace one days data with a backup.

All Visits improvements : looking forward to future use.

Yeah I’m asking myself this question with my own data too. Editor is usually doing a much better job than old Timeline. So I don’t really like the idea of later on doing a fresh import from Timeline into a new Editor install. The data I’m recording with Editor now is usually much better than the data in Timeline.

I think exporting by day might make the import process too fiddly. But perhaps one answer is to export selected items from Timeline and then import those into Editor, to fill in only identified item-sized gaps, or cases where Timeline managed to do it better.

For that I’ll have to get Editor capable of importing more export formats. Right now it can only import its own JSON export format, which is similar to Timeline’s but not close enough.

Building importers for all the different formats should be fairly trivial though. So it’s just a matter of time before I get that done. And with the AI coding assistants being so good these days, I can almost leave that kind of job entirely up to them! :grinning_face_with_smiling_eyes:

1 Like