Re: [Gpsbabel-code] IGC Format
Brought to you by:
robertl
From: tsteven4 <tst...@gm...> - 2023-03-28 14:18:18
|
I ran your recent kml reference files by my validator, they are valid. > $ ~/local/bin/StevesDOMCount -v=always -n -s -f > -sc=/home/tsteven4/schema -slp=km > l22 reference/track/92HV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > reference/track/92HV66G1.igc.kml: 71 ms (14937 elems). > tsteven4@PEDALDAMNIT:~/work/packetfiend$ ~/local/bin/StevesDOMCount > -v=always -n -s -f -sc=/home/tsteven4/schema -slp=kml22 > reference/track/92GV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > reference/track/92GV66G1.igc.kml: 43 ms (4461 elems). On 3/28/2023 8:05 AM, tsteven4 wrote: > > 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. >> |