gpsbabel-code

[Gpsbabel-code] IGC Format

[Kenneth V. <ke...@vo...>]

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.

-- 
Kenneth Voort
C-164 Mill Street South
Brampton, ON L6Y 1T6
m: (289)298-3602

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.
>

Re: [Gpsbabel-code] IGC Format

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

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.
>>

Re: [Gpsbabel-code] IGC Format

[Robert L. <rob...@gp...>]

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
>

Re: [Gpsbabel-code] IGC Format

[Kenneth V. <ke...@vo...>]

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

Re: [Gpsbabel-code] IGC Format

[Kenneth V. <ke...@vo...>]

Have a gander at the latest commit.

I added a boatload of other extensions. It's neat to graph things like 
altitude vs. temperature, or speed/vario vs. G load, or fix accuracy vs. 
satellites in use.

It's a lot of if ladders, and adding new extensions could be painful in 
the future - the logic and definitions are scattered all over the place 
- but, it works. I still would like to attach the IgcMetaData object, 
without the optional ExtensionDefinitions, to a route rather than 
individual waypoints, but this... works :)

Some code was generated by ChatGPT that I don't fully understand, 
particularly this block in igc.h:IgcMetaData:ExtensionDefinition:

   void setHasIgcExtsFlag() {
     for (auto& pair : extensions) {
       if (pair->exists) {
         flags.has_igc_exts = true;
         break;
       }
     }
   }

Which sets flags in the IgcMetaData->flags struct to True, when new 
ExtensionDefinition objects are added. I need someone else to have a 
look at this in particular, and take a good look at everything.

And then, while this works, it can generate rather large KML files. The 
next task is to include options (i.e. -o kml,oat=1,acz=1, etc) for the 
various extension data. There's so much of it that it that with a 
sophisticated flight recorder, the available data buttons scroll off the 
screen in Google Earth! I also have no idea how this could or could not 
fit into the GUI, I'm a command line guy who lives and breathes Debian.

Aside from wanting some command line/GUI options for all this, it is 
otherwise ready for inclusion, I think (although I still don't have 
tests set up).

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

Re: [Gpsbabel-code] IGC Format

[Kenneth V. <ke...@vo...>]

First, thank you all for bearing with me. I started this with some 
*very* out of date knowhow. It was a bit, I dunno.. difficult, in a few 
spots? I recognize and appreciate your expertise and guidance. While I 
am a very accomplished Python/Perl/Bash programmer, I haven't touched C, 
or anything compiled, in 20 years.

There's a few terms and acronyms in the postpasted conversation I don't 
understand: TDS, IR, "simplify filter", and then at the end of Steve's 
comment, I assume he's referencing something for which I lack necessary 
context (8.13 this and 11.5 that...).

---

Re: the proliferation of switches and those if ladders I hate so much:

The general principle this merge was written on is that I would like, 
eventually, for any changes to IGC extension data to be defined in 
/only/ the IGC header file. I think I managed that at least in igc.cc, 
with one or two tricks that Steve didn't quite take to. There's just too 
many of them to make the code maintainable if and when extensions change 
or if and when new ones come on to the scene - changes are needed in too 
many places. A lot of effort went into minimizing those future changes. 
Some kind of "extension data" data structure, initially built when 
parsing an IGC file, that could provide all the needed information for 
everything that works with it, is a stretch goal.

Re: merging of IGC data with Waypoint objects:

This one is difficult and worthy of a wholly separate discussion. Some 
are "obvious", such as Satellites In Use. Others are "intuitive" such as 
Outside Air Temperature. Others are "not obvious", such as Groundspeed. 
A speed metric is useless to a pilot without context - is it indicated 
airspeed, true airspeed, groundspeed, or mach (all of which can be 
wildly different, used for different purposes, and all of which some 
recorders record)?     (see aside)

Re: KML bloat

This one worries me a bit. Every commit I make seems to need a new 2 or 
3 MB reference file. Unless we find a way to minimize that, every future 
change I introduce will similarly bloat the repository and make it more 
difficult to clone and build. I do have an idea or two here; if I can 
fly with a reasonably modern recorder on a reasonably short flight, I 
can add the resulting IGC source and KML result as test cases. A simple 
training flight and then a short aerobatic flight could likely provide 
what we need. The aerobatic flight would cover what pilots call the 
"hysteresis test" (a method by which we validate and calibrate our 
instruments). I can probably make that happen this year.

Re: figuring out which extensions are present, after initial parsing:

We keep dancing around this... it's a serious limitation. Currently, 
when writing KML (and I assume when writing other formats if this logic 
is extended to them), each and every individual Waypoint is examined, 
and if some extension data exists on any of them, a flag is set. Later, 
that flag is used when determining which SimpleArrays to build. It's 
just a bad way to do it; it's inefficient and unfollowable (IMO). That 
data - whether or not Engine Noise or Total Vario data etc exists - 
should be attached to the route object, not parsed from individual 
Waypoints. Changing that is a tall order and would require me to go 
beyond the IGC box that I'm pretty safe in right now.

Additionally, I feel I'm running into a sort of logic that was designed 
for future use, back when fitbits and fancypants dive watches came on to 
the scene - but it seems a bit... unfleshed. A lot of my work was trying 
to fit my crazy IGC data into existing structures, and making sure I 
didn't step on anything else. I really feel that the whole *fsdata idea 
could be better used and expounded upon. The skeleton seems to be there, 
but it's just not used much.

Again, thank you all for bearing with me as I explore a language I 
haven't used in decades, and as I jump in on a similarly decades old 
project. I have many ideas.

---

(aside and a bit pilot-technical)

I suppose the biggest "speed" hangup I have is that "speed" is useless 
to a pilot without context. "Indicated" airspeed is a literal measure of 
how many air molecules are impacting your aircraft in terms that humans 
can understand. It's used to determine stall speed, Vne (never exceed 
velocity), stuff like that - it measures performance. "True" airspeed is 
a measure of movement through the air. It's the product of indicated 
airspeed and barometric pressure (at 20,000 feet, the air is thinner, 
ergo fewer air molecules to hit your airspeed indicator). It's used to 
make navigation calculations - it measures movement. "Groundspeed" is 
used to relay an ETA to air traffic control, which needs to be estimated 
plus or minus five minutes or so - it measures time. It's the sum of 
True Airspeed and wind. "Mach", meh, not so important for anyone using 
GPSBabel, but it's a measure of how much the air pressure in front of 
you affects your flight performance - it measures the accuracy of all 
the above. We just can't express "speed" as a single value.


GPSBabelDeveloper wrote:

Thank you for carrying this conversation, tsteven4, and your willingness 
to cultivate this set of changes, PacketFiend. Reviewing the changes, 
I'm pretty happy with the results. It's a good of modern data 
structures. The resultting use of kt_simple_array (and the graphing in 
Earth) is very gratifying., I'm a little torn on the multiple switch 
statements for selecting and modifying data structures, but they don't 
bum me out. I know those got kickballed around a lot here, so they're 
presumably less straight-forward to replace than it sounds. 
Stylistically, I'd write has_igc_tas = fs_igc->tas.has_value() instead 
of if (thing that might be true) foo = true I'd hope that SSA lowering 
would reduce them to be equivalent in the IR. In the future, if we have 
large reference files, we might consider filtering the reference files. 
A pass through the simplify filter would probably not change the 
material parts of this test. I'm very happy with this. Thank you, crew!

tsteven4 wrote:

I'm pretty happy as well. I wouldn't let the switch statements bum you out.

We likely will have to deal with kml bloat. If it was just turn off igc 
arrays that would be easy, but it sounds like it might be more of a 
selection of a group of igc extension data which is a bit more involved. 
I guess there is a limit though: I think I records are limited to 99 
characters, and there can only be one I record => at most 13 extensions 
in one file. Of course we could read multiple files and encounter more 
types between them.

It would be good to get some of the IGC data into Waypoint fields. We've 
spent a lot of effort getting better resolution of time, down to a 
millisecond. If IGC files exist with TDS data it would be good to use 
that data. etc. for SIU, LOD, LAD, OAT. I haven't found a file with TDS, 
LOD or LAD, but perhaps you can. No that other writers like unicsv and 
xcsv have a chance at using any data member from Waypoint, but using 
format specific data requires work like you just did for the kml writer.

    Stylistically, I'd write has_igc_tas = fs_igc->tas.has_value()
    instead of if (thing that might be true) foo = true

That would introduce a bug, has_igc_tas would just be set based only on 
the last waypoint instead of being true if any waypoint has the data. 
These statements are in a loop over waypoints. The input can be 
accumulated from various read operations, so the values might not be the 
same for every waypoint.

But it is tempting to
has_igc_type |= fs_igc->tas.has_value();

with both sides being of type bool

This is a bitwise inclusive or compound assignment operator, not a 
logical or.
bitwise inclusive or (8.13) does the usual arithmetic conversions.
usual arithmetic conversion (11.5) calls for integral promotions (7.6), 
which converts false to integer 0 and true to integer 1.
so it should work, but that's a lot of chasing through the "Standard for 
Programming Language C++".

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

-- 
Kenneth Voort
C-164 Mill Street South
Brampton, ON L6Y 1T6
m: (289)298-3602