Showing posts with label postgresql. Show all posts
Showing posts with label postgresql. Show all posts

Tuesday, October 25, 2011

Duplicate Airport Entries in A/FD

Hadn't noticed until recently that some airports are listed in more than one (physical) Airport/Facilities Directory. This makes some amount of sense in that some airports effectively straddle state lines. Consider "St. Louis Regional Airport", in Alton IL, not Missouri, or "Cincinnati International Airport" in Kentucky, not Ohio. In both cases, the different physical A/FD books happen to split along these common state borders: KY is in the South East book, Ohio in the East Central book.

I'll not argue that they shouldn't appear in both books as I pity casual GA pilots who might otherwise need to carry twice as much just because of a nearby political boundary. (I grew up in Kansas City, so I'm very familiar with cross-border advantages/dis-advantages.) I do find it surprising that some Oregon airports appear in the Alaska volume, however.
AST in "Northwest A/FD"

Does it matter? Well, yes-and-no, of course.

AST in "Alaska A/FD"
The entries happen to differ from each other in minor ways: For example, the Northwest A/FD volume's entry for Astoria, OR (AST) includes more details on runway lighting and obstructions than does the Alaska volume for the same airport. Fortunately the frequencies, locations, and distances are all the same.

Why do I care? I didn't until my code stopped working. Now I have to choose for you, which of the two entries I display. I was recently moving the information associated with A/FD pages from a python pickle into a PostgreSQL database (this is part of an ongoing project to move more ad-hoc memory structures into a "real" database.)

The mapping from airport code => page in an A/FD is pretty awkward. Via an FAA web page, we can query for most airports and the FAA will retrieve the page from the book. However, the first step is to indicate which state to use. So, you indicate "Alaska" and then "AST" and you'll see Astoria, OR.

For AvnWx.com, I retrieve the full mapping, which means I get all the entries, including:

ASTOREGONnw_84_20OCT2011.pdf
ASTALASKAal_21_20OCT2011.pdf

which roughly translates to page #84 in the Northwest volume, and page #21 in the Alaska volume.

Anyway, we apply an algorithm which attempts to pick the "better" entry and show that to the user. As it happened, I didn't use to care, so duplicates weren't silently ignored: I think I just always used the second entry.

The key concept here is that as you re-purpose data, you may discover new relationships which may be important or just annoying.

[also, note that "MANY" appears twice in the same book with Louisiana: once as the MANY NDB, and once as the MANY RCO... Fortunately, they're both on the same page!]