TwinFan / LiveTraffic

LiveTraffic is an X-Plane multiplayer plugin, which fills your sky with live air traffic based on public flight tracking data.
https://twinfan.gitbook.io/livetraffic/
Other
99 stars 24 forks source link

Simulate missing altitude data. #171

Closed slgoldberg closed 4 years ago

slgoldberg commented 4 years ago

Current Situation / Problem Commonly, when aircraft owned by LiveTraffic are taking off, the GPS data is correct except the altitude data remains 0 (unpopulated) for a long time.

This continues quite often for a minute or two, well after the aircraft should actually be in the air.

The aircraft then often disappears from LiveTraffic and re-appears about 30-60 seconds later -- sometimes in the air at that point, sometimes still on the ground, but traveling at a high rate of speed.

I often observe aircraft (both G/A and commercial) "flying" at ground level presumably because of missing altitude data. I presume also that the aircraft "disappear" then "reappear" in LiveTraffic during this time because LiveTraffic determines they are invalid if the aircraft stays on the ground for too long. I think this could be handled better, and would lead to a substantially increased feeling of quality from what is otherwise (sometimes) stitched-together and spotty data.

Suggested Solution The same way LiveTraffic interpolates / "fits" the aircraft's position just above/on ground as "landing"/"rollout", a similar heuristic could be employed to simply "fake" the aircraft's vertical position above ground when the altitude is 0 but clearly should be more.

For example, one such heuristic could be: if the ground speed of the aircraft reaches a rate far in excess of taxi speed (perhaps sustained over a certain period of time), LiveTraffic could "fake" the altitude of the aircraft to be 1,500 to 2,000 feet AGL, so that instead of "flying" along the ground at 0 altitude, it is at least above-ground during that time.

Alternatives The flight phase, according to LTAPI, during the takeoff roll is, "take-off", during this entire time (usually) -- so perhaps the above heuristic could be restricted to "take-off" phase. However, there is obvious complexity around what to do after that; once in the air, you don't want it to pop back to the ground suddenly, and of course you infer the phase of flight based on the altitude. So, perhaps it's better to stay with just the raw heuristics of "sustained groundspeed", after some initial trigger based on flight phase.

A refinement of the heuristic take into consideration additional data if available such as ICAO classification of the aircraft (type/weight-class), and define "tiers" of ground-speeds (within each such classification) to infer altitude. E.g., a commercial jet going more than 150 knots but less than 250 knots may be considered as being at 5,000 feet; whereas a G/A single-engine aircraft or helicopter may stay under 1,500 feet the whole time. Etc. (Though this may be overkill since this only usually happens during a brief period after takeoff.)

Presumably there are other heuristics that could be applied of a similar nature, i.e. to avoid the problem of the aircraft staying at ground level when it shouldn't (not just after take-off, but this also seems to happen sometimes on taxi; the aircraft will end up in strange places -- but I believe these are a different issue re: the GPS data being invalid. But missing/incorrect lat/lon is not something I believe is worth trying to "fix".

Altitude, however, seems totally reasonable, since the alternative is the aircraft "flying" along the ground due to missing altitude data (whereas the GPS lat/lon data seem to be updating fine in these cases.)

Benefits This would avoid user confusion and possibly increase adoption of the plugin for more users. Even classic pilot training scenarios with TCAS would be more sensible in these cases, assuming the heuristic for altitude would be simple and understandable.

For example, users today might hear a "TRAFFIC... TRAFFIC..." warning from TCAS, only to see the traffic is on the ground below them (which shouldn't normally alert -- in fact, maybe it doesn't in this case?). Though if the aircraft below is moving at a high rate of speed, that can be very confusing.

With this change, the user would actually see the traffic at 1,500 feet (or whatever the heuristic decides), which is more likely the actual altitude since this mostly happens only during take-off accel phase.

Thanks for considering this (or something like it).

Steve

TwinFan commented 4 years ago

I'd rather fix the original issue (data inaccuracy goes unnoticed) than inventing an artificial flight when I don't know where the aircraft is headed to. I can do that during landing (auto land feature) because I know where the rwy is. I cannot do that during take off as I don't know the climb rate and if the plane ultimately goes straight, left, or right.

slgoldberg commented 4 years ago

Fair enough!

Steve

On Thu, Jul 9, 2020 at 1:42 AM TwinFan notifications@github.com wrote:

I'd rather fix the original issue (data inaccuracy goes unnoticed) than inventing an artificial flight when I don't know where the aircraft is headed to. I can do that during landing (auto land feature) because I know where the rwy is. I cannot do that during take off as I don't know if the plane goes straight, left, or right.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TwinFan/LiveTraffic/issues/171#issuecomment-655977026, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCJXL2DKC47IGUEKMCUIF3R2V3LZANCNFSM4K72RIAQ .