gpsbabel-code — Discussions about development of gpsbabel

Re: [Gpsbabel-code] Error in garmin.cc

[tsteven f. <tst...@gm...>]

Thanks.  As you pointed out the check is problematic.   However I would
expect assertions to be disabled in release code.  Can you try the snap at
https://github.com/GPSBabel/gpsbabel/releases/tag/Continuous-Linux ?  If
that works OK it would imply Ubuntu mate has a build problem as well as the
problematic check.

On Mon, Jul 8, 2024, 10:47 PM Dirk <di...@di...> wrote:

> Hi!
>
> I'm using GPSBabel with a Garmin eTrex H. Recently updated to Ubuntu MATE
> 24.04 LTS and since then GPSBabel crashes with the following error message:
>
> gpsbabel: ./garmin.cc:380: void rw_init(const QString&): Zusicherung
> »!QString(valid_waypt_chars).contains('-')« nicht erfüllt.
>
> '-' can be a valid waypoint character for some older Garmin devices as
> correctly defined in garmin.cc. Hence line 306 of the current garmin.cc
>
> assert(!QString(valid_waypt_chars).contains('-'));
>
> makes GPSBabel unusable for those devices.
>
> Regards
>
> Dirk
>
> _______________________________________________
> Gpsbabel-code mailing list  http://www.gpsbabel.org
> Gps...@li...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>

[Gpsbabel-code] Error in garmin.cc

[Dirk <di...@di...>]

Hi!

I'm using GPSBabel with a Garmin eTrex H. Recently updated to Ubuntu 
MATE 24.04 LTS and since then GPSBabel crashes with the following error 
message:

gpsbabel: ./garmin.cc:380: void rw_init(const QString&): Zusicherung 
»!QString(valid_waypt_chars).contains('-')« nicht erfüllt.

'-' can be a valid waypoint character for some older Garmin devices as 
correctly defined in garmin.cc. Hence line 306 of the current garmin.cc

assert(!QString(valid_waypt_chars).contains('-'));

makes GPSBabel unusable for those devices.

Regards

Dirk

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

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

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

[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

[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

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

[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] Windows_Drag_and_Drop

[Kristian K. <kk...@kr...>]

Many thanks for the reply and for the nice program.

BTW, also probably elementary for some,
gpsbabel.exe needn´t be in the %PATH% ; 
and the batch file need not be in the same directory as gpsbabel.exe 
(provided that the batch file contains the absolute path to the exe file); 
but the batch file can usefully be in the %PATH% ; 
then it can be used at the CLI anywhere.

Sincerely, Kristian Kjær

Re: [Gpsbabel-code] Windows_Drag_and_Drop
From: Robert Lipe <rober...@gp...> - 2023-01-19 22:49:57

> Yes, you're certainly right. Congratulations for apparently being the first
> one in 15 years to read that page. The fact that it recommends NT and XP as
> the NEW options gives you some idea how long that page has been around. :-)
> I've updated the master, but it'll take some time for that to go live.
> 
> Since that was added, we actually have some amount of drag and drop
> recognition in the GUI. If your file has an extension that we can
> authoritatively associate with one format (so "gpx" but not "wpt", which is
> used with a couple of formats) you can drag it to the GUI and we'll spin
> the input to the right type and accept the filename to be the drop target.
> We can't guess the output filename and format, but once you choose an
> output format, we'll remember that for the next time.
> 
> We still can't match the zero click of a specialized batch file, so IMO you
> found the optimal way for your case. I'm just letting you know we try to
> help with some other cases.
> 
> Enjoy.
> RJL

On Thu, Jan 19, 2023 at 10:28 AM Kristian Kjaer <kk...@kr...> wrote:

> > (I hope this is the appropriate mailing list.)
> > On     https://www.gpsbabel.org/os/Windows_Drag_and_Drop.html     I read:
> >
> > @echo off
> > for %%A in (%*) DO (
> > gpsbabel.exe -i gpx -f %%A -o s_and_t -F "^%%~dpnA".csv
> > }
> >
> > I think the caret should be removed and the final bracket should be round,
> > not curly.
> > I ended up with
> >
> > GarminFitToGpx.bat:
> > for %%A in (%*) DO (
> > c:\absolute\path\to\gpsbabel.exe -i garmin_fit -f %%A -o gpx -F
> > "%%~dpnA".gpx
> > )
> >
> > BTW, a shortcut
> >
> > C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\SendTo\GarminFitToGpx.bat.lnk
> > conveniently allows right-click action.
> >
> > Sincerely, Kristian Kjær

Re: [Gpsbabel-code] Windows_Drag_and_Drop

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

Yes, you're certainly right. Congratulations for apparently being the first
one in 15 years to read that page. The fact that it recommends NT and XP as
the NEW options gives you some idea how long that page has been around. :-)
I've updated the master, but it'll take some time for that to go live.

Since that was added, we actually have some amount of drag and drop
recognition in the GUI. If your file has an extension that we can
authoritatively associate with one format (so "gpx" but not "wpt", which is
used with a couple of formats) you can drag it to the GUI and we'll spin
the input to the right type and accept the filename to be the drop target.
We can't guess the output filename and format, but once you choose an
output format, we'll remember that for the next time.

We still can't match the zero click of a specialized batch file, so IMO you
found the optimal way for your case. I'm just letting you know we try to
help with some other cases.

Enjoy.
RJL



On Thu, Jan 19, 2023 at 10:28 AM Kristian Kjaer <kk...@kr...> wrote:

> (I hope this is the appropriate mailing list.)
> On     https://www.gpsbabel.org/os/Windows_Drag_and_Drop.html     I read:
>
> @echo off
> for %%A in (%*) DO (
> gpsbabel.exe -i gpx -f %%A -o s_and_t -F "^%%~dpnA".csv
> }
>
> I think the caret should be removed and the final bracket should be round,
> not curly.
> I ended up with
>
> GarminFitToGpx.bat:
> for %%A in (%*) DO (
> c:\absolute\path\to\gpsbabel.exe -i garmin_fit -f %%A -o gpx -F
> "%%~dpnA".gpx
> )
>
> BTW, a shortcut
>
> C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\SendTo\GarminFitToGpx.bat.lnk
> conveniently allows right-click action.
>
> Sincerely, Kristian Kjær
>
>
>
>
> _______________________________________________
> Gpsbabel-code mailing list  http://www.gpsbabel.org
> Gps...@li...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>

[Gpsbabel-code] Windows_Drag_and_Drop

[Kristian K. <kk...@kr...>]

(I hope this is the appropriate mailing list.)
On     https://www.gpsbabel.org/os/Windows_Drag_and_Drop.html     I read:

@echo off
for %%A in (%*) DO (
gpsbabel.exe -i gpx -f %%A -o s_and_t -F "^%%~dpnA".csv
}

I think the caret should be removed and the final bracket should be round, not curly.
I ended up with

GarminFitToGpx.bat:
for %%A in (%*) DO (
c:\absolute\path\to\gpsbabel.exe -i garmin_fit -f %%A -o gpx -F "%%~dpnA".gpx
)

BTW, a shortcut 
C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\SendTo\GarminFitToGpx.bat.lnk
conveniently allows right-click action.

Sincerely, Kristian Kjær

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Greg T. <gd...@le...>]

Thanks.  Two more things that might be helpful at the risk of off topic
even though I suspect most subscribers would be at least dimly
interested:

  In addition to QField [lCheck out Mergin (formerly Input in part) and
  SMASH, formerly geopaparazzi

  You said M9, but I suggest that you alsl look at the F9P, which does
  RTK.  Ardusimple and sparkfun sell kits.  Interfacing and getting RTCM
  into it, from someplace is fairly tricky.  But RTK accuracy is amazing
  -- I've had 4 cm return-to-point-days-later results.  You won't get
  anything like that with a navigation solution.

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

thanks for the info and I apologize for some inappropriate phrases of mine.

Roberto

Il giorno dom 31 lug 2022 alle ore 13:56 Greg Troxel <gd...@le...> ha
scritto:

>
> Geo DrinX <geo...@gm...> writes:
>
> >> > I am sure it is a standard gps NMEA sentence file format, but... how
> to
> >> > successfully read it?
> >>
> >> You are sure because
> >>   1) you read the documentation and it says it is NMEA, and if so which
> >> version?
> >>   2) you looked at the data stream and it looks like NMEA?
> >>   3) something else?
> >>
> >
> > none of this. Perhaps I have simply misunderstood the data in my
> possession.
>
> Obviously I wasn't blunt enough.  You made a claim that you were "sure",
> which I thought was unwarranted -- and it seems I was correct.  I gave
> two actual reasonable and plausible possibilities and "something else"
> was meant as "so if it isn't 1 or 2, why do you believ this" and then
> you didn't answer the question.  When asking for help politeness demands
> straightforward answers to reasonable, on-point questions, even if it's
> "actually I was confused and I have no basis to believe anything; I'll
> go figure it out".
>
> > Obviously, I also requested support from QGIS,
>
> It's not obvious.  The only thing that's clear by now is that you have
> provided much less information than is appropriate and that you have
> declined to answer reasonable questions.  If you had filed a bug with
> qgis, you should have provided a URL to the issue, and you should have
> described exactly what you did in the issue.
>
> > but for now they are not very interested in letting people know that
> > there is something wrong with the gps reading.
>
> I am not surprised that your interaction there did not go well, given
> this discussion.
>
> > Maybe it's complicated to fix, or it's just me, and therefore has a very
> > low priority in their bug fix list.  Wnho knows?
>
> I think it's mostly you and partly that the docs are not clear enough in
> one small section.
>
> First, the qgis docs say:
>
>   1) For loading vector data *from files or from storage in devices*
>        - native is GPX
>        - it can use GPSBabel to read other formats
>        - it can use GPSBabel to download waypoints/tracks
>
>
> https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html
>
>   2) For live tracking, the options are:
>        - serial device
>        - gpsd
>      What is unsaid is what is normal these days and really has been for
>      a very long time: devices connected by serial are expected to
>      output NMEA.  And, they say that it works with gpsd, and gpsd's
>      mission is to read real-time data from any device and transform it
>      into standard form.
>
>
> https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/live_GPS_tracking.html#gps-options
>
>   I used an M8 (vs M9) with qgis via gpsd at some point and it worked
>   straightforwardly (on NetBSD; you seem to be using Windows and I have
>   zero experience with GNSS devices or qgis on Windows).  In fact, I
>   have zero idea if gpsd runs on Windows.  I do know that the people who
>   maintain it don't use Windows.
>
> Second, u-blox provides hundreds of pages of docs about the formats
> spoken by their devices and how to configure them.  They provide a
> zero-cost proprietary program u-center that does that configuration.
> You seem not to have read the docs.
>
> Third, one can connect to the device with kermit etc. and look at it.
> Surely if you've written a plugin you know that you should do this and
> you know how.
>
> The qfield docs also fail to state that external GNSS receivers are
> expected to speak NMEA:
>
>   https://docs.qfield.org/how-to/gnss/
>
> but of course that is how it is.  That also works, with an F9P, which is
> pretty similar to an M9.
>
>

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Greg T. <gd...@le...>]

Geo DrinX <geo...@gm...> writes:

>> > I am sure it is a standard gps NMEA sentence file format, but... how to
>> > successfully read it?
>>
>> You are sure because
>>   1) you read the documentation and it says it is NMEA, and if so which
>> version?
>>   2) you looked at the data stream and it looks like NMEA?
>>   3) something else?
>>
>
> none of this. Perhaps I have simply misunderstood the data in my possession.

Obviously I wasn't blunt enough.  You made a claim that you were "sure",
which I thought was unwarranted -- and it seems I was correct.  I gave
two actual reasonable and plausible possibilities and "something else"
was meant as "so if it isn't 1 or 2, why do you believ this" and then
you didn't answer the question.  When asking for help politeness demands
straightforward answers to reasonable, on-point questions, even if it's
"actually I was confused and I have no basis to believe anything; I'll
go figure it out".

> Obviously, I also requested support from QGIS,

It's not obvious.  The only thing that's clear by now is that you have
provided much less information than is appropriate and that you have
declined to answer reasonable questions.  If you had filed a bug with
qgis, you should have provided a URL to the issue, and you should have
described exactly what you did in the issue.

> but for now they are not very interested in letting people know that
> there is something wrong with the gps reading.

I am not surprised that your interaction there did not go well, given
this discussion.

> Maybe it's complicated to fix, or it's just me, and therefore has a very
> low priority in their bug fix list.  Wnho knows?

I think it's mostly you and partly that the docs are not clear enough in
one small section.

First, the qgis docs say:

  1) For loading vector data *from files or from storage in devices*
       - native is GPX
       - it can use GPSBabel to read other formats
       - it can use GPSBabel to download waypoints/tracks

  https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html

  2) For live tracking, the options are:
       - serial device
       - gpsd
     What is unsaid is what is normal these days and really has been for
     a very long time: devices connected by serial are expected to
     output NMEA.  And, they say that it works with gpsd, and gpsd's
     mission is to read real-time data from any device and transform it
     into standard form.

  https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/live_GPS_tracking.html#gps-options

  I used an M8 (vs M9) with qgis via gpsd at some point and it worked
  straightforwardly (on NetBSD; you seem to be using Windows and I have
  zero experience with GNSS devices or qgis on Windows).  In fact, I
  have zero idea if gpsd runs on Windows.  I do know that the people who
  maintain it don't use Windows.

Second, u-blox provides hundreds of pages of docs about the formats
spoken by their devices and how to configure them.  They provide a
zero-cost proprietary program u-center that does that configuration.
You seem not to have read the docs.

Third, one can connect to the device with kermit etc. and look at it.
Surely if you've written a plugin you know that you should do this and
you know how.

The qfield docs also fail to state that external GNSS receivers are
expected to speak NMEA:

  https://docs.qfield.org/how-to/gnss/

but of course that is how it is.  That also works, with an F9P, which is
pretty similar to an M9.

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[<geo...@gm...>]

>> Google Earth has been my myth since it was born.  :)

Incidentally, I write a narration book, inspired to Jim Gray story of 2008 (he disappears in the ocean, near Farallon Island).
Search with “Roberto Angeletti GeoDrinX the Simple Story” (is an italian book, but I am publishing in english soon)

Also, look at my blog of the book:

geodrinx.blogspot.com

and you can see the presentation video in english language, also. 

It is an humor triller. 

:)

A presto

Roberto

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

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

>
> gpsbabel -t -i m241 -f COM4 -o kml -F
> c:\Users\Asus\Documents\AreaLavoro\Lavoro20220730_gps\UBlox_LOG_20220730.kml
> mtk_logger: This is not a MTK based GPS ! (or is device turned off ?)
>

If it's NMEA, use nmea instead of m241, like I said in the first message.
But you've waffled between ublox binary protocol and NMEA, so we don't know.

The only reason we do it at all is because Google contracted me to add it
>> years ago for Earth. :-)
>>
>
> Google Earth has been my myth since it was born.  :)
>

It was my day job for ~13 years even after i added the realtime and Garmin
USB modes for Google in '05 and '06 during the Earth 3 and Earth 4 beta
periods. I later worked there until my body failed.

While I still have friends left on the project, I'm not exactly coupled
with it these days.



>
>> This is also, not coincidentally, how realtime GPS tracking works in
>> Google Earth.
>>
>
> Wow, I'll try your gps input in Google Earth right away (you never know it
> reads my U-Blox too :)
>

If it's the UBlox binary format, I'll about guarantee it doesn't. Earth's
GPS and (non KMZ/KML) file handling all goes through GPSBabel.  But things
can change.

RJL

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

Il giorno dom 31 lug 2022 alle ore 06:44 Robert Lipe <
rob...@gp...> ha scritto:

> That's two of us that have failed to get an actionable question from you.
>
> Apart from that, now I'm working on using a high resolution gps, such as
>> the U-Blox EVK-M91, to perform surveys via QGIS and QField (which is the
>> android version of QGIS). Basically, I have to use the U-Blox as a mouse :)
>>
>
> We're not an Android app. Becoming an Android app is non-trivial.
>

actually, I don't know how QField reads gps. Evidently not via gpsbabel...


> So, I installed a gpsBabel and I went to analyze why gpsBabel returns
>> error, and what were the right parameters
>>
>
> If you're a programmer yourself, you know that data like the contents of
> that error are pretty important. Taking your car to the shop and saying "it
> makes a funny sound" is less productive than "it makes a funny sound while
> accelerating up a hilll in a sharp left turn". Those details matter a LOT.
>

I know, but I didn't want to be too verbose at first

BTW, these are the log of messages that I have:

gpsbabel -t -i m241 -f COM4 -o kml -F
c:\Users\Asus\Documents\AreaLavoro\Lavoro20220730_gps\UBlox_LOG_20220730.kml
mtk_logger: This is not a MTK based GPS ! (or is device turned off ?)

gpsbabel -t -i globalsat -f COM4 -o kml -F
c:\Users\Asus\Documents\AreaLavoro\Lavoro20220730_gps\UBlox_LOG_20220730.kml

Traduzione terminata con successo

Of course I tried any "Dispositivo" listed in the "Formato" optionBox
(sorry, I am using italian version) and so the first message sure is for a
wrong device, I know.
The second message, instead, returns success, but KML contains no
coordinates  :(

The only reason we do it at all is because Google contracted me to add it
> years ago for Earth. :-)
>

Google Earth has been my myth since it was born.  :)
Did you know my GEarthView plugin for QGIS 2.x.x ?
Thousands of QGIS users used it
(405213 downloads  https://plugins.qgis.org/plugins/most_downloaded/ )

https://plugins.qgis.org/plugins/gearthview/

and this is the current port to QGIS version 3:

https://github.com/geodrinx/gearthview3

https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html
>
> Their examples use everything but NMEA, but that works in the "obvious"
> (once paired with the links I sent yesterday) command lines.
>
> This is also, not coincidentally, how realtime GPS tracking works in
> Google Earth.
>

Wow, I'll try your gps input in Google Earth right away (you never know it
reads my U-Blox too :)

Grazie e a presto

Roberto

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

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

That's two of us that have failed to get an actionable question from you.

Apart from that, now I'm working on using a high resolution gps, such as
> the U-Blox EVK-M91, to perform surveys via QGIS and QField (which is the
> android version of QGIS). Basically, I have to use the U-Blox as a mouse :)
>

We're not an Android app. Becoming an Android app is non-trivial.

You probably want a GPS logger and not an eval board. Carrying a laptop and
trying to catch the bits live is an unnecessary distraction. I'd suggest
finding one of these that writes the NMEA sentences to a memory card so you
can read plain old NMEA files - either with GPSBabel or whatever parser
arouses you.

We don't do uBlox binary protocol, either streamed or logged.


> I tried to use the standard QGIS functions to read the coordinates from
> gps, but it doesn't work. Investigating, I saw that QGIS simply uses
> gpsBabel to take a single point at a time.
>
> So, I installed a gpsBabel and I went to analyze why gpsBabel returns
> error, and what were the right parameters
>

If you're a programmer yourself, you know that data like the contents of
that error are pretty important. Taking your car to the shop and saying "it
makes a funny sound" is less productive than "it makes a funny sound while
accelerating up a hilll in a sharp left turn". Those details matter a LOT.


 ]

>
>> You are sure because
>>   1) you read the documentation and it says it is NMEA, and if so which
>> version?
>>   2) you looked at the data stream and it looks like NMEA?
>>   3) something else?
>>
>
> none of this. Perhaps I have simply misunderstood the data in my
> possession.
>

Our guesses can be no better than yours.


>
>
>> I don't think GPSBabel supports this.
>>
>
It's not really in scope for our project. The only reason we do it at all
is because Google contracted me to add it years ago for Earth. :-)



>   gpsd (works well on u-blox F9, should be fine on M9)
>>     https://gpsd.io/
>
>
This is certainly closer to GPSD's bag of tricks than ours.



>
>>   [Note that if you start down the gpsd path, and want to ask for help,
>>    make sure that 1) you are not using systemd and 2) you are using the
>>    latest release or git master.   Requests for help with the version
>>    that shipped in some ancient long-term stable will not go well.]
>>
>
We have the same problem with Linux. They ship an ancient version, strip
off all the support information, then ship their support problems to us.
But that's not a rant I'm prepared to have right now.




>
>>   https://github.com/semuconsulting/PyGPSClient
>>   [I haven't tried this, but it looks interesting.]
>>
>
That's closer to what we do with our realtime tracking module, but our
per-format support is spotty. Since we lean on consumer-facing hardware,
things like RTCM3 protol just doesn't register for us.

Re: QGis, they actually use GPSBabel for most of their realtime tracking.
YOu can see the commands they build up in the doc at
https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html

https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/plugins_gps.html

Their examples use everything but NMEA, but that works in the "obvious"
(once paired with the links I sent yesterday) command lines.

This is also, not coincidentally, how realtime GPS tracking works in Google
Earth.

RJL

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

Il giorno dom 31 lug 2022 alle ore 06:32 Geo DrinX <geo...@gm...> ha
scritto:

> this is QGIS documentation about gps reading:
>
>
> https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/live_GPS_tracking.html?highlight=gps#
>

... where it reports: "Therefore, you first have to configure gpsd properly
to connect QGIS to it"

well, I'll study for it.

A presto

Roberto

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

this is QGIS documentation about gps reading:

https://docs.qgis.org/3.22/en/docs/user_manual/working_with_gps/live_GPS_tracking.html?highlight=gps#


Il giorno dom 31 lug 2022 alle ore 06:26 Geo DrinX <geo...@gm...> ha
scritto:

> ...and moving through your links I arrived at this library:
>
> https://github.com/topics/ubx-gps-library
>
> that is: "Arduino library for the fastest and simplest communication with
> u-blox GPS modules"
>
> Good!  Great.
>
> Thank you
>
> A presto
>
> Roberto
>
> Il giorno sab 30 lug 2022 alle ore 15:03 Robert Lipe <
> rob...@gp...> ha scritto:
>
>> Use the '-T'racking flag and read from the serial port. See
>> https://www.gpsbabel.org/htmldoc-development/tracking.html
>>
>> We support only a few output types for this, notably KML.
>>
>> In general, this isn't a conversion problem and it's not a trick we
>> particularly try to solve well. If you have the data captured to a file,
>> you can read it with our NMEA modules.
>>
>>
>>
>> On Sat, Jul 30, 2022 at 4:59 AM Geo DrinX <geo...@gm...> wrote:
>>
>>> Good morning from Italy   :)
>>>
>>> I need to read gps output from the serial COM port, with  GpsBabel, but
>>> it seems not so simple  to do  :(
>>>
>>> I am sure it is a standard gps NMEA sentence file format, but... how to
>>> successfully read it?
>>>
>>> Sorry if the question is banal, but ... it is essential to me
>>>
>>> Thank in advance for any info about this
>>>
>>> A presto
>>>
>>> Roberto Angeletti  (geodrinx)
>>>
>>> PS:  I bought the U-Blox EVK-M91 evaluation kit two weeks ago
>>> _______________________________________________
>>> Gpsbabel-code mailing list  http://www.gpsbabel.org
>>> Gps...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>>>
>>

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

...and moving through your links I arrived at this library:

https://github.com/topics/ubx-gps-library

that is: "Arduino library for the fastest and simplest communication with
u-blox GPS modules"

Good!  Great.

Thank you

A presto

Roberto

Il giorno sab 30 lug 2022 alle ore 15:03 Robert Lipe <
rob...@gp...> ha scritto:

> Use the '-T'racking flag and read from the serial port. See
> https://www.gpsbabel.org/htmldoc-development/tracking.html
>
> We support only a few output types for this, notably KML.
>
> In general, this isn't a conversion problem and it's not a trick we
> particularly try to solve well. If you have the data captured to a file,
> you can read it with our NMEA modules.
>
>
>
> On Sat, Jul 30, 2022 at 4:59 AM Geo DrinX <geo...@gm...> wrote:
>
>> Good morning from Italy   :)
>>
>> I need to read gps output from the serial COM port, with  GpsBabel, but
>> it seems not so simple  to do  :(
>>
>> I am sure it is a standard gps NMEA sentence file format, but... how to
>> successfully read it?
>>
>> Sorry if the question is banal, but ... it is essential to me
>>
>> Thank in advance for any info about this
>>
>> A presto
>>
>> Roberto Angeletti  (geodrinx)
>>
>> PS:  I bought the U-Blox EVK-M91 evaluation kit two weeks ago
>> _______________________________________________
>> Gpsbabel-code mailing list  http://www.gpsbabel.org
>> Gps...@li...
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>>
>

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Geo D. <geo...@gm...>]

Il giorno sab 30 lug 2022 alle ore 12:22 Greg Troxel <gd...@le...> ha
scritto:

>
> You didn't explain what you are trying to do, and jumped to the
> conclusion that you need to use gpsbabel.   Maybe you are right, but I'd
> say the odds are low.
>

Yes, sorry, it remains in my brain only  :)
Before all, let me introduce myself: my name is Roberto (geodrinx)
Angeletti and among other things I am the developer of a plugin for QGIS
called GEarthView, which was among the most downloaded and used plugins in
QGIS version 2.x.x.

Apart from that, now I'm working on using a high resolution gps, such as
the U-Blox EVK-M91, to perform surveys via QGIS and QField (which is the
android version of QGIS). Basically, I have to use the U-Blox as a mouse :)

I tried to use the standard QGIS functions to read the coordinates from
gps, but it doesn't work. Investigating, I saw that QGIS simply uses
gpsBabel to take a single point at a time.

So, I installed a gpsBabel and I went to analyze why gpsBabel returns
error, and what were the right parameters to read the data from U-Blox.

This is the story so far.



> > I am sure it is a standard gps NMEA sentence file format, but... how to
> > successfully read it?
>
> You are sure because
>   1) you read the documentation and it says it is NMEA, and if so which
> version?
>   2) you looked at the data stream and it looks like NMEA?
>   3) something else?
>

none of this. Perhaps I have simply misunderstood the data in my possession.


>
> > PS:  I bought the U-Blox EVK-M91 evaluation kit two weeks ago
>
> Is this the device you are trying to read?  If so, that's very important
> information...  For anyone else following along:
>
> https://content.u-blox.com/sites/default/files/EVK-M91_Userguide_%28UBX-19056858%29.pdf?hash=undefined
> See "5 Device Description" on page 10.
>
> This seems to be a u-blox M9 in a box.


hit and sunk. You have hit the target.  :)


> Note that this will speak u-blox binary, often written UBX.


Surely you are right. The flow is likely to be binary, but I haven't
checked yet.


> I don't think GPSBabel supports this.
>

:(

I would recommend that you examine the following
>
>   gpsd (works well on u-blox F9, should be fine on M9)
>     https://gpsd.io/
>   [Note that if you start down the gpsd path, and want to ask for help,
>    make sure that 1) you are not using systemd and 2) you are using the
>    latest release or git master.   Requests for help with the version
>    that shipped in some ancient long-term stable will not go well.]
>
>   https://github.com/semuconsulting/PyGPSClient
>   [I haven't tried this, but it looks interesting.]
>

Thanks for these links.

Obviously, I also requested support from QGIS, but for now they are not
very interested in letting people know that there is something wrong with
the gps reading.
Maybe it's complicated to fix, or it's just me, and therefore has a very
low priority in their bug fix list.  Who knows?

A presto

Roberto

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

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

Use the '-T'racking flag and read from the serial port. See
https://www.gpsbabel.org/htmldoc-development/tracking.html

We support only a few output types for this, notably KML.

In general, this isn't a conversion problem and it's not a trick we
particularly try to solve well. If you have the data captured to a file,
you can read it with our NMEA modules.



On Sat, Jul 30, 2022 at 4:59 AM Geo DrinX <geo...@gm...> wrote:

> Good morning from Italy   :)
>
> I need to read gps output from the serial COM port, with  GpsBabel, but it
> seems not so simple  to do  :(
>
> I am sure it is a standard gps NMEA sentence file format, but... how to
> successfully read it?
>
> Sorry if the question is banal, but ... it is essential to me
>
> Thank in advance for any info about this
>
> A presto
>
> Roberto Angeletti  (geodrinx)
>
> PS:  I bought the U-Blox EVK-M91 evaluation kit two weeks ago
> _______________________________________________
> Gpsbabel-code mailing list  http://www.gpsbabel.org
> Gps...@li...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>

Re: [Gpsbabel-code] Reading U-Blox EVK-M91 serial data

[Greg T. <gd...@le...>]

Geo DrinX <geo...@gm...> writes:

>  Good morning from Italy   :)

Good morning; your signal is 59 in the US with all bits intact.

> I need to read gps output from the serial COM port, with  GpsBabel, but it
> seems not so simple  to do  :(

gpsbabel is aimed at file format conversion.   It sounds like you would
like to get position data as a stream over time.

You didn't explain what you are trying to do, and jumped to the
conclusion that you need to use gpsbabel.   Maybe you are right, but I'd
say the odds are low.

> I am sure it is a standard gps NMEA sentence file format, but... how to
> successfully read it?

You are sure because
  1) you read the documentation and it says it is NMEA, and if so which
     version?
  2) you looked at the data stream and it looks like NMEA?
  3) something else?

> PS:  I bought the U-Blox EVK-M91 evaluation kit two weeks ago

Is this the device you are trying to read?  If so, that's very important
information...  For anyone else following along:
  https://content.u-blox.com/sites/default/files/EVK-M91_Userguide_%28UBX-19056858%29.pdf?hash=undefined
See "5 Device Description" on page 10.

This seems to be a u-blox M9 in a box.  Note that this will speak u-blox
binary, often written UBX.  I don't think GPSBabel supports this.

I would recommend that you examine the following

  gpsd (works well on u-blox F9, should be fine on M9)
    https://gpsd.io/
  [Note that if you start down the gpsd path, and want to ask for help,
   make sure that 1) you are not using systemd and 2) you are using the
   latest release or git master.   Requests for help with the version
   that shipped in some ancient long-term stable will not go well.]

  https://github.com/semuconsulting/PyGPSClient
  [I haven't tried this, but it looks interesting.]