[Gpsbabel-code] IGC Format

[Kenneth V. <ke...@vo...>]

Hello,

I recently posted a pull request to Github that can read engine noise 
data from IGC files. I also heard that that IGC support is potentially 
on the chopping block.

Far from removing it, there's actually a few features I'd like to add to 
the IGC module. Chief among them is the ability to add the ability to 
extract various extension data from these files. There are several 
extensions that are of particular interest to (para)glider pilots, such 
as "engine noise level" (an indication of cheating during a contest, if 
you have a motorglider) and "total energy variometer" (an instrument 
that tracks the product of Δheight*Δspeed). I'm quite happy to add the 
necessary code and update existing code where necessary to accomplish 
this. I'd also like to eventually add filters that can compute various 
data, like inferring wind speed and vertical speed and G load, or 
detecting when a glider has begun "thermalling" (circling in a rising 
bubble of hot air to gain height).

My soaring club is using GPSBabel in our flight recorders as part of our 
accounting system, or at least we're hoping to implement it this year or 
next. The idea is that every club glider will be equipped with some kind 
of raspberry pi powered homebrew flight recorder, which when parked in 
our hangar, will upload its flight data somewhere (we're not sure where 
yet, it may happen locally) and get it converted into CSV format for 
entry into our billing system. We're also hoping it can somehow be 
adapted to analyze training and aerobatic flights, and overlay them onto 
Google Earth for demonstration purposes. I realize you don't hear a lot 
about people using GPSBabel's IGC module, but I can assure you, it most 
certainly *is* used, extensively - just not by the type of people who 
post to Sourceforge mailing lists or make commits on Github.

Generally speaking, glider pilots and clubs use proprietary software of 
some sort to analyze their IGC files, or they upload them to 
https://www.onlinecontest.org, an international free service that awards 
competition "points" for flights and curates world records for pilots 
not flying in competitions. Outside of that, we very much all rely on 
GPSBabel in one way or another to analyze those files. Unfortunately, 
the sport tends to attract the "technologically challenged" type of 
person, so I get the feeling GPSBabel is not benefiting much from our use.

I'm personally hoping to use it as a way to import various data into 
Google Earth. I have a talk coming up with a local flight school and I 
would like to show a bunch of flights, as a way to dispel, to people who 
only fly powered aircraft, just how capable a modern glider really is. I 
digress, but that's where my original interest in this project came 
from. And then I noticed a few features it didn't have that I wish it 
did, and you all know how that goes.

I haven't written anything in C++ in a dog's age, so please bear with me 
while I readjust. Contributing to a project written in C++ is also be a 
way to keep my skills sharp there, so I'm very happy to do so (it looks 
good on a resumé, too). I'm also working on a module that looks like it 
hasn't been maintained since 2005 or so, so I'm in the middle of a bunch 
of very, very old code, with little context. Feel free to be brutal and 
recommend all kinds of changes to this and any future pull requests.

One observation - the KML code is very difficult to follow. XML tags 
aren't closed in the same block of code they're opened in a lot of cases 
(nor are there comments explaining where they're closed if it's in 
another function), so it becomes very difficult to figure out why the 
KML I generate is invalid. Opening and closing tags should reside in the 
same function that writes the relevant KML wherever possible, IMO. Not 
that I want to rain on the parade, but I feel that's a useful observation.

-- 
Kenneth Voort
C-164 Mill Street South
Brampton, ON L6Y 1T6
m: (289)298-3602