First off, thanks for providing this app — I’ve been on the search for an app to track my location data with the highest possible accuracy and Arc came highly recommended. The focus on privacy is just the cherry on top for me.
I’ve been testing it out the past week or so and have noticed a quirk with the GPX export that I wanted to get some clarity on.
Effectively what’s happening is that the GPX exports sometimes seem to have gaps / be split into multiple lines, even when the Arc app shows them as a single line.
Here’s an example from a GPX export viewed inside QGIS:
The points seem to be in the GPX, just not all connected up as tracks. Ideally I want to avoid having to write my own parser for the GPX / JSON data to display as a single line for a day’s activity.
Is there anything I can do to help diagnose what’s happening here and how to avoid it?
What you’re seeing there is the “individual segments” within the Path timeline items. If you tap into the details view for the item in Arc, then tap Edit → Edit individual segments, you’ll see them there.
Each recorded trip is made up of often a whole bunch of segments of different types, either due to real changes in activity type, or due to noise and classifier uncertainty. From the Individual Segments view you can clean them up, and that will also train the classifier / ML models to produce less noise of that kind in future recordings along that route.
Initially you’ll probably see a lot of short segments that have completely nonsense auto assigned types (eg bits of airplane while you’re stationary, or in a car). Those bits of nonsense are also more common in areas where there’s less Arc users, so the local “shared models” have less or no detail, and the classifier has a lot of uncertainty. But with little bits of cleanup you’ll see the amount of nonsense reduced significantly in new recordings.
Thanks for the clarification Matt, I’ll look into that specific day and see if I can tidy up the segments a bit. I think I did that after exporting the GPX originally but didn’t realise that it could improve a future GPX export of the same area.
Generally, I’m less interested in the segments or modes and am instead interested in an unbroken line of my raw activity over a day in a spatial data format. By the sounds of it, the raw recorded points should still be in the GPX and I should be able to join those points from the GPX (rather than using the tracks) to create something similar to what is visible in the Arc map (ie. nice unbroken lines over the day).
If you’re curious, I’m working on (amongst other spatial things) a fog map that shows you where you have (or haven’t!) explored yet by dropping a GeoJSON (will soon support GPX): https://fogmap.robinhawkes.com/
Ok so I had a deeper look at what’s going on in my Arc timelines in the situations where the GPX shows breaks in the tracks (technically it’s multiple tracks) — as you mentioned this seems to be related to the individual segments and things do improve once I correct the data (though quite a slog as the app kicks me back to the main timeline screen every so often).
In my case it seems to be that “stationary” segments are the main cause of a new track to start in the GPX. That sort of makes sense as I guess you aren’t moving if stationary, though you are still moving along a continuous journey (ie. you didn’t teleport, you just stopped for a moment) so it would be great to find a way to have GPX tracks that are continuous and unbroken.
Perhaps there’s a way to also include a single raw, unbroken track within the GPX export — similar to dumb GPS tracking from a Garmin watch or similar. I imagine there is a use for the multiple / split tracks per acticity, though for me that data would be better stored within point data (eg. rather that causing breaks in the continuous trace I took throughout the day).
Either way, it looks like there is enough raw point data in the GPX for me to do what I need even if I have to manually parse the data myself for now and reconstruct a single continuous trace without breaks.
In that case you’ll be able to get the results you want by not bothering with the Individual Segments view, and just doing a type confirmation on the main path Edit view. That will assign that single type to all samples in the Path (with the exception of any stationary segments that have very high classifier confidence as being stationary).
The Individual Segments view is useful for getting precise, and ensuring every sample and segment is exactly as you want it. But for your purposes, yeah, that’ll be overkill, and unnecessary extra effort.
That looks gorgeous! Very cool
This is more common in recordings where the classifier has low confidence, ie it lacks much ML model data (either of your own, or from the shared models based on other people’s confirms/corrects). The more confirming/correcting you do, the less likely you’ll see those scatters of stationary segments, due to your personal ML models being updated and becoming more accurate.
Though short stationary segments can also continue to be common in walking trips, especially if there’s buildings blocking GPS line of sight, thus leading to lower location data accuracy. Basically the worse the available location data accuracy, the less able the classifier is to distinguish reliably between slow movement and actual stationary. But yeah, confirming and correcting things will still help to reduce the frequency of those too.
If you’re comfortable with Swift code at all, you could try doing a small tweak to the export code in Arc Mini, and building and using on your phone that for GPX exports. Just hunting through the code now… it looks like it’s in GPX.swift. Down at the bottom, in add(_ path: ArcPath), you could have it iterate through path.samples instead of each segment then the samples in each segment.
The catch is, if you build Arc Mini yourself, it can’t share Arc App’s database, due to app container security. (Only an Arc Mini built by me, with my cert, can access and share the same App Group container. Bit of a hassle, but makes sense in app security terms).
Oh, which means that you’d end up with two separate databases, and each app recording in parallel, instead of one database, and the apps sharing the recording responsibility. So yeah, not ideal. But at least the underlying recording engine is extremely energy efficient, so having the two recording side by side has very little energy impact.
