Altitude in the trip record during flight mode is displayed with a delay

[Zirochkabila]

Description

For a long time, the altitude in Trip Recording during the flight mode is shown wrong when using the OsmAnd in an airplane. The speed is correct, and the location either, but the altitude increases/decreases with huge time delays, tens of minutes. For example, showing 200 m when the airplane has already riched an altitude of 4000 m.

Displayed altitude is not always incorrect, but systematically (=always) shows an essential delay in a calculated value. That means during the airplane take off the OsmAnd shows delayed numbers with a huge error (for example, displays 200 m when the airplane is already rich 3000 m). After the airplane arrived at cruising altitude, the OsmAnd saturates to real altitude and keeps the correct value until the airplane starts descending. The time delay for the correct altitude is around 10-30 minutes, but the user doesn’t see a linear dependence of this effect.

logcat.log
GPX.zip

Actual result

Attached are 4 screenshots of the altitude profile for the flight from Frankfurt to Philadelphia, 2 of them are from Flightradar24 (clearly seen descending behavior up to 200 m), and 2 from my cell phone OsmAnd app (when landing in Philadelphia, the altitude is still 2400 m)

Altitude.issue.mp4

Expected result

OsmAnd displays timely altitude data - without delay

Your Environment

OsmAnd Version: 4.3.12 released 2023-02-17
Android/iOS version: Android 10

[zipav]

Our user did a test of altitude issue with a new 4.4.6 beta version of the app. The results are as follows: the problem with calculation of correct altitude is essentially eliminated, however, not completely. Now the altitude on the take off is calculated with a smaller time delay: approx. 1-2 minutes against tens of minutes in previous version. See the screenshot with calculated 168m altitude when airplane already gained around kilometer height. On the descent, the calculation of altitude was either with a short delay, see screenshots from app with 12.300 m against internal airplane monitor with 11.900 m. In attach the log of the whole flight and logcat.
logcat (8).log
2023-04-02_10-22_SEA-OGG (1).zip

[sonora]

Quite possibly the entire story is due to an issue with rhe google location API, can the user maybe test our setting "Android API". Different phones use different mechanisms to filter or smooth this data, but quite possibly changing between the 2 location APIs can bring a decisive difference.

[Zirochkabila]

User does not use the Android API because Flight Mode is activated during the flight and there is no network connection

[sonora]

The Android location API works in airplane mode, does not necessitate you being online at all.

And in my experience it is a lot closer to "reality" than what google does in terms of post-processing the GPS chipset data, which on occasion has caused all sorts of artifacts (we have several issues about it, #10864 being just one of them).