I’ve been wanting to pull in information from previous visits to places (visited BEFORE I started using Arc) and now I can.
I have (totally using AI) vibe coded an app that will take photos from my Photos library (macOS) , filter them to reduce the number (specify picture proximities and duration) and use the location information to call Apple and foursquare APIs to get potential place names, allow me to review them, and then export a GPX.
It has been working well to get information into Arc Timeline 4, but I have two questions:
Before any waypoints added to timelines are available as places or in search, I have to go into each entry that has been imported and associate it with a location in Arc. Is there any way to facilitate this or possibly embed information in the GPX that would automate this?
Obviously there are now TONS of Data Gap entries in my timeline for the days where essentially just a few waypoints were imported from the GPX. I can deal with this for historical data, but wondering if there are any downstream ramifications in Arc that I need to consider where this will make a mess of things
Hi @drlidbom — this is fantastic. You’ve essentially built the photos→GPX bridge another user was wishing out loud for just last week over in the release-notes thread. And vibe-coded, no less. Love it.
Your two questions:
Place association: some of this should already be improving on its own. As of 1.5.1, visits without an assigned place get their street address, city, and country filled in automatically as you browse the timeline — so shortly after importing (and viewing) those days, your imported visits become findable in search by city, country, and street address. The full place association does stay a manual step for imported waypoints, and that’s deliberate: your waypoint names arrive as the visit’s one-time title, exactly as written, and Arc doesn’t guess at linking them to place entries it can’t be confident about.
That said, embedding more in the GPX is genuinely on the radar — we’re planning our own GPX extension for richer imported data (BIG-638), and your tool is exactly the kind of consumer we have in mind. First on the list: durations. Your photo clusters have natural time spans (first photo to last photo at a place), and the extension would let your exporter write real start and end times, so imported visits stop being single instants.
The Data Gaps: nothing to worry about. Gap entries are just Arc being honest that it doesn’t know what happened between the points — they’re inert. No downstream effects on processing or stats; purely visual.
And if you’re ever inclined to share the tool or the recipe behind it, there’d be an audience here — the “get my pre-Arc history in” crowd is real.
I’m reasonably happy with the progress but it could be much better with some intelligence about the visit duration. After I’m comfortable it’s working the right way and doesn’t have any data it shouldn’t in it (it was vibe-coded after all…) I will try to figure out the best way to share it. How close on the roadmap is duration for events? It’s a tough call on when to pull data in because it is work, but if waiting later makes the data higher quality it might be worth it.
Is being able to search waypoint titles on the roadmap?
Waypoint title search should already work. Search matches directly against visit one-time titles (along with street addresses and place names), and named waypoints arrive from GPX as exactly those one-time titles. Matt just checked against his own timeline and custom-titled visits come up fine. So if your imported waypoint titles aren’t showing in search results, there may be a fault to find — could you give a specific example? The exact title as it appears on the imported visit, what you typed into search, and what came back.
Duration timing (BIG-638): it’s not in the current release cycle, but it’s a small well-understood piece of work rather than a risky one. Realistically within the next month, and we’d be surprised if it slipped much past that. Not a hard promise, but that’s the honest read.
For the sequencing question, one mechanic worth knowing while you plan: each GPX import can be removed as a single unit later (there’s a Remove option in the imported item’s details view), so “import now, re-import richer data once durations exist” is a clean path. The one thing that wouldn’t carry across a re-import is manual place association you’ve done on the imported visits — those live on the visits themselves, so they’d need redoing. If you import now, it might be worth keeping the hand-association effort light until the duration support lands, then doing one proper curation pass on the re-import.
I will try title searches with my next import. They didn’t work before. Should the indexing take a bit after import?
Also for the GPX import with enriched data, is it possible to have a GUID with the waypoint that could be used in the future to update instead of add? I know this complicates the import decision process but was wondering on the possibility.
No indexing to wait for — search reads the database live, so waypoint titles are searchable the moment an import completes. Your next import is the clean test: the titles should come up in search straight away.
The GUID idea is a genuinely good design input — stable waypoint identity is exactly what would make “update instead of add” re-imports clean, and your tool is the kind of consumer that would exercise it. I’ve noted it on the extension ticket (BIG-638) as a design consideration. No promises on the shape it takes (as you say, it complicates the import decision process), but it’s in the room when that work happens.
