FlightAware Discussions

BUG: "Filed" altitude for landed flights are not correct

If you look at landed flights, they will often have an incorrect “filed” altitude (e.g. 13,000 for a 777 that flew over the Atlantic).

I’m a controller in the U.S. and can see what the problem is and a way to fix it. There are three altitude fields in a NAS flight plan: proposed altitude (“filed altitude”) which only has a value before departure; “flight plan altitude” also known as “hard” altitude; and interim altitude which is the current assigned altitude if different than the hard altitude. However, some facilities by procedure change the hard altitude for arrivals (for example the controller has to put in a “hard” altitude of 13,000 before handing off to certain approach controls – this is so the approach control will get the flight data and the automated handoff will work). This is probably what’s happening above – you’re saving the last hard altitude after landing as the “filed.”

I’m guessing you’re only getting flight plan/hard altitude from the FAA data feed. To fix the issue, save out the flight plan altitude when you get the initial track on departure. That is the true “filed” altitude because the system copies over the proposed/filed altitude to the flight plan altitude when the aircraft departs. After it lands you then have the correct filed altitude instead of showing the last hard altitude which like above can be wrong.

A similar bug is with your airborne flights that are descending, for example it’ll show: (down arrow)16,900 feet (planned: 37,000 feet). The “planned” altitude there is going to be incorrect for an aircraft that is descending – that’s the last assigned hard altitude, not the current assigned interim altitude. To fix it, if an aircraft is descending I suggest you simply not show the “planned” altitude because it’s always going to be wrong anyway.

(On the other hand, if you ARE getting interim altitudes – the old HOST system didn’t send those but maybe ERAM is – you should always show that as the assigned altitude unless it’s blank or 0, in which case the assigned altitude would be the hard altitude).

Thanks for the heads up – we’ll look into this.

We’ve fixed this going forward.