Describe the bug
Most often seen with OpenSky data, but at times also with ADSBEx data: Planes come in at wrong altitude and miss the runway threshold. Or on take off leave the runway too early or late.
(There is a safeguard by now that tries keeping a plane above 2.5° glidescope, which works if the runway was determined correctly, read: not always.)
Reason is that the geomtric altitude given in tracking data seems to be rather unreliable. It has been seen that even in one set of responses the conversion from baroemtric to geometric altitude seems to differ between planes.
Just saw a number of long landings at EDDF while having normal pressure (1013hPa, EDDF 140850Z 31009KT 260V350 9999 FEW027 SCT041 21/14 Q1013 NOSIG). The caught raw network data shows that the geomtric altitude in the OpenSky data is way off. With normal pressure it should be more or less identical to the barometric altitude:
Marked in bold are the two altitudes: barometric at position 7 and geometric at position 12. Althrough pressure is 1013hPa the geomtric altitude is always significantly higher than the barometric one. At that's why planes come in high.
To Reproduce
Well...it happens...so far I would have said "go to a high-pressure airport and watch landings", but the above EDDF example is even more simple to understand. And that was just luck.
Expected behavior
Planes should be at correct real-world altitude and land more or less on the threshold.
Solution Approach
Use the barometric altitude and convert internally. This is already needed for RealTraffic data, but RealTraffic delivers current weather on a secondary stream.
For the same to work without RealTraffic, LiveTraffic has to query current real-life weather data. They are available, though, for example from AWC.
Describe the bug Most often seen with OpenSky data, but at times also with ADSBEx data: Planes come in at wrong altitude and miss the runway threshold. Or on take off leave the runway too early or late.
(There is a safeguard by now that tries keeping a plane above 2.5° glidescope, which works if the runway was determined correctly, read: not always.)
Reason is that the geomtric altitude given in tracking data seems to be rather unreliable. It has been seen that even in one set of responses the conversion from baroemtric to geometric altitude seems to differ between planes.
Just saw a number of long landings at EDDF while having normal pressure (1013hPa,
EDDF 140850Z 31009KT 260V350 9999 FEW027 SCT041 21/14 Q1013 NOSIG). The caught raw network data shows that the geomtric altitude in the OpenSky data is way off. With normal pressure it should be more or less identical to the barometric altitude:["3c65cd","DLH04K ","Germany",1592126950,1592126950,8.8512,50.1013,1188.72,false,113.01,262.94,-5.85,null,1264.92,"1000",false,0] ["3c65cb","DLH8XC ","Germany",1592126949,1592126949,8.722,50.0724,670.56,false,96.64,252.34,-5.2,null,739.14,"1000",false,0] ["c0293e","ACA7210 ","Canada",1592126949,1592126949,8.6162,50.2271,2186.94,false,129.01,71.64,-8.13,null,2301.24,"2242",false,0]
Marked in bold are the two altitudes: barometric at position 7 and geometric at position 12. Althrough pressure is 1013hPa the geomtric altitude is always significantly higher than the barometric one. At that's why planes come in high.
To Reproduce Well...it happens...so far I would have said "go to a high-pressure airport and watch landings", but the above EDDF example is even more simple to understand. And that was just luck.
Expected behavior Planes should be at correct real-world altitude and land more or less on the threshold.
Solution Approach Use the barometric altitude and convert internally. This is already needed for RealTraffic data, but RealTraffic delivers current weather on a secondary stream. For the same to work without RealTraffic, LiveTraffic has to query current real-life weather data. They are available, though, for example from AWC.
Technical Info:
LTRawFD.log LTRawFD.log