AirportBoards duplicating flights in same response

Hi

Per this JSON the scheduled flights board contained the same flight twice - below as a fragment the flight CPZ5805 appears twice (with different faFlightID’s) :

									"ident": "CPZ5805",
				"faFlightID": "CPZ5805-1543271337-2-0-115",
				"airline": "CPZ",
				"airline_iata": "CP",
				"flightnumber": "5805",
				"type": "Form_Airline",
				"codeshares": "AMX3110,VOZ6619,WJA7021,CAL9020,CES4186,WJA7017,KAL7470,AMX3936",
				"blocked": false,
				"diverted": false,
				"cancelled": false,
				"origin": {
					"code": "KSMF",
					"city": "Sacramento, CA",
					"alternate_ident": "",
					"airport_name": "Sacramento Intl"
				},
				"destination": {
					"code": "KLAX",
					"city": "Los Angeles, CA",
					"alternate_ident": "",
					"airport_name": "Los Angeles Intl"
				},
				"filed_ete": 3540,
				"filed_airspeed_kts": 328,
				"distance_filed": 373,
				"filed_departure_time": {
					"epoch": 1543297080,
					"tz": "PST",
					"dow": "Monday",
					"time": "09:38PM",
					"date": "11/26/2018",
					"localtime": 1543268280
				},
				"estimated_departure_time": {
					"epoch": 1543299060,
					"tz": "PST",
					"dow": "Monday",
					"time": "10:11PM",
					"date": "11/26/2018",
					"localtime": 1543270260
				},
				"actual_departure_time": {
					"epoch": 0
				},
				"filed_arrival_time": {
					"epoch": 1543300620,
					"tz": "PST",
					"dow": "Monday",
					"time": "10:37PM",
					"date": "11/26/2018",
					"localtime": 1543271820
				},
				"estimated_arrival_time": {
					"epoch": 1543302624,
					"tz": "PST",
					"dow": "Monday",
					"time": "11:10PM",
					"date": "11/26/2018",
					"localtime": 1543273824
				},
				"actual_arrival_time": {
					"epoch": 0
				},
				"arrival_delay": 2004,
				"filed_blockout_time": {
					"epoch": 1543287540,
					"tz": "PST",
					"dow": "Monday",
					"time": "06:59PM",
					"date": "11/26/2018",
					"localtime": 1543258740
				},
				"estimated_blockout_time": {
					"epoch": 0
				},
				"actual_blockout_time": {
					"epoch": 0
				},
				"filed_blockin_time": {
					"epoch": 1543292700,
					"tz": "PST",
					"dow": "Monday",
					"time": "08:25PM",
					"date": "11/26/2018",
					"localtime": 1543263900
				},
				"estimated_blockin_time": {
					"epoch": 0
				},
				"actual_blockin_time": {
					"epoch": 0
				},
				"status": "Delayed",
				"progress_percent": -1,
				"aircrafttype": "E170",
				"full_aircrafttype": "E170",
				"adhoc": false
			},
			{
				"ident": "CPZ5805",
				"faFlightID": "CPZ5805-1543040761-airline-0034",
				"airline": "CPZ",
				"airline_iata": "CP",
				"flightnumber": "5805",
				"tailnumber": "N633CZ",
				"type": "Form_Airline",
				"codeshares": "AMX3110,VOZ6619,WJA7021,CAL9020,CES4186,WJA7017,KAL7470,AMX3936",
				"blocked": false,
				"diverted": false,
				"cancelled": false,
				"origin": {
					"code": "KSMF",
					"city": "Sacramento, CA",
					"alternate_ident": "",
					"airport_name": "Sacramento Intl"
				},
				"destination": {
					"code": "KLAX",
					"city": "Los Angeles, CA",
					"alternate_ident": "",
					"airport_name": "Los Angeles Intl"
				},
				"filed_ete": 3960,
				"route": "FTHIL2 FRA REBRG IRNMN2",
				"filed_altitude": 300,
				"display_filed_altitude": "30,000 feet",
				"filed_airspeed_kts": 453,
				"distance_filed": 426,
				"filed_departure_time": {
					"epoch": 1543288140,
					"tz": "PST",
					"dow": "Monday",
					"time": "07:09PM",
					"date": "11/26/2018",
					"localtime": 1543259340
				},
				"estimated_departure_time": {
					"epoch": 1543299420,
					"tz": "PST",
					"dow": "Monday",
					"time": "10:17PM",
					"date": "11/26/2018",
					"localtime": 1543270620
				},
				"actual_departure_time": {
					"epoch": 0
				},
				"departure_delay": 11280,
				"filed_arrival_time": {
					"epoch": 1543292100,
					"tz": "PST",
					"dow": "Monday",
					"time": "08:15PM",
					"date": "11/26/2018",
					"localtime": 1543263300
				},
				"estimated_arrival_time": {
					"epoch": 1543303380,
					"tz": "PST",
					"dow": "Monday",
					"time": "11:23PM",
					"date": "11/26/2018",
					"localtime": 1543274580
				},
				"actual_arrival_time": {
					"epoch": 0
				},
				"arrival_delay": 11280,
				"filed_blockout_time": {
					"epoch": 1543287540,
					"tz": "PST",
					"dow": "Monday",
					"time": "06:59PM",
					"date": "11/26/2018",
					"localtime": 1543258740
				},
				"estimated_blockout_time": {
					"epoch": 1543298820,
					"tz": "PST",
					"dow": "Monday",
					"time": "10:07PM",
					"date": "11/26/2018",
					"localtime": 1543270020
				},
				"actual_blockout_time": {
					"epoch": 0
				},
				"filed_blockin_time": {
					"epoch": 1543292700,
					"tz": "PST",
					"dow": "Monday",
					"time": "08:25PM",
					"date": "11/26/2018",
					"localtime": 1543263900
				},
				"estimated_blockin_time": {
					"epoch": 1543303980,
					"tz": "PST",
					"dow": "Monday",
					"time": "11:33PM",
					"date": "11/26/2018",
					"localtime": 1543275180
				},
				"actual_blockin_time": {
					"epoch": 0
				},
				"status": "Scheduled / Delayed",
				"progress_percent": -1,
				"aircrafttype": "E170",
				"full_aircrafttype": "E170",
				"terminal_dest": "3",
				"gate_dest": "33B",
				"terminal_orig": "A",
				"gate_orig": "A10",
				"seats_cabin_first": 12,
				"seats_cabin_business": 0,
				"seats_cabin_coach": 64,
				"inbound_faFlightID": "CPZ5805-1543040758-airline-0202",
				"adhoc": false
			}

It appears that CPZ5805 was re-filed with new times once the airline was known to be delayed, but other other sources were not updated in a timely manner from the airline. This caused us to track two versions of the flight.

At time of departure CPZ5805-1543271337-2-0-115 was cancelled in favor of the original filing of CPZ5805-1543040761-airline-0034. This retained the originally filed departure with the delayed actual times while removing the 115 version from the AirportBoards results.

so is this normal and expected ? I see multiple instances of the faFlightID changing for a given ident between successive API AirportBoards calls.

It’s tough to build solution using this data if it gives unexpected results?

Given billing approach I think have to make additional calls so this seems like a logical bug that should be validated out of the source data and cleaned up before we make API call and get it?

Do we need to capture these systematically and sent them in automatically for a call refund :slight_smile:

Any reply on this ? It would be good to understand what the expectation are she can reliable build solution around these behaviors. Once hoes the docs for v3 will come up to and surpass those for v2.

In the mean time this the only source for help we have…and you response is appreciated.

A different faFlightID observed for a single ident should be treated as different flight instance. The faFlightID is intended to be a unique identifier, like a hash, for a flight instance. Details for that instance (estimated departure time, route, filed airspeed, etc) may change, but the id will remain constant. This may also allow for the ordering of faFlightIDs seen in a Boards to change over subsequent calls. Depending on an airline’s scheduling policies it’s possible to see the same ident used in multiple flights over the same day. An ident alone is not necessarily a good identifier of a unique flight instance.

This is a contributor to the additional CPZ5805 filing being treated as a new instance. Even though the ident is the same it was originally filed with non-overlapping flight times.

Once a flight of interest is identified in a Boards request it may be worth while to use its faFlightID to retrieve potential updates through FlightInfoStatus instead. This saves having to try and find the flight again in Boards, especially if an unexpected delay means it hasn’t transitioned from a scheduled to a departed state at the originally planned time.

Well I’ve seen many a flight change it’s faFlightID between one API request and the next (literally called seconds apart) so using it as a key is kinda useless as you end up with orphaned flights!

There has to be some kind of guarantee that won’t change a faFlightID once its used for a specific Ident or were all really hosed.

In your example the prior filed flight for CPZ5805 will be left with no future updates? And further more to do the in the same call response makes even less sense ?

Per you FlightInfoStatus suggestion - given the pricing model that would be significantly more costly as I get 4x15 flights per flight board (assume all types) for a “Call” and that would then be 60 “calls” by calling FlightInfoStatus repeatedly for each flight, and then I’d also miss out on these new re-filed flights…

I’m not sure this is very satisfactory, unless you add at least a 0 on the end of each tier call quota!

With LAX say having 2000+ flight a day a 20k quota won’t go very far…by your suggestion.

There is a hue barrier to entry for developed to get to develop their solution with out extensive startup data costs, and suggest that from a FlightAware business perspective there be a way to help this more…as you have to look a the future locking once you have us dependent!

Cost issue aside…

Please can you confirm that the API could do a better job of not having a duplicate ident in a single list of flights for a given repose type (say scheduled) to avoid orphaned flight.

Having this occur in the departed list would really makes no sense ?

Any reply - as before without better documentation your replies is is all we have?