gpsbabel-code Mailing List for GPSBabel
Brought to you by:
robertl
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(21) |
Nov
(24) |
Dec
(41) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(79) |
Feb
(19) |
Mar
(28) |
Apr
(8) |
May
(23) |
Jun
(49) |
Jul
(62) |
Aug
(18) |
Sep
(22) |
Oct
(33) |
Nov
(15) |
Dec
(32) |
2004 |
Jan
(108) |
Feb
(32) |
Mar
(30) |
Apr
(28) |
May
(34) |
Jun
(48) |
Jul
(59) |
Aug
(53) |
Sep
(94) |
Oct
(13) |
Nov
(43) |
Dec
(17) |
2005 |
Jan
(35) |
Feb
(25) |
Mar
(41) |
Apr
(34) |
May
(9) |
Jun
(92) |
Jul
(117) |
Aug
(52) |
Sep
(43) |
Oct
(50) |
Nov
(41) |
Dec
(20) |
2006 |
Jan
(46) |
Feb
(7) |
Mar
(52) |
Apr
(51) |
May
(64) |
Jun
(34) |
Jul
(150) |
Aug
(56) |
Sep
(39) |
Oct
(87) |
Nov
(47) |
Dec
(39) |
2007 |
Jan
(26) |
Feb
(17) |
Mar
(40) |
Apr
(15) |
May
(31) |
Jun
(6) |
Jul
(62) |
Aug
(38) |
Sep
(20) |
Oct
(12) |
Nov
(21) |
Dec
(18) |
2008 |
Jan
(28) |
Feb
(47) |
Mar
(11) |
Apr
(17) |
May
(33) |
Jun
(59) |
Jul
(46) |
Aug
(94) |
Sep
(31) |
Oct
(54) |
Nov
(27) |
Dec
(12) |
2009 |
Jan
(32) |
Feb
(39) |
Mar
(51) |
Apr
(31) |
May
(21) |
Jun
(73) |
Jul
(70) |
Aug
(28) |
Sep
(30) |
Oct
(19) |
Nov
(24) |
Dec
(43) |
2010 |
Jan
(26) |
Feb
(32) |
Mar
(17) |
Apr
(82) |
May
(50) |
Jun
(55) |
Jul
(7) |
Aug
(32) |
Sep
(19) |
Oct
(33) |
Nov
(7) |
Dec
(7) |
2011 |
Jan
(14) |
Feb
(26) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
(7) |
Jul
(33) |
Aug
(19) |
Sep
(12) |
Oct
(31) |
Nov
(42) |
Dec
(19) |
2012 |
Jan
(41) |
Feb
(9) |
Mar
(28) |
Apr
(18) |
May
(52) |
Jun
(4) |
Jul
(22) |
Aug
(16) |
Sep
(10) |
Oct
(12) |
Nov
(12) |
Dec
(62) |
2013 |
Jan
(73) |
Feb
(53) |
Mar
(28) |
Apr
(3) |
May
(15) |
Jun
(19) |
Jul
(111) |
Aug
(152) |
Sep
(62) |
Oct
(35) |
Nov
(15) |
Dec
(11) |
2014 |
Jan
(23) |
Feb
(26) |
Mar
(17) |
Apr
(70) |
May
(8) |
Jun
(50) |
Jul
(9) |
Aug
(2) |
Sep
(20) |
Oct
(9) |
Nov
(1) |
Dec
(50) |
2015 |
Jan
(6) |
Feb
|
Mar
(5) |
Apr
(11) |
May
(10) |
Jun
(11) |
Jul
(17) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2016 |
Jan
(43) |
Feb
(5) |
Mar
(9) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(14) |
Sep
|
Oct
(1) |
Nov
|
Dec
(16) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2018 |
Jan
(2) |
Feb
(1) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2019 |
Jan
(13) |
Feb
(2) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(5) |
Sep
(6) |
Oct
(8) |
Nov
|
Dec
(6) |
2020 |
Jan
(5) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
(14) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(3) |
Feb
|
Mar
(6) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kenneth V. <ke...@vo...> - 2023-04-07 05:32:09
|
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 |
From: Kenneth V. <ke...@vo...> - 2023-03-30 07:28:12
|
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 |
From: Kenneth V. <ke...@vo...> - 2023-03-29 00:19:20
|
No, every point absolutely does *not* need the igc_fs_flags_t struct. That needs improvement. It's there because I was able to get things to work that way, and I didn't want to push a broken pull request. If a flight log uses an extension, then that extension data will be present in every entry (notwithstanding technical glitches) - to be specific, every B record. It gets a little murkier with a few extensions, but for now I'm only concentrating on information present in every B record. It would be far better to have the igc_fs_flags_t struct in a route or route_head object, rather than every waypoint. Then we can do something like (pseudocode): if route->igc_fs_flags_t; then /* do all the fancypants IGC stuff */ else We don't need any of that crap, this is data is from a pair of fancypants binoculars fi I don't know how what I'm pulling from the IGC files is passed to the filters yet. I assume the "route" concept is constructed before we head over to the KML module but I don't know for sure. The long and short is: * igc_fsdata is necessary on every waypoint but superfluously contains igc_fs_flags_t * igc_fs_flags_t contains two kinds of data: o Start and end bytes of each extension. This can be discarded once we're done parsing the IGC file. o booleans indicating the presence of extension data. This should be attached to a route rather than a waypoint object I'll see what I can whip up for that. I spent a bit of time figuring out QHashes and banging my head against a wall because I didn't quite recall the limitations of switch statements today: https://github.com/GPSBabel/gpsbabel/commit/c4eda716ce49ccf27f8ace70f44dda1eea93c480 On 2023-03-28 18:44, Robert Lipe wrote: > More later, but I merged a change to Kenneth's branch that fixes the > test suite for these new files: > > https://github.com/GPSBabel/gpsbabel/pull/1054/commits/bc769c8055f77af4543144133d1c9baf15e751a1 > > I also did some scratching in how we might want to parse those > extended records. > https://github.com/PacketFiend/gpsbabel/pull/1 I don't know that this > is the final/correct form, but it's better than scanf, IMO. > > Just for size purposes, I still really need to better understand the > relationships between points (our fundamental location object) > igc_fs_flags_t (each point can have zero or more of these) and records > like enl. Does every location point potentially have each of an enl, > fxa, and so on ? Why do we need to carry start and stop around during > the life of a Point? > > I don't want to deraiil thread (welcome!) with code design/review > notes; I just wanted to let everyone know that we're starting to kick > some of these bits around in earnest. > > But to the point of this thread, an active user/maintainer of this > format is exactly what it > needs for life support. Oh, be sure to find the xmldoc > dowwn ixmldoc/formats/fmt_kml.xml and the individual flags one > directory leve down from that. > > Welcome. > RJL > > On Tue, Mar 28, 2023 at 9:18 AM tsteven4 <tst...@gm...> wrote: > > I ran your recent kml reference files by my validator, they are valid. > >> $ ~/local/bin/StevesDOMCount -v=always -n -s -f >> -sc=/home/tsteven4/schema -slp=km >> l22 reference/track/92HV66G1.igc.kml >> Using schemaLocation: "http://www.opengis.net/kml/2.2 >> /home/tsteven4/schema/kml22/ogckml22.xsd >> http://www.w3.org/2005/Atom >> /home/tsteven4/schema/kml22/atom-author-link.xsd >> urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 >> /home/tsteven4/schema/kml22/xAL.xsd >> http://www.google.com/kml/ext/2.2 >> /home/tsteven4/schema/kml22/kml22gx.xsd" >> <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://www.google.com/kml/ext/2.2/home/tsteven4/schema/kml22/kml22gx.xsd> >> reference/track/92HV66G1.igc.kml: 71 ms (14937 elems). >> tsteven4@PEDALDAMNIT:~/work/packetfiend$ >> ~/local/bin/StevesDOMCount -v=always -n -s -f >> -sc=/home/tsteven4/schema -slp=kml22 reference/track/92GV66G1.igc.kml >> Using schemaLocation: "http://www.opengis.net/kml/2.2 >> /home/tsteven4/schema/kml22/ogckml22.xsd >> http://www.w3.org/2005/Atom >> /home/tsteven4/schema/kml22/atom-author-link.xsd >> urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 >> /home/tsteven4/schema/kml22/xAL.xsd >> http://www.google.com/kml/ext/2.2 >> /home/tsteven4/schema/kml22/kml22gx.xsd" >> <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://www.google.com/kml/ext/2.2/home/tsteven4/schema/kml22/kml22gx.xsd> >> reference/track/92GV66G1.igc.kml: 43 ms (4461 elems). > > On 3/28/2023 8:05 AM, tsteven4 wrote: >> >> Kenneth, >> >> It is good to hear from users like you, especially those >> representing a group of users and one willing to contribute pull >> requests. The IGC format is fortunate in that a public >> specification >> <https://www.fai.org/sites/default/files/igc_fr_specification_with_al8_2023-2-1_0.pdf> >> exists. Given the general interest in IGC you attest to, your >> willingness to help with the code, and the availability of a >> public specification I support the retention of the IGC format in >> GPSBabel. >> >> KML has a schema definition that allows automated validation, and >> we do some checking of our reference files in our regression >> tests. One validator is at >> https://www.freeformatter.com/xml-validator-xsd.html, although I >> have not used it. It is important the validator has access to >> all the xsd files, e.g. atom-author-link.xsd, kml22gx.xsd, >> ogckml22.xsd, xAL.xsd. >> >> Steve >> >> On 3/27/2023 11:41 PM, Kenneth Voort wrote: >>> Hello, >>> >>> I recently posted a pull request to Github that can read engine >>> noise data from IGC files. I also heard that that IGC support is >>> potentially on the chopping block. >>> >>> Far from removing it, there's actually a few features I'd like >>> to add to the IGC module. Chief among them is the ability to add >>> the ability to extract various extension data from these files. >>> There are several extensions that are of particular interest to >>> (para)glider pilots, such as "engine noise level" (an indication >>> of cheating during a contest, if you have a motorglider) and >>> "total energy variometer" (an instrument that tracks the product >>> of Δheight*Δspeed). I'm quite happy to add the necessary code >>> and update existing code where necessary to accomplish this. I'd >>> also like to eventually add filters that can compute various >>> data, like inferring wind speed and vertical speed and G load, >>> or detecting when a glider has begun "thermalling" (circling in >>> a rising bubble of hot air to gain height). >>> >>> My soaring club is using GPSBabel in our flight recorders as >>> part of our accounting system, or at least we're hoping to >>> implement it this year or next. The idea is that every club >>> glider will be equipped with some kind of raspberry pi powered >>> homebrew flight recorder, which when parked in our hangar, will >>> upload its flight data somewhere (we're not sure where yet, it >>> may happen locally) and get it converted into CSV format for >>> entry into our billing system. We're also hoping it can somehow >>> be adapted to analyze training and aerobatic flights, and >>> overlay them onto Google Earth for demonstration purposes. I >>> realize you don't hear a lot about people using GPSBabel's IGC >>> module, but I can assure you, it most certainly *is* used, >>> extensively - just not by the type of people who post to >>> Sourceforge mailing lists or make commits on Github. >>> >>> Generally speaking, glider pilots and clubs use proprietary >>> software of some sort to analyze their IGC files, or they upload >>> them to https://www.onlinecontest.org, an international free >>> service that awards competition "points" for flights and curates >>> world records for pilots not flying in competitions. Outside of >>> that, we very much all rely on GPSBabel in one way or another to >>> analyze those files. Unfortunately, the sport tends to attract >>> the "technologically challenged" type of person, so I get the >>> feeling GPSBabel is not benefiting much from our use. >>> >>> I'm personally hoping to use it as a way to import various data >>> into Google Earth. I have a talk coming up with a local flight >>> school and I would like to show a bunch of flights, as a way to >>> dispel, to people who only fly powered aircraft, just how >>> capable a modern glider really is. I digress, but that's where >>> my original interest in this project came from. And then I >>> noticed a few features it didn't have that I wish it did, and >>> you all know how that goes. >>> >>> I haven't written anything in C++ in a dog's age, so please bear >>> with me while I readjust. Contributing to a project written in >>> C++ is also be a way to keep my skills sharp there, so I'm very >>> happy to do so (it looks good on a resumé, too). I'm also >>> working on a module that looks like it hasn't been maintained >>> since 2005 or so, so I'm in the middle of a bunch of very, very >>> old code, with little context. Feel free to be brutal and >>> recommend all kinds of changes to this and any future pull >>> requests. >>> >>> One observation - the KML code is very difficult to follow. XML >>> tags aren't closed in the same block of code they're opened in a >>> lot of cases (nor are there comments explaining where they're >>> closed if it's in another function), so it becomes very >>> difficult to figure out why the KML I generate is invalid. >>> Opening and closing tags should reside in the same function that >>> writes the relevant KML wherever possible, IMO. Not that I want >>> to rain on the parade, but I feel that's a useful observation. >>> > _______________________________________________ > Gpsbabel-code mailing list http://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code > > > > _______________________________________________ > Gpsbabel-code mailing listhttp://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code |
From: Robert L. <rob...@gp...> - 2023-03-28 22:44:42
|
More later, but I merged a change to Kenneth's branch that fixes the test suite for these new files: https://github.com/GPSBabel/gpsbabel/pull/1054/commits/bc769c8055f77af4543144133d1c9baf15e751a1 I also did some scratching in how we might want to parse those extended records. https://github.com/PacketFiend/gpsbabel/pull/1 I don't know that this is the final/correct form, but it's better than scanf, IMO. Just for size purposes, I still really need to better understand the relationships between points (our fundamental location object) igc_fs_flags_t (each point can have zero or more of these) and records like enl. Does every location point potentially have each of an enl, fxa, and so on ? Why do we need to carry start and stop around during the life of a Point? I don't want to deraiil thread (welcome!) with code design/review notes; I just wanted to let everyone know that we're starting to kick some of these bits around in earnest. But to the point of this thread, an active user/maintainer of this format is exactly what it needs for life support. Oh, be sure to find the xmldoc dowwn ixmldoc/formats/fmt_kml.xml and the individual flags one directory leve down from that. Welcome. RJL On Tue, Mar 28, 2023 at 9:18 AM tsteven4 <tst...@gm...> wrote: > I ran your recent kml reference files by my validator, they are valid. > > $ ~/local/bin/StevesDOMCount -v=always -n -s -f -sc=/home/tsteven4/schema > -slp=km > l22 reference/track/92HV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://www.google.com/kml/ext/2.2/home/tsteven4/schema/kml22/kml22gx.xsd> > reference/track/92HV66G1.igc.kml: 71 ms (14937 elems). > tsteven4@PEDALDAMNIT:~/work/packetfiend$ ~/local/bin/StevesDOMCount > -v=always -n -s -f -sc=/home/tsteven4/schema -slp=kml22 > reference/track/92GV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > <http://www.opengis.net/kml/2.2/home/tsteven4/schema/kml22/ogckml22.xsdhttp://www.w3.org/2005/Atom/home/tsteven4/schema/kml22/atom-author-link.xsdurn:oasis:names:tc:ciq:xsdschema:xAL:2.0/home/tsteven4/schema/kml22/xAL.xsdhttp://www.google.com/kml/ext/2.2/home/tsteven4/schema/kml22/kml22gx.xsd> > reference/track/92GV66G1.igc.kml: 43 ms (4461 elems). > > > On 3/28/2023 8:05 AM, tsteven4 wrote: > > Kenneth, > > It is good to hear from users like you, especially those representing a > group of users and one willing to contribute pull requests. The IGC format > is fortunate in that a public specification > <https://www.fai.org/sites/default/files/igc_fr_specification_with_al8_2023-2-1_0.pdf> > exists. Given the general interest in IGC you attest to, your willingness > to help with the code, and the availability of a public specification I > support the retention of the IGC format in GPSBabel. > > KML has a schema definition that allows automated validation, and we do > some checking of our reference files in our regression tests. One > validator is at https://www.freeformatter.com/xml-validator-xsd.html, > although I have not used it. It is important the validator has access to > all the xsd files, e.g. atom-author-link.xsd, kml22gx.xsd, ogckml22.xsd, > xAL.xsd. > > Steve > On 3/27/2023 11:41 PM, Kenneth Voort wrote: > > Hello, > > I recently posted a pull request to Github that can read engine noise data > from IGC files. I also heard that that IGC support is potentially on the > chopping block. > > Far from removing it, there's actually a few features I'd like to add to > the IGC module. Chief among them is the ability to add the ability to > extract various extension data from these files. There are several > extensions that are of particular interest to (para)glider pilots, such as > "engine noise level" (an indication of cheating during a contest, if you > have a motorglider) and "total energy variometer" (an instrument that > tracks the product of Δheight*Δspeed). I'm quite happy to add the necessary > code and update existing code where necessary to accomplish this. I'd also > like to eventually add filters that can compute various data, like > inferring wind speed and vertical speed and G load, or detecting when a > glider has begun "thermalling" (circling in a rising bubble of hot air to > gain height). > > My soaring club is using GPSBabel in our flight recorders as part of our > accounting system, or at least we're hoping to implement it this year or > next. The idea is that every club glider will be equipped with some kind of > raspberry pi powered homebrew flight recorder, which when parked in our > hangar, will upload its flight data somewhere (we're not sure where yet, it > may happen locally) and get it converted into CSV format for entry into our > billing system. We're also hoping it can somehow be adapted to analyze > training and aerobatic flights, and overlay them onto Google Earth for > demonstration purposes. I realize you don't hear a lot about people using > GPSBabel's IGC module, but I can assure you, it most certainly *is* used, > extensively - just not by the type of people who post to Sourceforge > mailing lists or make commits on Github. > > Generally speaking, glider pilots and clubs use proprietary software of > some sort to analyze their IGC files, or they upload them to > https://www.onlinecontest.org, an international free service that awards > competition "points" for flights and curates world records for pilots not > flying in competitions. Outside of that, we very much all rely on GPSBabel > in one way or another to analyze those files. Unfortunately, the sport > tends to attract the "technologically challenged" type of person, so I get > the feeling GPSBabel is not benefiting much from our use. > > I'm personally hoping to use it as a way to import various data into > Google Earth. I have a talk coming up with a local flight school and I > would like to show a bunch of flights, as a way to dispel, to people who > only fly powered aircraft, just how capable a modern glider really is. I > digress, but that's where my original interest in this project came from. > And then I noticed a few features it didn't have that I wish it did, and > you all know how that goes. > > I haven't written anything in C++ in a dog's age, so please bear with me > while I readjust. Contributing to a project written in C++ is also be a way > to keep my skills sharp there, so I'm very happy to do so (it looks good on > a resumé, too). I'm also working on a module that looks like it hasn't been > maintained since 2005 or so, so I'm in the middle of a bunch of very, very > old code, with little context. Feel free to be brutal and recommend all > kinds of changes to this and any future pull requests. > > One observation - the KML code is very difficult to follow. XML tags > aren't closed in the same block of code they're opened in a lot of cases > (nor are there comments explaining where they're closed if it's in another > function), so it becomes very difficult to figure out why the KML I > generate is invalid. Opening and closing tags should reside in the same > function that writes the relevant KML wherever possible, IMO. Not that I > want to rain on the parade, but I feel that's a useful observation. > > _______________________________________________ > Gpsbabel-code mailing list http://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code > |
From: tsteven4 <tst...@gm...> - 2023-03-28 14:18:18
|
I ran your recent kml reference files by my validator, they are valid. > $ ~/local/bin/StevesDOMCount -v=always -n -s -f > -sc=/home/tsteven4/schema -slp=km > l22 reference/track/92HV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > reference/track/92HV66G1.igc.kml: 71 ms (14937 elems). > tsteven4@PEDALDAMNIT:~/work/packetfiend$ ~/local/bin/StevesDOMCount > -v=always -n -s -f -sc=/home/tsteven4/schema -slp=kml22 > reference/track/92GV66G1.igc.kml > Using schemaLocation: "http://www.opengis.net/kml/2.2 > /home/tsteven4/schema/kml22/ogckml22.xsd http://www.w3.org/2005/Atom > /home/tsteven4/schema/kml22/atom-author-link.xsd > urn:oasis:names:tc:ciq:xsdschema:xAL:2.0 > /home/tsteven4/schema/kml22/xAL.xsd http://www.google.com/kml/ext/2.2 > /home/tsteven4/schema/kml22/kml22gx.xsd" > reference/track/92GV66G1.igc.kml: 43 ms (4461 elems). On 3/28/2023 8:05 AM, tsteven4 wrote: > > Kenneth, > > It is good to hear from users like you, especially those representing > a group of users and one willing to contribute pull requests. The IGC > format is fortunate in that a public specification > <https://www.fai.org/sites/default/files/igc_fr_specification_with_al8_2023-2-1_0.pdf> > exists. Given the general interest in IGC you attest to, your > willingness to help with the code, and the availability of a public > specification I support the retention of the IGC format in GPSBabel. > > KML has a schema definition that allows automated validation, and we > do some checking of our reference files in our regression tests. One > validator is at https://www.freeformatter.com/xml-validator-xsd.html, > although I have not used it. It is important the validator has access > to all the xsd files, e.g. atom-author-link.xsd, kml22gx.xsd, > ogckml22.xsd, xAL.xsd. > > Steve > > On 3/27/2023 11:41 PM, Kenneth Voort wrote: >> Hello, >> >> I recently posted a pull request to Github that can read engine noise >> data from IGC files. I also heard that that IGC support is >> potentially on the chopping block. >> >> Far from removing it, there's actually a few features I'd like to add >> to the IGC module. Chief among them is the ability to add the ability >> to extract various extension data from these files. There are several >> extensions that are of particular interest to (para)glider pilots, >> such as "engine noise level" (an indication of cheating during a >> contest, if you have a motorglider) and "total energy variometer" (an >> instrument that tracks the product of Δheight*Δspeed). I'm quite >> happy to add the necessary code and update existing code where >> necessary to accomplish this. I'd also like to eventually add filters >> that can compute various data, like inferring wind speed and vertical >> speed and G load, or detecting when a glider has begun "thermalling" >> (circling in a rising bubble of hot air to gain height). >> >> My soaring club is using GPSBabel in our flight recorders as part of >> our accounting system, or at least we're hoping to implement it this >> year or next. The idea is that every club glider will be equipped >> with some kind of raspberry pi powered homebrew flight recorder, >> which when parked in our hangar, will upload its flight data >> somewhere (we're not sure where yet, it may happen locally) and get >> it converted into CSV format for entry into our billing system. We're >> also hoping it can somehow be adapted to analyze training and >> aerobatic flights, and overlay them onto Google Earth for >> demonstration purposes. I realize you don't hear a lot about people >> using GPSBabel's IGC module, but I can assure you, it most certainly >> *is* used, extensively - just not by the type of people who post to >> Sourceforge mailing lists or make commits on Github. >> >> Generally speaking, glider pilots and clubs use proprietary software >> of some sort to analyze their IGC files, or they upload them to >> https://www.onlinecontest.org, an international free service that >> awards competition "points" for flights and curates world records for >> pilots not flying in competitions. Outside of that, we very much all >> rely on GPSBabel in one way or another to analyze those files. >> Unfortunately, the sport tends to attract the "technologically >> challenged" type of person, so I get the feeling GPSBabel is not >> benefiting much from our use. >> >> I'm personally hoping to use it as a way to import various data into >> Google Earth. I have a talk coming up with a local flight school and >> I would like to show a bunch of flights, as a way to dispel, to >> people who only fly powered aircraft, just how capable a modern >> glider really is. I digress, but that's where my original interest in >> this project came from. And then I noticed a few features it didn't >> have that I wish it did, and you all know how that goes. >> >> I haven't written anything in C++ in a dog's age, so please bear with >> me while I readjust. Contributing to a project written in C++ is also >> be a way to keep my skills sharp there, so I'm very happy to do so >> (it looks good on a resumé, too). I'm also working on a module that >> looks like it hasn't been maintained since 2005 or so, so I'm in the >> middle of a bunch of very, very old code, with little context. Feel >> free to be brutal and recommend all kinds of changes to this and any >> future pull requests. >> >> One observation - the KML code is very difficult to follow. XML tags >> aren't closed in the same block of code they're opened in a lot of >> cases (nor are there comments explaining where they're closed if it's >> in another function), so it becomes very difficult to figure out why >> the KML I generate is invalid. Opening and closing tags should reside >> in the same function that writes the relevant KML wherever possible, >> IMO. Not that I want to rain on the parade, but I feel that's a >> useful observation. >> |
From: tsteven4 <tst...@gm...> - 2023-03-28 14:05:19
|
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. > |
From: Kenneth V. <ke...@vo...> - 2023-03-28 06:09:50
|
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 |
From: Kristian K. <kk...@kr...> - 2023-01-20 11:11:16
|
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 |
From: Robert L. <rob...@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 > > > > > _______________________________________________ > Gpsbabel-code mailing list http://www.gpsbabel.org > Gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsbabel-code > |
From: Kristian K. <kk...@kr...> - 2023-01-19 16:28:22
|
(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 |
From: Greg T. <gd...@le...> - 2022-07-31 17:32:57
|
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. |
From: Geo D. <geo...@gm...> - 2022-07-31 15:50:04
|
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. > > |
From: Greg T. <gd...@le...> - 2022-07-31 11:56:12
|
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. |
From: <geo...@gm...> - 2022-07-31 07:35:03
|
>> 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 |
From: Robert L. <rob...@gp...> - 2022-07-31 06:26:10
|
> > 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 |
From: Geo D. <geo...@gm...> - 2022-07-31 06:08:47
|
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 |
From: Robert L. <rob...@gp...> - 2022-07-31 04:44:49
|
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 |
From: Geo D. <geo...@gm...> - 2022-07-31 04:35:52
|
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 |
From: Geo D. <geo...@gm...> - 2022-07-31 04:32:37
|
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 >>> >> |
From: Geo D. <geo...@gm...> - 2022-07-31 04:27:00
|
...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 >> > |
From: Geo D. <geo...@gm...> - 2022-07-31 04:17:48
|
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 |
From: Robert L. <rob...@gp...> - 2022-07-30 13:04:04
|
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 > |
From: Greg T. <gd...@le...> - 2022-07-30 10:38:20
|
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.] |
From: Geo D. <geo...@gm...> - 2022-07-30 09:58:10
|
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 |
From: David P. <dav...@gm...> - 2022-06-04 16:43:15
|
OK (never mind). Thanks. On 6/4/2022 12:39 PM, tsteven4 wrote: > > Yes, it is a gpsbabel question, the relevant lines of code are here: > > https://github.com/GPSBabel/gpsbabel/blob/d926831188bbf19c604dadc8b70f4fc185c894c5/kml.cc#L842-L849 > > > On 6/4/2022 10:33 AM, Jon Witsell wrote: >> >you get the track-none icon (square) for track points with a speed >> less than 1m/s. >> >> Thank you for that! That makes sense. I'll test this out with my GPS >> unit on my hike later. Appreciate it! >> >> >(Not really a GPSBabel question; More of a GE one.) >> >> I was directed here because no one at google knows any longer. I was >> told "Robert Lipe might know. He's the author of GPSBabel, the >> program that handles GPS files for Google Earth." >> >> So, I think it is really a GPSBabel question. >> >> On Sat, Jun 4, 2022 at 8:57 AM Jon Witsell <ag...@gm...> wrote: >> >> Hi, >> >> I’m curious about the symbology of track points. I’ve imported a >> .GPX file into Google Earth (It may be similar in Garmin >> Basecamp). The track is made up of points, some are arrows and >> some are squares. See here: >> >> https://imgur.com/a/NKBT1xB >> <https://notifications.google.com/g/p/AD-FnEyGlIWl2juTBRnDhGJYoXM02fpisbvwtKTOWReGaK2J0CCEFi1jzpr4ijEUDgp4gn3Ny1wf6MfLcrvryGvp> >> >> It makes sense to me that the arrows are showing /heading/. >> However, the square symbols also contain heading data. >> >> *Why are they not all arrows (or squares for that matter…)? What >> determines what symbol goes with what trackpoint?* >> >> The only (very dated) reference I could find was here: >> >> http://kml4earth.appspot.com/icons.html >> <http://notifications.google.com/g/p/AD-FnEyrusI4m2wuQbLcyHheh_hZbbv5CtFquoyjieT3iq9Rsf2mJliY9A8LTGHBpDKQpVpoxj8rHq58Pj1MSayH9Ky34HvUgAr90xvY> >> >> Note: The track icons are treated special in Google Earth. If >> you specify to use the gx:Track extension as used for >> GPS-tracks and specify a Style using the >> http://earth.google.com/images/kml-icons/track-directional/track-0.png icon >> (shown above) then the icon is dynamically changed to >> appropriate icon using the computed compass heading from the >> previous position. The URL >> http://maps.google.com/mapfiles/kml/shapes/track.png can also >> be used in KML for the track icon style for the same >> behavior, but in this case the URL itself doesn't resolve if >> accessed directly in a web browser and results in a HTTP 404 >> not found error. >> >> Thx! >> >> Jon >> >> >> >> _______________________________________________ >> Gpsbabel-code mailing listhttp://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 |