Ken and I just got back from a 19 day flying trip. Ten days of actual flying, 5900 miles and 48 hours of operating the airplane (average speed of 140 mph; 6 hours spent maneuvering). Took about 500 gallons of gas, 12 mpg. Fortunately I didn’t learn to fly because I thought it was particularly practical. This trip was particularly frustrating because we got unlucky with headwinds and maintenance problems. I am privileged to be able to travel in a small plane. Aside from being able to fly at all, I’m lucky that Ken has such a nice airplane for long trips. And we’re fortunate in having the time and money to go on a trip like this and just shrug off a few days’ delay. It’s unusual for a pilot as new as I to take such a long trip. I couldn’t do it without sharing the flying with Ken, both for his expertise and for his instrument rating in case of bad weather.

Here’s a map of our full route. My favourite stops were Kansas City for a nice downtown, Cleveland for a great dinner at Lola, and Tucumcari for a small airport fuel stop complete with borrowing a 20 year old cop car to drive in to town for enchiladas. I also enjoyed our time in St. Louis, even if it was frustrating; it’s a nice town with a lot to offer visitors.

Next up is a trip to Florida for Christmas. Looking forward to not flying through Kansas for once! We may hop over the ocean to the Bahamas while we’re at it, would be a nice entry in the logbook.

I’m sitting in St. Louis waiting for our plane to be fixed. This repair is the third required on our trip to Boston and back. The first was replacing a vacuum pump in Santa Fe; that only delayed us a few hours. The second was replacing a gear indicator switch in Poughkeepsie where we were stopped for a few days anyway. Failure #3 is bad luck, the attitude indicator failed on Saturday morning. Mechanics generally don’t work weekends and you have to have parts shipped anyway, so now it’s Tuesday and they just installed a new one and it doesn’t work, something else is wrong.

The good news is none of these failures was anything serious; the plane flies fine even without fixing them (albeit it’s not legal nor smart). The bad news is repairs are delays, multiple days of delay, and it gets a bit tiresome.

The other big slowdown in a little plane is winds. Generally you expect a 10-15kt wind from the west across the US, so you get a tailwind going east and a headwind coming home. But winds change a lot down low and we’ve had terrible luck. We haven’t seen a tailwind yet and half our days have had 25kt+ headwinds, making us travel 20% slower. Between headwinds and other weather our 3 day trip to Boston ended up taking 4.5.

At least we’re stuck in St. Louis and not somewhere in the middle of nowhere. It’s a nice city.

There’s an amazing amount of free mapping code and data out there but it’s difficult to figure out how it all fits together. Yesterday I did a one day spike of a map for pilots, a picture that emphasizes mountains higher than 8000′. What I love about this hack is how much technology was involved. Web servers, Javascript, PNG compositing. Geographic projections and image rendering. Data from three different sources, including the freaking Space Shuttle. And I was able to cobble it all together in less than a day without any real expertise in mapping. Hooray for Open Source Geo!

My product is a slippy map, a zoomable javascript map like Google Maps. The map has three data layers on it: raster aviation sectionals for the base map, a raster elevation overlay, and a vector state outline. I put it all together in Javascript using Polymaps, an amazing mapping library. All told it was 50 lines of Javascript, about an hour’s work.

Polymaps’ job is loading map tiles, what about the tiles themselves? I lifted the aviation sectionals from RunwayFinder and the state outlines from a PolyMaps demo. I had to build my own map layer for elevation. SRTM is an amazing free elevation dataset (7GB for North America, an hour’s download). But it’s just raw data and I need images.

SRTM is a simple enough format but I didn’t want to write a bunch of rendering software. Fortunately there’s MapServer, a dynamic web server for map tiles. MapServer wraps a CGI interface around GDAL, which does the heavy lifting of projection, scaling, and rendering (via libgd). The great thing about this software is it all just works and has great docs. I barely understand what it’s doing, but I got it working with an hour or two of tinkering.

I didn’t link my live map because my server would die; the dynamic rendering from Mapserver is too much for it. It’d be pretty simple to prerender all the SRTM tiles to about 100 gigs of image files for fast serving. That’d be a useful resource to host online for other mappers to use in their own products. But what I really want to do is move that 8000′ threshold I hardcoded into the user’s hands, to let you dial up and down and quickly see terrain levels. To do that requires some client side image manipulation, so that’s my next hack.

For video games I’ve been playing almost nothing but Minecraft for weeks now. It’s a really amazing game / toy / sandbox, beautifully done. The ease of playing it combined with the complexity of what you can do with it makes for a really engaging game. It’s also horribly buggy and with comically bad graphics, although the graphics grow on you after awhile.

The video above is my first experiment with Redstone circuits, Minecraft’s complex digital logic system. I like blinking lights. The video also shows off the lovely Quandary texture pack, which combined with the texture rotator gives a nice sense of changing seasons.