API vs Website

Martinair is a cargo operator, which in general will have lower tracking accuracy as cargo operators do not generally have the need/desire to transmit their FLIFO data to us through the same systems that passenger airlines do. Additionally, that flight is operating outside of our primary coverage areas, so we are unable to receive full ATC data for that flight. Furthermore, portions of that flight operated outside of our positional coverage areas, which means that some portions of the flight we were estimating/projecting its current position based on last known information.

That specific flight appears to have performed a diversion from its originally scheduled destination (FAOR) to a different destination (HKJK), however we did not receive that flightplan change notification through any of our public data sources. We were instead only able to synthetically determine it had diverted after detecting its arrival at HKJK. Because of that, FlightXML would likely have continued to indicate it was travelling to its original destination until its arrival at its destination.

When diversions are detected to have occurred, FlightXML will typically return two (or perhaps more) flight records for the same faFlightID with one record containing the original destination and the other record containing the new destination. Your application logic may or may not have been prepared to encounter multiple records for the same flight.

Although we do have published flight schedules for that Martinair flight, that is slightly unusual since it is a cargo operator and typically only passenger airlines publish flight schedules to us in that manner. It’s not entirely clear whether that Martinair flight was always intended to make an intermediate stop at HKJK before landing at FAOR (that seems to be a common occurrence with that particular flight’s history), so it’s possible that their published flight schedule is simply inaccurate.

1 Like