Re: [Gpsbabel-code] IGC Format

[tsteven4 <tst...@gm...>]

Kenneth,

It is good to hear from users like you, especially those representing a 
group of users and one willing to contribute pull requests.  The IGC 
format is fortunate in that a public specification 
<https://www.fai.org/sites/default/files/igc_fr_specification_with_al8_2023-2-1_0.pdf> 
exists.  Given the general interest in IGC you attest to, your 
willingness to help with the code, and the availability of a public 
specification I support the retention of the IGC format in GPSBabel.

KML has a schema definition that allows automated validation, and we do 
some checking of our reference files in our regression tests.  One 
validator is at https://www.freeformatter.com/xml-validator-xsd.html, 
although I have not used it.  It is important the validator has access 
to all the xsd files, e.g. atom-author-link.xsd,  kml22gx.xsd, 
ogckml22.xsd,  xAL.xsd.

Steve

On 3/27/2023 11:41 PM, Kenneth Voort wrote:
> 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.
>