My Flight Historian has always used Great Circle Mapper for its maps. However, I’ve occasionally had the need to use other map formats, like GPX (used by many of my mapping projects) or KML (used by Google Earth).
A while ago I wrote some internal methods in Flight Historian’s code to let me generate GPX or KML files. However, they weren’t available for public use.
I’ve changed that with a small update today. Every map on Flight Historian now has download links immediately below it for GPX and KML versions of the map.
Early on during the development of Flight Historian, I realized that I’d have to do some filtering of my maps by region. Most of my travel is within the United States, so a world map of all of my flights left the United States as an unreadable mess of lines. Thus, I gave Flight Historian the ability to toggle between world maps (all flights) and CONUS maps (flights within the CONtiguous United States – that is, the United States except for Alaska, Hawaii, and territories).
Because of peculiarities with how the Great Circle Mapper generates maps, showing region maps wasn’t as simple as setting a map center and zoom level. Instead, I had to know which airports were inside the CONUS and which ones were outside. The easiest solution was to add an is_conus attribute to my Airports table, which would be set to true for CONUS airports and false for OCONUS (Outside CONUS) airports. Once I had that, I could set the world map to use every airport, and the CONUS map to show only airports where is_conus was true.
This worked well enough when I was only showing two regions (world and CONUS). But as I traveled, I realized I was going to want to zoom in on other regions (for example, Europe) as well, which meant that I’d have to have some way match airports to other regions.
In general, my Flight Historian has been a big time saver for me as far as tracking my flights – instead of manually generating reports and maps from an Excel file, I can simply add flights to a database and let it do all the work. However, as I’ve started tracking more details about my flights over time, the task of entering the flights has become less simple.
There are currently 24 fields to fill out in the flight log. Not every field is required, but it can still take several minutes to fill out a flight.
Since I’d been working on parsing boarding pass barcode data, it seemed like a logical next step to write some sort of scanner that would read a boarding pass barcode and import the data as a new flight. Then one of my Twitter followers had a suggestion:
that's actually not a bad idea. You could import the .xpass format used for apple's wallet make the process easier
On my Flight Historian application, a number of my pages make use of the flash and flash.now session messages capability for errors, warnings, successes, and informational messages. However, some of those pages needed to have multiple messages of the same type (e.g., multiple warnings), which flash didn’t allow me to do. Additionally, I had some views that were generating status messages of their own (for example, if a collection was empty on a page that had multiple collections), and so I ended up with several ways to generate messages that didn’t output consistent HTML.
The bar codes on paper or electronic boarding passes contain a good deal of data about a given flight. One of my goals for Flight Historian is to allow me to add a new flight by scanning the bar code, but in order to do that, I need to write a Ruby parser for the data in these boarding passes. This parser will accept bar code data, and return a collection of field names, values, and its interpretation of what those values mean.
One of the more difficult challenges I’m running into, though, is interpreting the date of the flight from the bar code.
So why did I go to the trouble of writing my own flight tracking application rather than just use an existing one? My primary reason was to gain experience in a new programming language, but the reason I decided to write a flight tracker rather than any other project was that I disagreed with the way the available flight trackers count airports.
For clarity, I’ve taken the numbers of flights for each airport from the above links and placed them in a table:
Comparison of Year 2015 Flights
Airport
Code
Paul Bogard’s Flight Historian
Flightdiary
FlightMemory
OpenFlights.org
Dayton
DAY
42
42
42
42
Chicago (O’Hare)
ORD
16
32
32
32
Orlando (International)
MCO
12
12
12
12
Dallas/Fort Worth
DFW
10
17
17
17
Tulsa
TUL
10
10
10
10
Baltimore
BWI
5
10
10
10
Charlotte
CLT
5
10
10
10
Columbus, OH
CMH
5
5
5
5
Seattle/Tacoma
SEA
4
4
–
–
St. Louis
STL
4
4
4
4
Atlanta
ATL
3
6
6
6
For the sake of image size, not all of the above numbers are not in the screenshot; however, all of the airport counts in this table are available on their respective sites.
Note that the three right columns are in complete agreement with each other (other than that FlightMemory and OpenFlights only show their top ten airports). However, these are in many cases different from my FlightHistorian – I highlighted the differences in bold red text.
Why are they different?
Well, the airports that are different are all airports where I’ve had layovers in 2015. In many cases, the flight count is exactly doubled. (DFW is not quite doubled, but I had some trips where it was a layover and some trips where it was a destination. It only got double-counted on the trips where it was a layover.) The other three sites all appear to be double-counting my layover airports every time I have a layover.
Airport Visits vs. Flights Involving an Airport
Let’s say, for example, that I fly out of Dayton (DAY), have a layover at Dallas/Fort Worth (DFW), and land in Seattle (SEA).
Assume these two flights were the only flights I’ve ever taken. How many times would I have been to each of these airports?
As far as I’m concerned, I would have been to each of these three airports once. Even though DFW had two flights using it on this trip, I was still only there one time for my layover.
However, all three of the flight logging sites above would say that I’ve been to DFW twice:
Flight 1: DAY – DFWFlight 2: DFW– SEA
Effectively, what they’re all doing is counting the number of flights that involve a particular airport, rather than the number of visits to an airport. This may have been a deliberate design choice, but I find the number of times I’ve visited an airport to be the more useful of those two metrics. If we’re interested in airport visits, then layovers are being double counted.
But why would so many flight logging sites decide to count airports this way? Because counting flights with a particular airport code is much easier than figuring out what is and isn’t a layover.
What’s a Layover?
If you’ve flown a few times before, you probably understand what a layover is, but let’s try to define it explicitly.
Layover: When a traveler lands at an airport on one flight, and subsequently takes off from the same airport on another flight.
This is pretty easy for a flight log site to determine – just sort all the flights in chronological order, and look if the arrival airport of one flight is the same as the departure airport of the next.
Unfortunately, it’s not as simple as that. Let’s say I’m going to Seattle again. I land at SEA, I head into the city, and a few days later, I come back to SEA to fly home. Is that a layover? No, but by the above definition it is, so maybe we should modify it to say the flights have to be on the same day.
Layover: When a traveler lands at an airport on one flight, and on the same day takes off from the same airport on another flight.
This comparison is still pretty easy for a flight log site – sort the flights, check that the airports for two adjacent flights match, and also check that this pair of flights have the same departure date.
But there are a couple problems with this.
First, flights that are not on the same day could still be a layover. For example, I had a trip from Seattle to Chicago with a layover at Portland; the first flight was before midnight, and the second flight took off after midnight. The layover was less than two hours, but the flights were on different days, so this situation doesn’t fit the above definition of layover.
Secondly, just because two flights share the same airport on the same day doesn’t mean that they’re a layover. Imagine that I have an out-and-back, single day trip: I fly from Dayton to Chicago in the early morning, have meetings all day, and fly home from Chicago to Dayton the same evening. Both flights are on the same day, one flight lands at Chicago while the next takes off from Chicago, but it was not a layover – I spent the whole day away from the airport.
So maybe looking at the date is wrong, and we’d do better to look at whether or not we leave the airport:
Layover: When a traveler lands at an airport, and, without leaving the airport in between, takes off from the same airport on another flight.
This is actually the definition I use on my flight log. But looking at a list of flights, departure dates, departure airports, and arrival airports, how the heck does a flight log website know whether or not you left the airport? There’s really no way it can tell. Thus, flight log websites tend to ignore layovers completely and just count airport codes, with the consequence that all the layovers get their airport counted twice.
Enter the Trip Section
When I wrote my Flight Historian, I quickly realized that it wasn’t going to be able to figure out whether or not I left the airport between flights. I decided that I had to find a way to tell it, and I accomplished that with what I called “trip sections.”
But I took it further, and broke the trips into sections. Each section of the trip represented a complete, one-way journey from an origin to a destination, with as many layovers as necessary in between. Thus, using our final definition of layover, I needed to start a new trip section every time that I left an airport between two flights.
Every flight in my flight log records what trip it belongs to, and what section of that trip it falls in. The trip section is simply a number; I start with Section 1, and increment the number as high as it needs to go to describe my whole trip. (Right now, I have trips with only a single section, and trips with as many as six sections!) From there, all my software has to do is check whether two consecutive flights are in the same trip and same section number; if they are, then there’s a layover between them and their mutual airport should only be counted one time.
Parting Words
Of course, my goals with Flight Historian were not necessarily the same as any other flight log’s goals. It could be that they felt that counting flights involving each airport was more useful than counting visits to a particular airport, or it could be that they’d rather not make their users take the extra step of splitting their flights into trips and their trips into sections. All of these are valid.
But if any developer prefers the way I count airports, I’d recommend they consider implementing something similar to my trip sections!
It’s been over three years since I began working on my flight log. In that time, it’s gone from an interesting side feature of my Portfolio to a major project large enough to stand on its own. For the past month, I’ve been spending my free time working on spinning it off into its own site. Now announcing:
Every aircraft has a unique registration number, usually printed on or near the tail – think of it like a license plate for an airplane.
I track tail numbers on my flight log in order to let me keep track of whether I’ve been on a particular airplane before, and to let me know which particular airplanes I’ve flown on most often.
If you can see the tail number of your plane, great! But if you can’t see it, you can usually find the tail number with a bit of detective work.
One of the minor features I’ve added to the flight log is country flags for tail numbers. Every aircraft is registered to one country, and each country has its own assigned format for tail numbers, so it’s possible to look at each tail number and determine what country it’s from.
Since this operation is matching a string to a pattern, it made sense to create regular expressions for each country. For most countries, whose tail number is a unique prefix followed by a dash and three or four letters, this was easy to do. But the United States rules for valid tail numbers are substantially more complicated.
