Re: [Gpsbabel-code] IGC Format
Brought to you by:
robertl
From: tsteven4 <tst...@gm...> - 2023-03-28 14:05:19
|
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. > |