Airplane!

This past week, I revisited QGIS in hopes of making some elegant/simple maps of historical air travel to/from Albuquerque. When I first heard that our class project was about the Sunport, I was puzzled. I’ve appreciated many airports in my life, none moreso than ABQ with its 12 minute curb-to-terminal potential (and yes, I used a stopwatch). I’ve never really thought about them from a scholarly point of view. Do they illustrate conceptions/constructions of race, class, and gender? Do they create spatial data? Do they illustrate technological innovation over time? Are they linked to leisure and tourism?

The answer, of course: yes. Airports are some of those spectacular things that hide under our collective noses. Think about it: you plan weeks/months ahead to arrive at a building to VOLUNTARILY hurtle through the sky. I know that’s a bit reductionist, but you get the idea—airports are pretty jazzy spaces. They’re even more significant for landlocked spots like Albuquerque, which can sometimes seem a bit like an island. The city itself seems to be constantly keeping up with the Joneses nationwide—for instance, when Winrock Center opened in the early 1960s, there was a multi-day televised opening celebration. Like a mall, an airport is another symbol that a municipality has arrived.

This rumination is all well and good, but how does it lend itself to a DH perspective on the Sunport? Luckily, airports and airlines produce data. Lots of it. My partner Gary and I were curious to see how the airport facilitated a spatial compression of the nation—in other words, how diminishing travel times throughout the mid-20th century brought distant spots like New York closer to the Duke City. While I’ll ruminate more on this in the future, I’ll give a summation of my methodology:

1. Find historic flight tables.
2. Set parameters. It would be impossible to calculate every flight time to/from the city if one factored in transfers. So, we focused on singular flights—ways to get to Albuquerque from other cities without changing planes).
3. Harvest data from said flight tables (we were most concerned with duration of flights to/from Albuquerque; we found pricing details as well).
4. Visualize the resulting CSV files using QGIS. Add a raster layer and manipulate the attribute tables, and voila!

The mapping itself turned out to be quite fun. I was able to make a simple map illustrating travel times by year, like so:

The above view is from Print Composer, a subsidiary feature of the QGIS platform. You can tell it’s not a finished product because it’s got some drag bars still showing (because you can always tweak your project just a tad more). Print Composer is great because you can add a legend/title/compass rose, then export your map as a JPG, PDF, or pretty much any format you can imagine. Why didn’t I screenshot my finished product, you ask? Well, there wasn’t really a choice. When I exported the above map, here’s what I got:

This one is actually pretty well aligned, but I only got a chunk of my image. Let’s try again:

No one told me that Los Angeles was so close to Anchorage. Plus, my legend migrated to Canada—cheaper rent, maybe?

This was actually the first try. No raster for me, I guess. Anyways, it was really difficult to get it right (I’ve got many more erroneous map exports if you’re curious just how wrong things got). When I talked to Dr. Gibbs, he mentioned there might be a problem with the Coordinate Reference Systems (CRS). Unfortunately, both the raster and the CSV layer were set up identically. This was disappointing news. However, there are two positives:

1. I can always just screenshot my finished map in the Print Composer (like the first image in this post). As long as it doesn’t need to be über high quality, this will work fine.
2. Further evidence that I should be really happy when mapping goes right. Even though I’m getting more comfortable with QGIS, it’s still astounding what I ask of it. I input a CSV layer with GPS data; I then tell it to locate these points and mark them (it does). Then, I use the OpenLayers plugin to fetch a Stamen map for my background (it does). Now I manipulate my attribute table, creating custom delineations for my flight data (in this case, I’m using the time variable). Then, dots with color gradients show up on the aforementioned GPS locales—the color shows a correlation with certain time brackets that I deemed significant. Even though I’ve done a lot to the map by this point, it’s still essentially a delicately interwoven combo of vector and raster. The Print Composer showed me this, time and time again.

Overall, this difficulty made me reevaluate my data presentation. Gary has made a brilliant web map with CSV data I harvested—we’re not quite sure on the specifics, but it will show the reduction in travel times with different year intervals (‘35–’65) as clickable map layers. In exporting some simple JPG maps from Print Composer, I was hoping to add a non-interactive component to our final product. This is not because I think interactivity is bad, but because such a format seems to allow Gary and I—the masters of our project—certain liberties with choosing how the user interacts with our data. Say we find an interesting correlation between birth rates and flight times (humor me). An interactive map with flight times, years, vector layers and birth rate data could get cluttered; by isolating it in its own map, however, we could juxtapose it with our larger (and simpler) map of flight times by year. This was my thinking.

However, upon the realization that my Print Composer skills weren’t cutting it, I had a brief flash of our project as nothing but interactive maps. Gary and I had a productive conversation about our data and the most cogent arguments it can make. We realized that, at bottom, our project was still about time and space. Even if we present one thickly interactive web map, we can still include the fourteen CSV files that I made (7 intervals, one every five years; 2 per year, one for Continental and one for TWA) as a gesture toward methodological transparency. That’s the nice thing about creating your own data: even if it doesn’t visualize precisely the way you want, it’s still there. And, there’s a chance someone else might also find it valuable.