9

We just realized that there are quite a lot of ICAO codes which have changed in recent years and seem to not have been updated in AirportData (and also WeatherData which uses these codes as codes for the airport-located weather stations).

One example is O. R. Tambo International Airport at Johannesburg, IATA code JNB, ICAO code FAOR as of now. (wikipedia: "On 10 January 2013 the airport's ICAO code was changed from FAJS to FAOR"). AirportData still addresses this as FAJS and doesn't know the newer FAOR. Thus from the following call only the first two will return valid results, the last one reports Missing["UnknownEntity",...] although it is the current valid ICAO-code:

AirportData["JNB"]
AirportData["FAJS"]
AirportData["FAOR"]

I think I will report this as a bug, but does anyone have an idea how we could fix this in the current releases?

Note: This problem also exists in Wolfram Alpha. I have now reported this as an issue to Wolfram Research...

Albert Retey
  • 23,585
  • 60
  • 104
  • 1
    I doubt there's much to be done, other than creating your own EntityStore with the newer data or setting up a master list of "aliases" for ICAO codes. I would definitely report it as a bug though, this data should be kept up to date if it is going to be shipped with the language. – Carl Lange Mar 23 '21 at 17:29
  • @CarlLange: I think you are right, but sometimes someone has an unexpected idea :-) – Albert Retey Mar 23 '21 at 18:08

1 Answers1

3

I have investigated this a bit further and found that there are quite a lot of outdated entries and that this also seems to be the case for WolframAlpha queries. One possibility to do checks is to use another data source for airports, one that I have found is ourairports.com which at least seems to do regular updates and showed correct up to date values for some spot checks I did. Using this as a reference we can use the following code to check for differences:

airportfile= FileNameJoin[{$TemporaryDirectory, "airports-download.csv"}]

URLSave["https://ourairports.com/airports.csv",airportfile];
content = Import[airportfile];
Length[content]

which gives 63289 entries in that file (on 2021-03-25). To check which of those have both a valid IATA and ICAO code, we can use:

iataQ[s_String] := StringMatchQ[s, RegularExpression["([A-Z]){3}"]]
icaoQ[s_String] := StringMatchQ[s, RegularExpression["([A-Z]){4}"]]

Using these we can extract those entries:

currentids = Select[content[[2 ;;, {17, 16}]], 
   MatchQ[#, {_String?iataQ, _String?icaoQ}] &];

Length[currentids]

giving 8208 (at least today, 2021-03-25). Using that data, we can create replacement rules with which we can correct or check outdated entries, e.g.:

icao2iata = Dispatch[(Reverse /@ Rule @@@ currentids)];
iata2icao = Dispatch[Rule @@@ currentids];

and check that AirportData indeed returns something else:

AirportData["FAOR" /. icao2iata]@"ICAOCode"

Doing this for all the ~8000 entries I found 433 entries where the ICAO code differs between ourairports.com and AirportData, 48 entries where IATA codes differ and 3219 entries which AirportData did not even know (these numbers were from yesterday, they might have changed slightly for today). Warning: this check takes a few hours to run and as a mass query is not really friendly to WRI servers, so don't repeat if not for good reasons.

With the replacement rules icao2iata and iata2icao one should at least be able to implement some workarounds for outdated AirportData entries. Making use of the other columns in the downloaded files one could also extract some of the other properties for those entries that are missing in AirportData.

Albert Retey
  • 23,585
  • 60
  • 104