My application makes lots of calls to FXML3’s AirportBoards; I’m concerned that I’m occasionally missing updates on flights because they arrive or depart between API calls.
I constrain API calls by time, for example, grabbing “flights arriving in next x minutes,” which I do by fetching results 15 at a time, looking at the last result, and grabbing more if that result is arriving in < x minutes until I hit x… which is done so I don’t pay for more data than I need.
One solution I thought of was providing an alternate constraint parameter of “howLong” in seconds (or minutes?), which could constrain scheduled/future results going out x seconds, and past/arrival results going back x seconds. That way flights aren’t going to get missed if they happen to arrive/depart between API calls.
… otherwise, is there an alternate approach to making sure you don’t pay for more than you need, but don’t occasionally skip over a flight?
Now that it’s been two weeks, would anyone from FlightAware like to chime in here?
@dogrock, @bovineone, @cbw … anyone? Could someone please respond to this?
This sounds like something that could be handled in the future planned geospacial queries functionality. In XML v2 the SearchBirdseyeInflight endpoint allows for searches by estimated arrival time and destination airport. Does something like the query below match up to what you’re trying to achieve?
https://flightxml.flightaware.com/json/FlightXML2/SearchBirdseyeInFlight?query={< arrivalTimeEstimated 1566921600} {= dest KLAX} {true inAir}
Otherwise it may be useful to keep some general metrics on how far you need to page back in the results for a given airport so that the howMany can be scaled to get a closer approximation of all the desired results in the first web request. It isn’t a perfect solution, but it should reduce the probability of a flight being missed between en route requests by reducing the number of web requests made.
1 Like
That sounds interesting - would have to look at query pricing on the geospatial stuff - was quite a bit more expensive than AirportBoards last I looked.
Metrics on expected demand per request based on day/time is an interesting idea - I might explore that a bit. I try to reduce overhead by only requesting the data I need in those requests (usually I need lots of data for future arrival/departures and less on flights that have already arrived/departed), but I suppose I can reduce my overhead by just ignoring the incoming data on the flights I don’t need - would increase overhead on your end though (for example, sometimes I need 18 hours of future arrivals/departures at LAX, but I don’t need the 18 hours of past arrivals/departures).
I need to do some more digging, but, I suspect lots of the flights that stop getting updates in my system are a result of the [ arrival time ] == [ departure time ] convention that you guys are using - any progress on that front? It was discussed here: AirportBoards FlightXML3 Missing Flight after Arrival.
The [ arrival time ] == [ departure time ] convention related to XML3 airport boards and unintentionally suppressing FRU flights is currently a prioritized task. However, I don’t have an estimation for when a change would be made.
