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.
Recently in GIS Category
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.
Usually, installing an application from source on Linux/Solaris/BSD is easy:
- ./configure --help (Always look at the help to see the options. It makes a difference if, for instance, you compile php without support for MySQL.)
- ./configure
- make
- make install
However, with Darkice, it's prerequisites are numerous, and Darkice's configure doesn't find it's prereqs if they're installed in the standard locations. I've done this twice so far without documenting how I did it, so this time, I'm writing it down.
Here's my configure line:
./configure --with-vorbis-prefix=/usr/local/ --with-lame-prefix=/usr/local/lib/ --with-twolame=prefix=/usr/local/lib/ --with-faac-prefix=/usr/local/lib/
Then you'll get this when you launch darkice:
darkice: error while loading shared libraries: libmp3lame.so.0: cannot open shared object file: No such file or directory
So you need to link that, and when you link that you'll get the next error, so here are both:
ln -s /usr/local/lib/libmp3lame.so.0 /usr/lib/libmp3lame.so.0
ln -s /usr/local/lib/libfaac.so.0 /usr/lib/libfaac.so.0.
If you're wondering what links you're missing, try
ldd /usr/local/bin/darkice
If one of the links to the libraries reads "missing" then that's the one you need to link.
Yum install darkice might work for you, but then again, if you need all the features, it probably won't.
Prereq links are below. Generally ./configure, make, make install works well with all of them, but you really want to track exactly where each lib gets installed -- usually /usr/local/lib/.
Lame
Twolame
libogg
libvorbis
faac
Preqrequisite for faac or twolame -- I forget which:
libsndfile
Prereqs I didn't neeed:
Alsa
Jack
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.
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.
According to the FAA, there are 977 U.S. special use airspaces around the world. (Some are international, like the Pacific off of Guam.) By Special Use airspace, I mean the following FAA Types: ALERT AREA, MILITARY OPERATIONS AREA, PROHIBITED AREA, RESTRICTED AREA, WARNING AREA. (Another side note: It's not just the FAA that loves ALL CAPS. The Department State also uses ALL CAPS in its cables.) There are many areas of the United States, in CONUS, Alaska and Hawaii, that are special use.
The FAA flat-fixed file that is the source of this data is so convoluted that I have a new-found respect for companies like Jeppesen that produce the data in a readable format every 56-day cycle. The FAA stuffs 8 different tables into one giant flat file with a well-documented layout.
Google Earth is not perfect with its polygons, either. It's got bugs, especially when it comes to KML stylesheets. I wrote the style tags with VBScript out of SQL, so they are all the same, but in Google Earth, they don't all look the way they're supposed to. It feels like troubleshooting early versions of Netscape and IE when writing HTML. And no, I didn't use some fancy XSL to transform my queries into KML (XML). I used VBScript because it's the tool I know and it's fast.
The usual warning applies: DO NOT USE FOR NAVIGATION. My code isn't perfect, and neither is the FAA's data. There is no substitute for a pre-flight briefing. I ask about the airspace every time flying out of the ADIZ.
Download the file here: US Special Use Airspace.kml.