Re: [Gpsbabel-code] IGC Format
Brought to you by:
robertl
From: Robert L. <rob...@gp...> - 2023-03-28 22:44:42
|
More later, but I merged a change to Kenneth's branch that fixes the test suite for these new files: https://github.com/GPSBabel/gpsbabel/pull/1054/commits/bc769c8055f77af4543144133d1c9baf15e751a1 I also did some scratching in how we might want to parse those extended records. https://github.com/PacketFiend/gpsbabel/pull/1 I don't know that this is the final/correct form, but it's better than scanf, IMO. Just for size purposes, I still really need to better understand the relationships between points (our fundamental location object) igc_fs_flags_t (each point can have zero or more of these) and records like enl. Does every location point potentially have each of an enl, fxa, and so on ? Why do we need to carry start and stop around during the life of a Point? I don't want to deraiil thread (welcome!) with code design/review notes; I just wanted to let everyone know that we're starting to kick some of these bits around in earnest. But to the point of this thread, an active user/maintainer of this format is exactly what it needs for life support. Oh, be sure to find the xmldoc dowwn ixmldoc/formats/fmt_kml.xml and the individual flags one directory leve down from that. Welcome. RJL On Tue, Mar 28, 2023 at 9:18 AM tsteven4 <tst...@gm...> wrote: > 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" > <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://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" > <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://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. > > _______________________________________________ > Gpsbabel-code mailing list http://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code > |