Recently in Aviation Category

There are 13,632 airports in the FAA database. That does not count balloonports, seaplane bases, gliderports, heliports, or ultralight facilities. That's also a huge number of placemarks for a KML file, so your Google Earth machine will need some processing power.

If you pan out, the placemark icons will cover the continental United States. It also drives home the point that if you're flying high enough and your engine dies, you should be able to glide to an airport.

Improvements: Public airports are in blue; private airports are in red. AWOS data is included where applicable. (If airports have an AWOS, it's included. Note that ATIS is not the same as AWOS.)

Code improvements: All output code is Python. The database is still Microsoft SQL, and the API is adodb for Python. Next: Porting output code to Linux (need a new database connection) and keeping back end MS SQL for now. Long-term: cleaning up and uploading data via python into MySQL.

Random Comments on Python: String manipulation in python is the same as in visual basic script, but different. If statements have no end, just an indent and and end of indent.

The KML file is in the KML archive, as usual. DO NOT USE FOR NAVIGATION.

I have an updated AWOS KML file that will show you the telephone number, frequency, and AWOS type for the airports listed in the FAA's AWOS text file. You can download it here. As always, the KML archive is here.

This file uses the airport's latitute and longitude rather than the AWOS' latitude and longitude, which is missing in some cases in the FAA's file.

Also, the FAA files seem to have arbitrary layout changes from release to release, as well as some data quality issues. (Missing data, data out of alignment, etc.) I'm glad I don't have to produce this stuff on deadline.

After losing a disk, I finally got around to rebuilding the database and scripts to generate KML files from the FAA's NFDC subscription. First to be redone is the Special Use Airspace KML. Microsoft's SQL Server 2008 does a far better job of importing files than SQL 2005 did. The airspace KML archive is here.

I updated the airspace KML files again -- skipping one release. The latest covers from December 17, 2009 throughFebruary 11, 2010. You can find them in the archive here.

I have updated the AWOS frequency, phone, phone and type file based on the FAA's 56-day subscription data. However, instead of using latitude and longitude included in the file, I joined the main airport file by airport ID. This requires making an assumption that all AWOSes are at the airport they serve. While that might not be the case, I get 643 more airports into the file then before. The AWOS file has 2,185 entries of which 1,542 have latitude and longitude. Almost every corresponding airport in the APT file has latitude and longitude. Thus, DCA will now show up with a phone number, but no frequency. The new KML will also show the AWOS type: ASOS, AWOS-1, AWOS-2, AWOS-3, or AWOS-A.

Finally, matching airports to AWOS increases the complexity. I had hoped to write a simple script that does text manipulation for all KML files -- one script altering one FAA text file to produce one KML file. As with the Special Use Airspace, however, there wasn't a good way to do it without using a database and relations.

Find them in the KML archive.

I updated the Airspace, Special Use, and Airport KML files for the FAA data covering the 56 Day Subscription from August 27 2009 to October 22 2009. I have also created batch files to call all the scripts, and I'm working on a T-SQL script to clear the tables and do a bulk import from the files.

Also, I corrected one incorrect assumption. Not all US Airports are in the western hemisphere. I assumed all longitudes were W and put a minus sign in the conversion to Google/KML decimal format from the FAA's all-seconds format. Wrong. In the updated file, MAJ (MARSHALL ISLANDS INTL) is in the right place. I'm still not sure Pago-Pago is correct, however.

The index of files is here.

FAA subscription data includes .shp (shape) files for ESRI products. Google Earth Pro ($400/year) is capable of opening these shape files directly, but the default setting is to make them opaque. Thus the class B airspace looks like one single area with no details. FWTools is a free open-source conversion tool to change GIS formats. It also does a much better job of converting the data, showing each individual airpspace and its low and high altitudes. The FAA marks the class E files as experimental, NOT TO BE USED FOR NAVIGATION.

The FWTools command to change from the FAA's .shp format to KML is as follows:
ogr2ogr -f "KML" C:\airports\class_b.kml C:\airports\class_b.shp The FAA lists airspace in order (e.g. Washington Class B Area A, Washington Class B Area B...), and fwtools maintains this order. When Google Earth displays this information, the last one listed goes on "top" of the area. Thus when you click on the center of a Class B zone, the widest area comes up, NOT the SFC to 10000 area. You can see the correct area when you click on the corresponding area layer, however. (I am currently working on a fix for this, but it requires some custom XML and SQL programming that's going to take some time.)

However, there is a weakness in Google Earth. The KML specification does not allow the creation of floating polygons. All non-plane polygons are extruded from the surface or ocean floor. Thus, there's no way to express in KML the upside-down-wedding-cake shape of your typical Bravo airspace. This may one day change, however, because Google is already adding its own extensions to the KML specification.

If you don't want to bother, just download the Airpspace KML files here: Archive link.The usual warning applies -- DO NOT USE FOR NAVIGATION. The KML archive is here.