Every pilot works hard to maintain good records of their flight time. Besides being expensive to obtain, the FAA requires that flight time of a certain nature be logged and available for inspection, should it ever be required or questioned. The pertinent regulation gives a description of what information must be logged, but leaves the method up to the individual pilot.
Being a bit of a technologist, I wanted a system for logging flight data that would give me maximum flexibility for manipulating the statistics. And so, my own version of an online flight log was born. I built it using Playdoh, Mozilla’s Django-Plus framework. The application is a very simple CRUD application, but it’s not the input of data that’s interesting; it’s the way it’s displayed.
At A Glance Period Reports
As is true for almost every bureocracy in the world, the information you’re required to keep and the information you’re required to supply later are in fact different. The FAA requires that pilots report solo time, night takeoffs and landings, and other information that isn’t necessarily logged. However, it is possible to extrapolate some of this data with a little bit of knowhow. And so I created some MySQL queries that extract precisely the data I need.
Much of the data I pull out can be computed by directly extracting the data from the logs. But other data, like solo time, requires a bit of effort. To manage solo time, I added a checkbox for “solo time”. Because some solo time is logged together with other kinds of time (namely, dual received), I wrote a MySQL script that counts only the pilot-in-command time for a solo checkbox. This gives me an easy way to know exactly how much solo time I have logged, when the time comes to apply for another rating.
The Instrument Rating I’m working on also requires 50 hours of cross country time as pilot in command. A cross country is a flight exceeding 50 nautical miles from the point of departure. However, the logbook only has one column for cross country time, and that includes cross country instruction. Again, with a bit of creativity I was able to determine precisely how much time was spent as pilot in command by evaluating two fields: the total cross country time when both the cross country and pilot in command fields are greater than zero.
Am I Current? How Is My Current Rating Going?
There are certain requirements for a pilot to maintain currency, especially if the pilot is going to carry passengers. I’m required to conduct three takeoffs and landings every ninety days in the conditions of the flight in order to carry passengers. This means daytime for a day flight, and night time for a night flight.
I also wanted to know whether or not I was making progress towards my next rating – an instrument rating. So I utilized data I already had to determine whether or not I was making progress.
Since all of this data exists in the application there was no need to go back to the database and fetch it. I simply needed to present already-present data in a new way. The only data in the database is the 250 nm cross country flight. I used a little jQuery to turn the cells red for areas in which I am deficient. Since I’m only about half-way to an instrument rating, I’m still deficient in each of those areas (no flying in the clouds for me).
How do I know if a flight is 250 nm anyway?
In order to have the system automatically know how long my flights are, I had to come up with a system to determine precisely how far each point is from another. This is relatively straightforward to do if you know the location of each airport. Lucky for me, the FAA has a database of airports in the United States (my tax dollars at work) on their website. With a little PHP magic I converted the list into a database. Then I got to work.
Since I wanted to update the distance every time the individual records were updated (rather than calculating it every time the pages were loaded, since distances never change), I wrote a form cleaner that automatically calculated the distances between the airports listed in the route. I used GeoPy to calculate the distances from longitude and latitude. The code is below:
def clean_flight_distance(self): if self.cleaned_data['route']: route = self.cleaned_data['route'].split(' ') else: route =  starting = self.cleaned_data['starting_airport'] starting = Airport.objects.get(airport_id = starting) total = 0 route.append(self.cleaned_data['ending_airport']) for x in route: try: next = Airport.objects.get(airport_id = x) starting_point = Point(starting.latitude, starting.longitude) next_point = Point(next.latitude, next.longitude) addition = distance.distance(starting_point, next_point).nm total = total + addition starting = next except Airport.DoesNotExist: raise ValidationError('The airport %s does not exist.' % x) return round(total, 2)
The end result is a relatively accurate measurement of distance between the airports. Fun fact: I’ve flown 4,153.53 nautical miles as of the writing of this post.
So when do I fly most?
I also wanted to answer the question of “when do I fly the most?” To answer this I built a “year at a glance” chart to show me flying by month.
I flew a tremendous amount last October as I prepared for my first FAA checkride, but the winter months proved to be lacking (the display even shows 13 months because one month I logged no time at all; this is a bug I’m unsure how to fix). Still, the image allows me to easily know when the last time I did a particular type of flying happened to be.
My app works well but it’s far from complete. Regulatory requirements for instrument currency require that I log my instrument approaches, so I’ll probably add the ability to log specific approaches. Also, right now there’s no way for an instructor to sign my logbook, something that keeps me from replacing my paper logbook completely. I’d like to add the ability to graph the flight times and improve search (right now searching for 1.0 doesn’t do much good). The app is also built for a single user, meaning it could never be opened up to more people besides myself. I’d also like to improve the way that data is calculated for the dashboard; the data changes infrequently, so it should be updated when the logbook is updated, and/or once every 24 hours for the period reports. However, from a single-user standpoint, the load is irrelevant.
Be the first to get Modern Object-Oriented PHP!
Long to learn how you can develop modern applications using object-oriented PHP? Curious about how to apply all these best practices to your code?
Modern Object-Oriented PHP is a brand-new book focused on teaching you the techniques you need for writing modern, well-designed object-oriented applications!
The book lands in April. Sign up today for a sample chapter plus special launch day discounts!