FlightXML2 SetAlert Airline Code Remap Bug/Feature

FlightAware AeroAPI
1

We built an API that supports entering of Alerts via the FlightXML2/SetAlert interface. It’s been up and running for about a year but the return from the FlightAware API has at least two interesting features. The main criticism is that if we submit a specific flight we would like to Alert on using Airline Code/Tail Number such as ASA55 (Alaska Airlines 55) for the ident value there appears to be a “Best Match” algorithm set up on the FlightAware end that sets our alert but sometimes pairs it with an Airline we are not interested in. This is similar to how the UI works I believe, but from the coding side of things this is not always the desired result. I think it is there in the FlightAware UI to handle the “operated by” type flights were the user may be unaware of how the flight is entered in the database. This seems to specificallly occur on our end where there has been mass mergers / rebranding of airline names and the data being submitted by operators to FAA may be mixed up to start with. In our world in Alaska the larger regional airline known as ERA (ERR) but historically based on Frontier Flying Service (FTA) with subsidiaries of Hageland Aviation Services (HAG) are now operated as Ravn (RVF).

For instance today March 30th 2015 we would like to set an alert on RVF807 for an ident code. We submit it to the API - but the Alert that comes back is set for an ident of ERR807. Both these flights are in the FlightAware UI - but ERR807 (the old name) has nothing scheduled for the future and nothing listed in the last few months.

In another strange but specific case setting up an alert for RVF823 remaps the alert to watch for ERH823 - but ERH is ERA Helicopters which has long been a separate company from ERA Alaska. Both these flights exist in UI, but SetAlert interface always sets to ERH823.

Please consider giving the API an “override” feature so that we can setup an alert on a specific ident - WITHOUT having the flight remapped. We propose that the UI can be studied by user to figure out what flight they really want to alert on is.

The other problem we have with the API is that if we are trying to set an alert near the end of the day for a flight later in the evening local time and UTC time is already on the next day we can’t seem to sneak in the flight via the API - we generally end up with the API “rolling” the alert to the next day. This may be an understanding problem with what the time basis is of the API but we have sort of learned to try to set all our alerts for the day before UTC time as rolled into the next day. For instance in Alaska we are currently 8 hours behind UTC time. As long as via the API we setup alerts for undeparted flights leaving today (local epoch time) before 4pm local time we can get an alert back for our current day. However if we try to setup an alert for a flight leaving at 8pm AFTER 4pm local time we can only get the alert to respond to the flight the next day. Does this sound familiar?

M

2

Are you always creating alerts using the ICAO airline identifiers, and not IATA airline identifiers? (Your examples that you cite happen to be all ICAO.) We’ve seen confusion when the ambiguous IATA codes are specified. However, there are codeshare translations that are sometimes necessary when one airline (or regional carrier) is operating flights under a mainline airline’s identity, so we need to auto-correct the alert to ensure that it will match the ident that we expect will actually be used for the flight. It’s possible that some of those translations are not working properly, so we’ll investigate.

As for the second half of your question, the date_start should be the epoch seconds of the departure date, represented in the local timezone of the departure airport.

3

bovineone,

Just to clarify we do use ICAO airline identifiers - see those reference flights I gave you. I believe part of the problem is an outdated codeshare translation table - please cleanup if possible for all obsolete references to “ERH” and “ERR” - “RVF” should be the operator. FlightAware is essentially “doubling” the flights on the tracking page - future scheduled flights say “ERH” but you can see their actual past tracks under “RVF”.

I still maintain these two basic problems with the API:

The API as well as UI will switch alerts based on your internal codeshare rules - and I believe that one should be able to override this in the API version of the SetAlert interface. That is if the flight can be found in your database - which is the frustrating case I mention. There’s even an argument that maybe we should be able to set alerts on flights not-yet existing in FAA data as being charter operators we often know what flight numbers/tail numbers will be long before they are filed with the FAA and disseminated via ASDI.

The second problem is trying to use the API/UI SetAlert interface late in the day when UTC time is already in the next day. The API will literally return an error: INVALID: invalid {date_start} if one tries to put in a time earlier than local time so typically we use local epoch time as the date_start argument. Consider this flight: ASA102 PANC->KSEA - generally the flight leaves PANC at 18:00 Local (Alaska) Time which is 02:00 UTC time the next day. If it is after 16:00 Alaska time this Alert can be entered via API but it will be rolled to the next day. In this particular case one can go into the UI, modify the date to be the current date and the UI will take it - which is interesting!. Note that there may be some bearing on this depending on API Account timezone setup - we have ours set to Alaska (UTC - 8) to keep time references on Alerts we receive consistent.

Please investigate.