I’ve been noticing a recurring issue with altitude readings in the Arc Editor beta.
In several car trips, the altitude graph shows completely unrealistic variations — in some cases hundreds or even tens of thousands of meters, despite the route being entirely flat.
For context:
The actual elevation of these routes is between 60 and 90 meters above sea level.
The iOS Compass app reports a stable and correct altitude during the same trips.
The problem appears intermittently, and it affects both short and long car trips.
Some technical background and context: Arc Editor’s recording engine, LocoKit2, uses a separate Kalman filter for altitude, separate from the more complex one used for latitude and longitude. The lat/lon Kalman filter takes into account the device’s reported “horizontal accuracy” but also the reported movement direction and velocity/speed. That allows lat/lon coordinates to be filtered often very cleanly, which is what gets Arc Editor’s paths looking typically much more accurate and sensible than other apps.
The altitude Kalman filter is simpler, not taking into account velocity or direction (those values aren’t available for altitude), but it does take into account the device’s reported “vertical accuracy”. So it is still intelligently filtering and correcting the raw data.
That will differ from what the Compass app typically shows. I’m pretty sure the Compass app just reports the raw values. Though that should mean that you see more incorrect values in the Compass app, rather than in Arc Editor. So that’s the first suspicious detail.
For whether the difference you’re seeing could be a bug in LocoKit2’s altitude Kalman filter, I’m thinking at this stage very unlikely. That filter is essentially the exact same one that worked reliably for many years in old LocoKit (in old Arc Timeline app). That one’s unchanged from the old system, while the new lat/lon Kalman filter in LocoKit2 is the newer and more advanced code. So what we’re seeing here is weirdness in a battle tested system, which suggests the problem is … likely somewhere else.
As to where that “somewhere else” is, I’m not surfacing any good guesses yet. You’re clearly seeing a repeated pattern though, so that makes it easier to debug at least. I think maybe next it’ll be valuable to grab screenshots of specific moments where what Arc is seeing/showing is diverging from what Compass app is showing. If you can grab screenshots of the two of them at the same moment in time, that’ll be revealing.
In Arc Editor there’s also the Debug view, from top left gear button on timeline view. That has the “Latest sample” section, which will show you the verticalAccuracy value. I think if you can capture screenshots of the altitude chart, Compass app, and that Debug view showing verticalAccuracy, all at a moment in time where there’s disagreement and also seemingly wrong altitude values in Arc, that’ll give us the most data to go on!
First of all thanks for the technical explanation, always interesting to understand how things work
I’ve run some more tests while driving to better understand the altitude issue.
During the car trip, both Arc Editor (Debug view) and the iOS Compass app were showing altitude values around 540–600 metres, while the real elevation of the area is around 50–70 metres above sea level (flat terrain).
This confirms that Arc is not generating the wrong altitude itself, but is instead receiving incorrect altitude data from iOS / CoreLocation.
In Arc’s Debug view, at the same moment, the values were for example:
altitude ≈ 588.9 m
verticalAccuracy ≈ 19 m
horizontalAccuracy ≈ 8–9 m
speed ≈ 15 km/h
As soon as I approach my home area (a place with well-known altitude ??), the values drop back to the correct range (≈ 60 m) and stay stable.
So it seems the incorrect altitude recordings are caused upstream — either GPS vertical inaccuracy in the car environment (possibly shielded windscreen) and/or barometer not being used or trusted during car movement — rather than a bug in Arc or LocoKit.
It also occurred to me that in the car I use now, something that in no other car I had ever noticed before in the years, the speed of the GPS navigator (both Waze or Google maps) fluctuates by a few km/h (4 or 6 depending on the speed) could be a further confirmation that the GPS of the iPhone in this car works badly.
Thanks, at least it served to think and understand how things work, it’s certainly not an Arc editor problem!
Hah! And there’s the second trap. Not only wildly incorrect altitude values reported by the phone, but it’s also reporting that those values are within ~19 metres of the real value. When in reality, as you say, the real values are more like 500 metres away.
That’s where the Kalman filter will fall down. It’s using those reported accuracy values to calibrate how much trust it should put into newly reported values.
Kalman filters function by making their own predictions of what the next value will be, then also looking at the reported input value from the phone, then deciding how much weight to put into each based on its own prediction’s expected accuracy and the phone’s reported accuracy. Ok I didn’t explain that very well, but basically the Kalman filter will be thinking something like “For my own prediction I think I’m within about 50 metres of the real value. But the phone is saying its value is within 20 metres of the real value. So I’ll lean the final result much more heavily towards what the phone is saying instead of my own prediction”.
When the phones are reporting sensible accuracy numbers, it all works spectacularly well, and the resulting path lines or altitude lines come out very sensible and pleasing. But if the phone starts reporting wildly wrong accuracy numbers… it all goes to shit.
So yeah, if the phone was reporting verticalAccuracy of a more realistic 500 metres then the Kalman filter would probably do great! But… it’s not. It’s reporting something wildly over confident, that throws all the maths off.
This is a general problem with GPS data unfortunately. It’s also the cause of the sometimes common drifting location data while stationary at home. The phone will be reporting lat,lon coordinates that drift potentially hundreds of metres away, and also be reporting horizontalAccuracy values of 50 metres or less (ie clearly wrong). So the lat,lon Kalman filter thinks “Ok I’d better trust what the phone is telling me then”, when really it shouldn’t be trusting that at all.
Those horizontalAccuracy / verticalAccuracy values end up being the real problem. Drifting location or altitude data is something a good Kalman filter can work around, as long as it’s being told not to trust it too much. But as soon as it’s told “this data is super trustworthy! for real bro!” … it’s all over.
Although there’s probably no way to fix it, the question there becomes “why?”. What’s going on that’s upsetting the GPS data when in that car. Is it something to do with the car? The route you’re driving, with surrounding buildings? Sometimes it could be a government thing, with GPS blocking around a sensitive location like an embassy or some such.
Though knowing why the GPS data is going fruity won’t be of any help. But it does satisfy that need to understand, instead of being stuck with “it goes weird, and I’ve got no idea why”. Heh.
Thanks Matt for the explanation – you described perfectly how the Kalman filter works, and it was really interesting to read.
I’ve noticed that the problem only happens in that specific car, regardless of the route. It’s easy to spot because the GPS speed keeps fluctuating by a few km/h. I also tried moving the phone to the windshield and different positions in the car, but it didn’t help. Very odd – my suspicion is that it might even be related to the rental company’s black box in the vehicle, but in any case it’s outside the scope of this forum.
What matters is that now I finally understand what’s happening between the raw data and the Kalman filter, so thanks again for that!
I’m also reading through the other discussions here – super interesting – but I couldn’t find if you have a roadmap for future betas or an idea of when a stable release of the app might come. Do you have any insight on that?
Kalman filters are super cool! They were initially invented for airplanes I think. Ah Wikipedia says they were first used in the Apollo space program! The ones used in Arc apps are much simpler though. Just complex enough to do the job well. Adding in velocity and direction really improves the results in Arc Editor’s lat,lon Kalman.
I’ve got a few pet test cases like this too. Boeing 787s are one - they absolutely destroy GPS/GNSS accuracy (while other Boeings and all Airbus planes cause no problems). Also high speed rail is a GPS menace. And also normal speed urban rail is an interesting one in the significant differences in accuracy depending on whether the train carriage is full or empty (my assumption is that humans bodies are fleshy GPS blockers).
But yeah, you’re right, we can’t really solve those problems. They’re just an intellectual fascination (and sometimes technical annoyance) at this stage. Actually solving those problems is largely out of our control.
I’m playing it by ear at this stage. Prioritising which features to add back in based on feedback here on the forum. But just this morning I had the thought “I’d better actually plan out an App Store release soon”.
I think Arc Editor is already the better app. It should be on the App Store by now, or at least very soon, because it’s just better than old Arc Timeline, even with the missing and incomplete features. So I’m going to start plotting out which parts have to be finished before I could sensibly put it on the store, then focus on those ones and also try to lay out some vague timeline for the App Store release.
I think there’s certain essentials like the search view, finishing up Places and Activity tabs, getting the Settings view to be an actual settings view instead of just the debug info view. Various core parts like that. The core timeline recording and editing is all rock solid at this point, so it’ll be a matter of tidying up house in the surrounding parts, so that it’s in a state that I can present to the App Store Review team and have them accept it for publishing, instead of rejecting it on “not a finished app” grounds.
I agree! As a new user, having lost all my data from more than 10 years of Google Timeline (when I switched to a new phone a month ago, I thought the full backup on iCloud would protect me), and being able to act lightly and having had some problems editing the timeline with Arc Timeline, I decided to use only Arc Editor for a few weeks! Obviously, some features are missing, but even so, I find it a better experience than Arc Timeline! With the new beta just released, I saw that workout import is integrated, which is very useful for me when I log a workout only with my Apple Watch without carrying my iPhone with me.
This gives flashbacks to when I lost my Moves app data many years back, in the early development days of Arc Timeline. The app got database corruption (which used to be scarily common in iPhone apps using SQLite back then) and lost everything. It was supposed to be backed up to Facebook’s servers, but when I tried to do the restore from there nothing came back at all. I think I lost about 5 years of data
Yeah I find going back to old Arc Timeline app a bit jarring now. It feels slower, more awkward, and I trust it far less. Arc Editor has definitely achieved the goal of being modern, clean, reliable, etc. And the data it records is noticeably better. It’s a really satisfying base to build on. Hopefully it’ll be good for another 10 years!
