Re: [Gpsbabel-code] IGC Format
Brought to you by:
robertl
From: Kenneth V. <ke...@vo...> - 2023-03-29 00:19:20
|
No, every point absolutely does *not* need the igc_fs_flags_t struct. That needs improvement. It's there because I was able to get things to work that way, and I didn't want to push a broken pull request. If a flight log uses an extension, then that extension data will be present in every entry (notwithstanding technical glitches) - to be specific, every B record. It gets a little murkier with a few extensions, but for now I'm only concentrating on information present in every B record. It would be far better to have the igc_fs_flags_t struct in a route or route_head object, rather than every waypoint. Then we can do something like (pseudocode): if route->igc_fs_flags_t; then /* do all the fancypants IGC stuff */ else We don't need any of that crap, this is data is from a pair of fancypants binoculars fi I don't know how what I'm pulling from the IGC files is passed to the filters yet. I assume the "route" concept is constructed before we head over to the KML module but I don't know for sure. The long and short is: * igc_fsdata is necessary on every waypoint but superfluously contains igc_fs_flags_t * igc_fs_flags_t contains two kinds of data: o Start and end bytes of each extension. This can be discarded once we're done parsing the IGC file. o booleans indicating the presence of extension data. This should be attached to a route rather than a waypoint object I'll see what I can whip up for that. I spent a bit of time figuring out QHashes and banging my head against a wall because I didn't quite recall the limitations of switch statements today: https://github.com/GPSBabel/gpsbabel/commit/c4eda716ce49ccf27f8ace70f44dda1eea93c480 On 2023-03-28 18:44, Robert Lipe wrote: > 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 > > > > _______________________________________________ > Gpsbabel-code mailing listhttp://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code |