I’m on the fence with this one.

I’m very much not keen on Arc stepping into the realm of creating location data, and would rather keep it relying purely on location data that the phone provides.

But there is already the “bogus location data” feature, for removing / flagging location data that the phone got very wrong. So it perhaps makes sense to have an option to nudge/correct location data that was close, but not close enough.

But at what level that happens, and how it gets done both technically and in the UI, I’m uncertain. So I’ll have to come back to this one after more thought.

That’s exactly the point, as bogus is not at all solving my issues. I need the places to right (that’s how my head works) else I might as well just leave it. As said Arc is my memory book, so I need it to be rather correct to the extent possible.

While the bogus feature is a must have, marking individual segments as bogus is pretty tedious. Maybe Arc could be more agressive in normalising obvious glitches in gps data - I have almost daily random jumps to a couple of km of my actual location and back for whatever reason.

Sander, Arc is already running location data through several layers of filtering and smoothing. It first applies Kalman filters to the raw location data (Kalman filters are what’s used in aviation and aerospace). Then it applies dynamic smoothing, to reduce large jumps depending on reported location accuracy.

Basically Arc (or rather LocoKit, the recording engine) is doing everything possible to clean out bad data. The glitches that remain are not “obvious” to a computer, because the computer has already applied industry best filtering techniques at that point, so what remains is the glitches that are convincingly enough presented that they can fool the best algorithms.

If you are getting daily long distance glitches, then unfortunately your phone will be “sleepwalking”. By that I mean that the phone is reporting that that location data is much more accurate than it is. Every raw location that the phone reports is accompanied by an “accuracy” number, measured in metres. For example it might say that it thinks the reported location is within 30 metres of the real location. When the phone is “sleepwalking” it is providing locations that are, for example, 300 metres away from the real location, but the reported accuracy is 30 metres. In that case there is very little that can be done, because essentially the phone is lying about the data it is providing.

That is where the “bogus location data” feature comes in. By manually marking those segments as bogus, Arc’s Machine Learning can learn to identify the times and places where your phone is liable to sleepwalk.

Just thinking more on this one: If this kind of sample coordinate nudging feature were provided, it would allow Arc / LocoKit to build a nudges map, based on common nudge directions at given coordinates.

This nudges map could then be used to either feed back into the Kalman filter, or be applied at a higher level, with automatic nudge adjustments to the pre filtered/smoothed samples.

I can’t see this being a high priority feature. But it would be a very cool one, for the data correctness obsessives amongst us (which includes myself!)

What about for when you visit a place, but it’s only for a couple minutes, which is rarely enough time for Arc to register as a place visit, and instead computes it as part of the travel path (car in my case).

Just today I visited two places (one even getting out of my vehicle to walk inside for 2-3 minutes), but Arc shows only the route, not the actual visit, and there appears to be no way to manually change/input the visit (tried through the segment edit).

@John, for those cases, go into the “Recorded Activities” view (or “Individual Segments” view, in Arc 3.0), for the trip item.

From there you should be able to find the stationary segment that represents the visit, then you can manually assign a place to it.

Once it has a manually assigned place, it is marked as “worth keeping”, and will stay in the timeline as a visit.

Visits without manually assigned places must be at least 2 minutes long to reach “keeper” status, so instead they will be merged into the surrounding trip items. But once you’ve assigned a manual place to the stationary segment, it will stay in the timeline.

Might using Swarm/4SQ checkins (as already suggested on its own here) be able to serve as a workaround for this? With e. g. optionally (4sq locations are bogus at times) using the location data provided by 4sq to override the recorded position.

Foursquare / Swarm location data tends to be lower accuracy than Arc data.

Arc’s location recording makes use of multiple layers of noise filtering and error correction. Arc also records location data in a continuous stream, at the highest sampling frequency and accuracy level that the phone is capable of under current conditions. So as a general rule of thumb, Arc’s location data will be more accurate and detailed than anything else’s.

The one case where another app could have better location data than Arc is if Arc wasn’t running at the time - ie there was a data gap, due to Arc being terminated and not yet relaunched.

+1, because Arc app cannot collect correct data when I’m in subway (Metro) and/or underground malls.

Arc app ONLY records when and where I’m into/out of underground. App cannot record how long I wait for subway, and how long I walk in transfer station (or underground mall) because GPS waves don’t reach underground. iOS map says “Cannot determine location”, or points inaccurate position with big acuuracy circle (~2.5kilometer); and, Arc app records ‘Stationary’ (sometimes ‘Unknown’ or lost data), although I’m walking around in subway station, or I’m already on subway.

Trains, includes subways, usually operate on time in Japan - so I can guess ‘correct’ boarding time and get-off time. ‘Split a segment’ ( https://changemap.co/bigpaua/arc-app/task/3205-split-a-segment/ ) may resolve this problem for boarding station and getting-off station records. However, because location data is not recorded (or is recorded inaccurately - typically recorded ‘Stationary’ at underground entry point), I cannot add action records in subway transfer station even if I can split a segment. That’s why I want to adjust positions manually; if splitted record has no location data, ‘Add (missing) position’ ( https://changemap.co/bigpaua/arc-app/task/3209-add-missing-position/ ) may able to fix this problem.

And also, tracking line may incorrect - not ‘underground entry point’ to ‘exit to ground point’ straight line, lines fitting to railway. That’s another problem.

Any chance for a snap to road feature? Or snap to train

Tim, it’s on my todo list to add road and train line awareness to LocoKit’s recording engine.

I won’t implement complete snapping to lines, because that tends to produce lies more than it produces truth. But once the recording engine is aware of where the roads and train lines are supposed to be, it can incorporate that into its filtering and smoothing algorithms, to either partially or completely correct the paths.

Cars are a good example of why you don’t want 100% snapping to roads. You might take a shortcut on an alley that isn’t on the map, or you might have to drive across to the other side of the road, or through a parking area off the road, to detour around some roadworks or an accident. With 100% snapping to roads, the snapping would invalidate those detours and deviations, and produce false data. But with road location awareness being taken into account in the filtering and smoothing, the incoming raw data can be interpreted intelligently to keep the paths more sensibly on the road when appropriate, but to not interfere with deviations and detours that disagree with the map data.

In the case of trains, 100% snapping to the train line would probably be best. So when it comes time to implement this functionality, I’ll almost certainly the snapping’s input weighted per activity type, and heavily weighted for train data.

Oh, Tim, it’s probably worth submitting “Snap to roads” as a separate feature request! The more people voting for that specific functionality, the sooner I can justify getting started on it 😄

I have another case (related to Satoshi Yamadas description) in which the requested feature would be very practical. I often drive around in Switzerland (a lot of tunnels/mountains), so sometimes there is no gps signal which leads to straight lines across mountains/lakes/forests… Arc recognizes the whole ride correctly as a car ride, but if i now want to remove the bogus data i either way have to delete the whole track including all the correct data (since it all is saved as one car ride) or just live with the bogus data. It wold be awesome if there was a way to clean out these wrong parts of the track, either by deleting a segment of the track or by adjusting some data points to fit the actual ride better.

Would not be there any possibility to switch to accelerometer readings if the GPS signal drops out?

Sascha, accelerometer data is already being recorded and used for activity type classification.

Months later, but i totally agree with this!

Dani, if you are seeing location data off by large distances, then I recommend contacting me directly from the “Feedback & Support” button inside the app.

Arc is already doing everything that mathematically can be done about bad location data. There are not more opportunities for optimisation or improvement in this area. If your phone is regularly producing extremely incorrect location data, then it will be necessary to look at other aspects of your phone and environment, in order to improve the quality of the data.

Hi Matt. Thank you. I have just emailed you through the app.