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.
