Discovered while trying to debug my nav data loading scripts: The Hendersonville Airport (0A7) and the “W.N.C. Museum Airport” (8NC9) are only 0.03 nautical miles apart, but they’re separate airports. I’m not sure if they’re the closest two ever, but they’re certainly pretty damn close. As a matter of fact, I think this picture 
from the AirNav.com web site listing for Hendersonville shows both runways, the paved one for Hendersonville and the turf one for the museum. I bet there is a story why they didn’t just build a taxiway between them and call it one airport.
Category: Geekery
Oh, bugger!
Ok, the big load job just finished, and it appears I was loading the old FAA data, not the data that became current on Wednesday. Also, it appears I have a bug in the code that loads the runways – the old scripts seemed to have taken “U” or “” for the runway end latitudes and longitudes as null, but the new ones are putting those values in as 0. Oops.
I guess I’ll have to run it again – using nohup this time. See you next week.
Hey, Google
If you’re going to send a guy a survey to find out his impressions of your recruiting/interviewing methodology, you might not want to send it to somebody who has been waiting two months for you to pay his travel expense claim. Because he might just think that you’re a bunch of disorganized fuckwads. Just sayin’.
And a bit of further advice – you might want to make sure your expense spreadsheet actually prints out correctly using Google Docs and doesn’t require one to steal a copy of Microsoft Office in order to use it.
Darn it!
Some years ago I got a set of Shape Files (much as I hated ESRI at the time, they did beat us (GeoVision) fair and square with an inferior product and superior marketing) for the provincial and territorial boundaries of Canada and wrote a short little C program to do a “point in polygon” to determine what province a particular point is in. It’s set up so that it parses the shapes, then sits there waiting for a lat/long pairs to come over a pipe and writes the province code back over the pipe. I write a special lat/long pair (-999/-999) when I want it to exit. I use it all the time when I’m loading waypoints. The program has continued to work while my waypoint generator moved from being hosted at home to a webhost (Gradwell.com) to a virtual private server (Linode) to a colocation box. Unfortunately, I just discovered that somewhere along the way I lost the source code. Right now it has a small bug in that when the program that opened the pipe to it dies, it starts consuming all the CPU instead of shutting down. I can live with that, but it’s annoying while I’m doing all this testing with buggy load scripts. That’s why I went looking for the source code.
Maybe I should write a new one just in case?
Hoist by my own petard
Yesterday I thought I’d try running my loading scripts on my home machine because it’s so much faster than my colo box. And it was running faster, and had gotten further than the still running script on my colo box when I got hoist by my own petard. I like to partition my systems up with different sized partitions for different major directories, and unfortunately, on this home machine, I only gave 100Mb for /tmp, not realizing that MySQL uses a temporary directory when you’re doing a long transaction. According to munin, the script filled up /tmp and died just a few minutes before I woke up this morning. So I’ve gone into /etc/mysql/my.cnf, changed the temporary directory to /var/tmp, and restarted it. /var/tmp has 7.6Gb free, so it should be safe.