Done in changeset/83734763. If I'm not missing anything, this should address all the feedback.

If so I have one last question: How should I proceed with the remaining IATA code issues? Those seem to fall into roughly 3 categories:
(1) ICAO/FAA/other LIDs wrongly marked as IATA codes (ie. similar to this changeset).
(2) "no"/"none"/etc, ie. some form of explicit indication of there being no IATA code.
(3) Duplicate uses of the same (syntactically valid) IATA code on multiple airports. Some of this might be due to similar issues as (1), some might be historic (new airport being built reusing the same code), I haven't reviewed all of those in detail yet.

There's about 30 cases of (1) + (2) left, and another ~50 cases of (3).

For (1) I guess I can proceed in line with the discussion here, ie. move codes to the right tags while ensuring there is no "data loss"? For (2), should those be kept as-is, normalized somehow, or dropped? For (3), what's the approach for historic values?

I also get warnings for issues in the enclosing polygons of 7 airports, but that could just as well turn out to be issues in my code :)

Thanks for your help!

Both issue should be addressed by changesets 83734763 and 83735227 respectively.

Thanks for reviewing this! I agree on both.

Mule Creek seems to be a Canadian airport code instead, I got fooled by the FAA website finding it as an FAA code (https://nfdc.faa.gov/nfdcApps/services/ajv5/airportDisplay.jsp?airportId=CBS4). I don't know how to properly tag those though (there's a few more such cases that were mislabled as IATA codes before), see the open question in the discussion on changeset/83540929.

The ICAO code on Naked Lady Ranch Airport is certainly wrong (syntax violation), and there are quite a few more of those cases, but that was already the case before, I just added the FAA code there as requested in the discussion around changeset/83540929.

I can have a look at the ICAO issues more systematically eventually, but it seemed to make sense to first complete my current attempt of fixing issues with IATA codes :)

changeset/83656249 re-adds those removed codes that are actual ICAO/FAA codes for this changeset. What remains now are 5 cases where the codes turned out to be Canadian or Mexican local airport codes. For those I am unsure how to correctly re-add them, using "ref" or the above suggested "airport_code" tag?

Right, but please note that the above mentioned fix was for the second changeset (83546052), not for this one (83540929). The issue you mention is part of this changeset, and therefore not addressed yet. I just thought it would be prudent to verify first I was on the right track before going over all changesets.

changeset/83600172 should fix changeset/83546052 by adding FAA codes that were previously wrongly tagged as IATA codes. There are two other patterns in those changes I did not revert/fix: (1) FAA codes in the IATA field, but also already set in the FAA field (2) IATA codes derived from (also syntactically wrong) ICAO codes by dropping the first letter. In case (1) I'd say the deletion of the IATA tag is correct, and in case (2) it does not constitute an information loss while improving the data quality of the IATA field at least (I haven't touched ICAO syntax errors at all yet). Verifying the FAA codes on the FAA website found one that was changed (way/316984088), I updated that accordingly.

I hope I didn't cause even more damage and this matches what you had in mind. If so, I'd do a similar fix for this changeset. Sorry again for the trouble, and thanks for your help!

So, how to proceed from here? Should this changeset as well as the similar #83546052 be reverted?

Hi,

these changes merely clean up syntactically invalid IATA codes, ie those not consisting of three upper-case letters. The changes themselves were done manually, although the list of errors was the result of code consuming this data. ~150 cases in total, not all submitted yet though, the remaining ones need closer review (e.g. swapped keys rather than wrong values as such).

I am very sorry if I didn't follow the right procedure for applying those changes, and I will most certainly refrain from further changes until this is clarified. It just seemed more useful to improve things upstream rather than just ignoring this in code.

Volker