Calling the API GET /flights/{ident} returns 2 responses for the same tail (flight registration) with different flightIDs.
Upon querying, have discovered that in some instances this is due to FA receiving 2 flight plans and in another case FA receiving 2 ‘actual_off’ times.
My query is this?
- If 2 flight plans are received should not the new overwrite the old/existing rather than creating 2 records?
- If 2 ‘actual_off’ times are received from the airline, should the record in FA be getting updated? Rather than creating 2 records.
- If >1 responses are received for the same flight registration, is their a mechanism to identify/select the latest record?
Thanks.
Flightplan messages are automatically merged by our HyperFeed engine, or treated as a flightplan amendment, as long as they are similar enough in terms of origin, destination, departure time, and arrival time. If you are seeing two flightplans (and two flight_ids) then there was enough differences to disqualify that behavior.
Be sure that you are not actually looking at flights with different days. For airlines with published schedules, we generally try to keep 2 days of upcoming flights populated in our system so you may actually be looking at upcoming flights with the same times but different days.
If you can be more specific about which ident you are looking at, we can further evaluate if there is a problem or not.
Thanks for coming back to me.
here are a few idents (we encountered duplicates)
G-ZBKB departed on 27/10/2023
G-EUUL departed on 29/10/2023
EC-IJN departed on 28/10/2023
In all of those examples, I can confirm that there were two flight_ids assigned but at least one of the two (sometimes both) were cancelled by our system such that only one of the two is the true flight_id that should be used to reference it.
This unfortunately sometimes happens when the flight is already entered in our system based on its published airline schedule, but we also detect it near departure time from another real-time data feed that has limited information about the aircraft. A second flight_id is allocated based on the limited information we had from the other data feed, but we eventually receive enough information that allows us to determine they represent the same flight. Our HyperFeed system then issues an “internal” cancellation for one of the two, with the intention that people use the other flight_id for tracking.
My recommendation is to also look at the cancellation field to be aware that there may be another instance of the flight that is not cancelled.
flight_id | ident | reg | origin | destination | filed_departuretime | actualdeparturetime | actualarrivaltime | cancellation | true_cancel
------------------------------------+--------+-------+--------+-------------+---------------------+---------------------+---------------------+----------------------------+-------------
BAW195-1698223579-schedule-1119p:0 | BAW195 | GZBKB | EGLL | KIAH | 2023-10-27 08:45:00 | | | 2023-10-26 22:44:10.446695 | t
BAW195-1698451738-airline-102p | BAW195 | GZBKB | EGLL | KIAH | 2023-10-27 08:45:00 | | | 2023-10-28 04:09:17 |
flight_id | ident | reg | origin | destination | filed_departuretime | actualdeparturetime | actualarrivaltime | cancellation | true_cancel
-------------------------------------+---------+-------+--------+-------------+---------------------+---------------------+---------------------+---------------------+-------------
BAW1486-1698421951-schedule-2086p:0 | BAW1486 | GEUUL | EGLL | EGPF | 2023-10-29 15:50:00 | | | 2023-10-29 16:45:27 |
BAW1488-1698426811-schedule-565p:0 | BAW1486 | GEUUL | EGLL | EGPF | 2023-10-29 17:20:00 | 2023-10-29 16:45:00 | 2023-10-29 17:37:00 | |
BAW1493-1698429810-schedule-1252p:0 | BAW1493 | GEUUL | EGPF | EGLL | 2023-10-29 18:10:00 | | | 2023-10-29 18:43:11 |
BAW1499-1698559684-ed-238p:0 | BAW1493 | GEUUL | EGPF | EGLL | 2023-10-29 18:48:26 | 2023-10-29 18:43:05 | 2023-10-29 19:51:46 | |
BAW1464-1698438609-schedule-1048p:0 | BAW1464 | GEUUL | EGLL | EGPH | 2023-10-29 20:30:00 | | | 2023-10-30 02:54:01 |
SHT8D-1698567784-ed-3456p:0 | BAW1464 | GEUUL | EGLL | EGPH | 2023-10-29 21:22:15 | 2023-10-29 21:17:16 | 2023-10-29 22:06:19 | |
flight_id | ident | reg | origin | destination | filed_departuretime | actualdeparturetime | actualarrivaltime | cancellation | true_cancel
-------------------------------------+---------+-------+--------+-------------+---------------------+---------------------+---------------------+---------------------+-------------
IBE3406-1698313946-schedule-1208p:0 | IBE3406 | ECIJN | LEMD | LFPO | 2023-10-28 09:45:00 | | | 2023-10-28 09:57:49 |
IBE3406-1698471348-ed-19p:0 | IBE3406 | ECIJN | LEMD | LFPO | 2023-10-28 09:57:44 | 2023-10-28 09:57:44 | 2023-10-28 11:32:38 | |
IBE3406-1698471348-ed-19p:0 | IBE3406 | ECIJN | LEMD | LEMD | 2023-10-28 09:57:44 | 2023-10-28 09:57:44 | | 2023-10-28 10:09:37 |
IBE3405-1698323665-schedule-163p:0 | IBE3405 | ECIJN | LFPO | LEMD | 2023-10-28 12:30:00 | 2023-10-28 13:05:33 | 2023-10-28 14:42:39 | |
Happy New Year!
I am using the following API to get data (as these are historic flights) https://aeroapi.flightaware.com/aeroapi/history/flights
Calling this API for GZBKB for 2023-10-27, still returns 2 records with the exact same flight ID’s you referenced above, but both have the cancelled flag set to true.
For registration, ECIJN, on 2023-10-28, for flight id’s ending with 1208p and 19p (Origin LEMD, dest LFPO), again using the API mentioned above I receive 2 records with both set to true (as cancelled)
The first tail on your query has one record as cancelled (1119P but the other 102P not, using the API both return as cancelled, which is confusing
For the second, the query results you posted above, has all records as not cancelled
If the HyperFeed system is issuing a cancellation on of the two records, this does not seem to be case for the above records.
Apologies, something else I just noticed, on your query results there is a field ‘cancellation’ with a datetime stamp of when the record was cancelled. This is not visible via the API,
