As I begin forging my online identity here, I need to begin with a bit of shameless self-promotion. Last year I designed a piece of software called PFPS Google Earth Tool that links the Department of Defense's flight planning software with Google Earth. With this program, users can convert routes, airspace regions, waypoints, threats, and other data into a .KML file viewable in Google Earth. At the most basic level, the software allows pilots to visualize their flights in 3D. Also, now that SIPRNET (the military's classified version of the Internet) has authorized Google Earth servers running, GE could potentially serve as a joint virtual battlespace, where users of myriad geospatial programs can bring their data together into one presentation.
I mention the program here because it illustrates a point I will hammer on this blog: the case for "openness." In about six months, while maintaining a full-time active duty career and a family, I was able to write a piece of software that would require millions of dollars and years of effort in the DOD acquisitions system. The program is now being used in such diverse places as NASA's support for wildfire fighting, the Air Force's search-and-rescue support for the space shuttle, airdrops in Afghanistan, and air forces in Australia and South America.
What I've done is not unique. The military is full of talented individuals who find low-level solutions to their problems using spit and duct tape. On the software side, I've seen pilot-written software for recording GPS tracks of flights and playing them back in Google Earth, spreadsheets for calculating detailed airdrop parameters, and Access databases that deconflict crowded low-level training routes. Innovative ideas take more tangible forms as well. In Iraq, innovative soldiers used silly string to detect tripwires for IEDs and built radio devices sometimes capable of remotely detonating them. My favorite example comes from Moses Lake, an auxiliary training field used by C-17s from McChord AFB. The Air Force wanted the capability to use the field for night vision goggle (NVG) operations, but the main runway has intense VASI lights at either end that can't be dimmed. The Air Force studied the problem and decided it would cost millions of dollars to rewire the field to enable dimming the lights. A local handyman at the airport--the kind of guy who drives around a pickup with a tool chest in the back--bought a couple sheets of plywood at home depot and built two boxes that can be placed over the top of each offending light fixture. Problem solved, for around $30.
Winning organizations, including the military, must create an open climate that fosters innovation and allows good ideas to "win." This is especially important in information technology, and it's especially important in the Air Force--a service that is particularly information intensive.
A Success Story for Openness
PFPS Google Earth Tool was possible because of three enabling technologies: (1) the flexible, open-ended, and public .KML data format used by Google Earth (2) a semi-public Software Development Kit (SDK) for the military's flight planning system (PFPS) and (3) PFPS's widespread use of Access databases to store information, which allows users like me to manually manipulate the data. Using these "open" technologies, it was relatively easy to write conversion code from one format to another.
The military today uses myriad geospatial and force tracking programs, most of which store data in different formats and are mutually incompatible. One of my top recommendations for these and future programs is that they support a variety of Import/Export formats that can be easily used by your average Lieutenant or Captain. Any officer today can use Excel. Many can use Access or SQL. XML has emerged as one of the most important and useful data formats in the world, because it can store anything, it's easy to parse, and you can read it as plain-text. My first version of PFPS Google Earth Tool relied on PFPS .XML exports. My point is this: every day out in the battlefield, soldiers and airman are scouring, recombining, and republishing information from myriad sources. This takes a lot of ingenuity at the unit level. If the military makes real efforts to open up data formats, it will empower soldiers at the unit level and accelerate the flow of information.
A Failure for Openness
There is a dark side to the PFPS Google Earth Tool story. Every day, the Combined Air Operations Center (CAOC) publishes an "Airspace Control Order" (ACO) that details every region of airspace in an entire theater: air refueling tracks, Army firing ranges, UAV orbits, etc. This vital information is viewable in PFPS, but my personal holy grail was to convert the entire thing into vivid 3D detail in Google Earth. The problem is that the ACO data format is incredibly complex and almost impossible to parse. It has so many subtle variations (giving coordinates in multiple formats, for example) that without a detailed explanation of all the standards, there was no way I could create a reliable converter. A document supposedly exists that explains the data format. It is a "USMTF", or US Message Text Format, document. The entire purpose of USMTF is to facilitate the flow of informations among the joint force. Sounds open... right?
Thus began the wild goose chase. After w