Not sure if arrival time == departure time (discussed here and here has been resolved yet, but, was thinking about it recently and had a couple of other suggestions along similar lines…
It’d be nice if there was a flag we could provide in our query to FXML3’s AirportBoards that would include flights that previous queries for an airport would have picked up, but have since gone away, for cases where the plans just drop out of the system, the unconfirmed arrivals (as mentioned at top of this post), flights that divert to another airport, etc.
For example, if a flight plan drops out of the system, add ability to keep it in the results but set the status indicator to dropped. If a flight diverts to another airport, keep it in the results set, but indicate it’s diverted… otherwise we need to do additional queries on flights that have stale data, and pinging each one against the API can get pretty expensive, especially if monitoring a large number of airports - it’s an impractical solution.
Also - not sure if it’s supported by data, but I’ve been noticing more duplicate flights lately, where AirportBoards or push alerts are coming through with different FA flight IDs for the same flights - it’d be cool if there was an added field you could include when/if your system catches the flights as duplicates that would just be a set of FA flight IDs for other flights that ended up being the same. I can do a fair amount of duplicate detection on my end, but, it’d be nice if there was so help coming from your end too.
For the cases concerning the FRU status some updates were made specifically to how the boards arrivals list is generated so an estimated arrival doesn’t unintentionally hide the flight in the recent arrivals list.
Currently in the case of diversions the original flight plan is considered cancelled as well as being marked diverted. This state makes it ineligible to appear in airport boards. However, the diverted (new) flight plan will appear in a boards query. Holding the old plan may prove challenging since its state doesn’t fit into any of the boards states and will no longer receive updates and exist as a stale entry in boards. Would an ideal scenario have the old flight entry remain in enroute for some amount of time?
Do you have some examples of a few recent duplicate flight entries? This is to see if a root cause can be found. Ideally we should be catching these before they are even visible in FlightXML.
Yeah, and that behavior totally makes sense from your system’s perspective, but on my end, I’m caching each flight from AirportBoards, it’s very problematic; once one of those flights becomes “ineligible” for inclusion from AirportBoards queries, the data just gets stale on my end.
As I said in my previous comment, I think a good solution might be adding an input parameter like include_expired_data to the AirportBoards API, which defaults to false, but when set as true, could be used to provide information on flights that otherwise have become ineligible for display on the boards.
In cases where a diversion happens, that might also be a good opportunity to for the “duplicateFaFlightIDs” field idea, to tie the two records together, so they can get reconciled on my system’s end.
I’ll provide a few of these as time allows, thank you!
A few duplicates for your filtering pleasure; I’ve got some code that detects them as they get displayed on my site, I’ll see if I can update the code so I can keep a log of detected duplicates, as that might be helpful on your end. Thanks!
SWA4946-1579996114-3-11-29 and SWA4946-1579758374-airline-0014
BAW219-1579931139-airline-0265 and BAW219V-1580107178-ed-0008
AAL178-1579931137-airline-0188 and AAL178-1580160179-10-0-200
AAL2367-1579931137-airline-0580 and AAL2367-1580138176-5-0-230
Thanks for those examples. There seems to be something unexpected happening with the delay handling for the flights (SWA and AAL) that were operating entirely within US airspace. I’ve passed the details on to the flight tracking team.
@dogrock Here’s another set of FA Flight IDs my software tagged as duplicates; I tried to get a good mix of different cases… apologies in advance to the devs who get to comb through this. Again, I don’t need follow-up on any of these specific cases, just providing examples as requested to improve the service going forward. Cheers!
@dogrock - any idea if my “include_expired_data” tag is something that could be considered/implemented in the near-ish future? I’ve got a client it’d be very helpful for, otherwise I need to look at doing follow-up queries on a flight-by-flight basis.
We’re considering it, but we don’t have a timeline. In general the Boards functions only consider non-cancelled flights, but the original plan of a diverted flight is considered cancelled. Changing that baseline concept is likely to have a bit of unforeseen challenge. I’d recommend not waiting on a near-ish future change.
That’s a pretty major oversight - I appreciate the technical challenge it might pose on your end, but this sort of information is what airport boards are for.
What’s the proposed workflow for having a functional real-world airport board if your AirportBoard doesn’t do it? Review all of the flights we have cached information for, if no recent update came via a recent AirportBoards call, query FlightInfoStatus with the faFlightID? When we do that and status is diverted, will it return the new destination, or will that require an additional query too?
If a faFlightId represents a diverted flight FlightInfoStatus will return the new version of the flight first followed by the originally planned flight in the same response. FlightInfoStatus can be used to check on the unexpected absence of a flight in boards.
