gpsbabel / gpsbabel

GPSBabel: convert, manipulate, and transfer data from GPS programs or GPS receivers. Open Source and supported on MacOS, Windows, Linux, and more. Pointy clicky GUI or a command line version...

GPSBabel

This is the source code for GPSBabel, the free software project to manage GPS data (waypoints, tracks, routes) in your GPSes or in related programs.

Welcome new open source contributors

We have a GPSBabel contributor guide.

Current status of the master branch build is:

• 
• 
• 
• 
• 

Passing is good. We like passing.

The latest official release is available at http://www.gpsbabel.org/download.html.

We are proud of our rating on Codacy:

If you aren't a programmer or a writer, we need help with gear, hosting costs, tool license prices, answering questions on the mailing lists, etc. Please support GPSBabel any way you can.

Chief Babel-Head @robertlipe

gpsbabel's Issues

Add option to turn Garmin RoutePointExtension into regular points

The way Garmin BaseCamp software encodes a GPX route is with regular <rtept> elements describing the navigation hints at intersections (referred as primary route points below), and, for each of these primary route points (except the final one), many <gpxx:rpt> sub-elements in a <gpxx:RoutePointExtension>, describing a more precise path along roads.

Simplified example with relevant parts:

<rtept lat="46.544628096744418" lon="6.658079791814089">
  <extensions>
    <gpxx:RoutePointExtension>
      <gpxx:rpt lat="46.544483928009868" lon="6.658018603920937"/>
      <gpxx:rpt lat="46.544415950775146" lon="6.658358573913574"/>
      <gpxx:rpt lat="46.544415950775146" lon="6.658358573913574"/>
    </gpxx:RoutePointExtension>
  </extensions>
</rtept>

Full file example: Lavaux 001 1 à Lavaux 001 48.GPX.zip

It would be nice to add support to read these <gpxx:rpt> points. A new option to make these sub-elements regular points. E.g. for a conversion from GPX to GPX format, building on the previous example, we would obtain:

<rtept lat="46.544628096744418" lon="6.658079791814089"/>
<rtept lat="46.544483928009868" lon="6.658018603920937"/>
<rtept lat="46.544415950775146" lon="6.658358573913574"/>
<rtept lat="46.544415950775146" lon="6.658358573913574"/>

It would work for a conversion to any other formats too, like to CSV. These subpoints would become regular points in the route.

There are already references to RoutePointExtension in GPSBabel code, and some support for Garmin specific GPX extensions, but not the feature I suggest here.

Reference

The XML DTD from Garmin defining these RoutePointExtension:
http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd

Compatibility with FIT 2.0 format

Gpsbabel breaks when provided a 2+ versioned FIT file. I'm not sure how much has changed from version 1 to version 2, but I can provide a couple of sample files if this helps.

Any plans to support the latest fit formats?

Error when exporting GPS xml to humminbird *.ht

I can export all my HT files into a single GPS xml file. Not working from GPS to HT.

OS X command-line binary

The download page says:

For 10.9 (Mavericks), 10.8 (Mountain Lion), 10.7 (Lion), 10.6 (Snow Leopard), and maybe 10.5 (Leopard). This is a .dmg that contains the GUI and a binary for GPSBabel.

But when I download GPSBabel-1.5.3.dmg it only contains GPSBabelFE, the UI.

Where can I find a command-line binary for OS X?

Conversion from GPX to KML should translate <type> to <Document>

GPX files created by OSMAnd+ contain <type> tags, which are used to categorise bookmarks and set colours, etc. When translating such a GPX file to KML, this information seems to be lost.

I would suggest to translate each GPX <type> to a different KML <Document> (or <Style>, if that is not possible).

My goal is to have the categories, that were shown in OSMAnd+, show up in MAPS.ME in a similar way. I am using these categories to sort my bookmarks by world-region. MAPS.ME shows different <Document>s as different folders, which resembles exactly the OSMAnd+ behaviour with <type>s.

A lot of bugs reported on Debian

Have a look.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=gpsbabel

kml: There were more gx:coord elements than the number of when elements.

Recently, exporting kml from google location history returns the error in the subject. Older kml files convert fine with the latest master, but any new export fails.

If needed I can provide an example file, but reproducing is as simple as fetching any recent Google location history kml and running it through gpsbabel.

Filter option for trkpts above a specified speed

GPX tracks in mountainous areas often include erroneous data resulting from signal bounce. These points are often obvious to humans viewing a track on a map, as they will deviate significantly from an otherwise expected path.

These data points will typically have an imputed speed (calculated as distance from the previous trkpt divided by time since the previous trkpt) that is unreasonably high. For example, the GPX track may be for a hiker, and the imputed speed at a given point may be 20 mph (32 kph) or even higher.

I would love to see a filter option that would remove points above a given imputed speed as provided by the user. The algorithm would need to remove points iteratively; that is to say, when one bad data point is removed, the calculations would need to be performed again to see if surrounding data points are bad.

garmin_gpi option category value can be incorrectly encoded

In #43 @iget-master reported:

Hi, I'm having problems to set category name using accents:

gpsbabel -i gpx -f Vinícolas.gpx -o garmin_gpi,category="Vinícolas" -F "Roteiro.gpi"

This create a category with wrong encoding on the gps: Vinï½colas

How can I fix it?

I believe I have a fix for this, but I need test case. Can you supply the input file mentioned above? Then, if I convert it can you check the output file on your device and report if it appears correctly?

Error: "skytraq: cannot set new location"

I receive this error on Ubuntu 16.04 for a GT-730 USB dongle device in build 1.5.3.

I can confirm that the workaround patch from pull request #41 fixed this issue for me (although obviously have no idea about the wider implications of that change).

linux-gui will not compile on qt-5.x > 5.5

Due to changes in webkit/webengine after qt-5.5, the linux-gui will not compile:

$ make linux-gui
Project ERROR: Unknown module(s) in QT: webkit webkitwidgets

GPX to Naviguide returns an empty file

Running the following command line returns an empty file (0 bytes) - exit code 0:

gpsbabel.exe -N -i gpx,gpxver=1.1 -f "C:\Users\xxx\AppData\Local\Temp\tmp3C12.tmp" -o naviguide -F "C:\Users\xxx\AppData\Local\Temp\tmp3C22.tmp"

Here's the relevant input file.
מסלול 1.txt

Running on Windows 10.
GPSBabel doesn't have a version in the file so it's dated from 02-jan-2016 (worth adding a version to the file...)

Skytraq Venus 6 leap seconds added

Hello
I downloaded my GPS Canmore GT750FL-S with GPSBabel, format IGC
The time have an offset of 3 to 4 seconds with UTC time
The chip Venus 6 have a GPS time and the software must add the leap seconds since the launching of the first satellite.
GPS time start at 1980, Jan. 5/6 mid-night, actually (April 2017) GPS time is ahead of UTC by 18 seconds.

The lead seconds seen to be incorrectly corrected, what is the value take account by the software ?

Mobius

Drag and Drop in v1.5.3 on OS/X fails '/.file/id=6571367.13131907' for read. Error was 'Not a directory'.

Stan Glaser reported:

I tried dragging a file named "2015-12-20 11.01.03 Day.gpx” to the Input section for File Name(s) and it came up with “/.file/id=6571367.13131907” in the box. Of course I tried clicking on “OK” but it just came up with an error of

gpsbabel -w -t -i gpx -f /.file/id=6571367.13131907 -x position,distance=3F -o gpx,gpxver=1.0 -F /.file/id=6571367.13131907
Cannot open '/.file/id=6571367.13131907' for read. Error was 'Not a directory'.

columbus v990 duplicates and duplicate filter

I own Columbus V990 and I use v900 driver to convert data from the device.

I have noticed, that files generated by my device contain duplicates (time, 4th column), i.e.

202***,T,170226,075106,46.474680N,011.803118E,2417*,4***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
203***,T,170226,075107,46.474680N,011.803119E,2417*,4***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
204***,T,170226,075108,46.474681N,011.803124E,2417*,3***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
205***,T,170226,075109,46.474683N,011.803130E,2417*,0***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
206***,T,170226,075107,46.474684N,011.803136E,2417*,0***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
207***,T,170226,075108,46.474688N,011.803145E,2417*,0***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
208***,T,170226,075109,46.474690N,011.803154E,2417*,0***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********
209***,T,170226,075110,46.474691N,011.803164E,2418*,0***,0**,3D,SPS ,1.2**,0.9**,0.8**,*********

I wonder if the duplicate filter could be extended to allow filtering timestamp duplicates?

kml writer produces LookAt elements that are missing a required range element

kml_output_lookat(const Waypoint* waypointp) never outputs a range element, yet

ogc kml 2.2 spec requires
"A kml:LookAt element shall contain the kml:longitude, kml:latitude,and kml:range
child elements outside of an update context, that is when not a descendant of kml:Update."

This is covered in the kml 2.2 abstract test suite check ATC-38.

Patch: garmin_fit: warn instead of fail on unsupported protocol version

Files conforming to newer protocol versions should be (at least partly) decodable with programs that support older versions.
Successfully converted Garmin Edge 520 FW 12.20 fit files protocol version 2.0 to gpx with lat, lon, ele, time, speed, wpt.

Thanks for gpsbabel!

0001-garmin_fit-warn-instead-of-fail-on-unsupported-proto.patch.txt

Setting Garmin TCX files as input, .tcx files cannot be selected

Sometimes it's nice to use the GUI instead of typing the correct filenames in the terminal command gpsbabel -i gtrnctr -f ~/input.tcx -o gpx -F ~/output.gpx.

But the GUI doesn't let me select .tcx files when I ask it to get files with the format 'Garmin Training Center (.tcx)', as seen in the attached screenshot.

GPSBabel GPSBabel 1.5.4 on OS X 10.12.6 (16G29).

New release?

Could a new version please be released with latest support for modern Qt (including, I hope, Qt 5.10)?

Multiple symbols in one Garmin GPI file

Please add support for multiple custom waypoint symbols for Garmin POI file. One waypoint would have one symbol. Different waypoints could have different symbols.

From commandline, it could be done, for example, like this:

Each waypoint will use symbol from image file with the same name as content of the <sym> element in GPX file ( <sym>myicon1</sym>, <sym>myicon2</sym>). There will be several image files (myicon1.bmp, myicon2.bmp) in the same directory as GPX file. Instead of:

gpsbabel -i gpx -f myfile.gpx -o garmin_gpi,category="mycategory",bitmap=myicon.bmp,sleep=1 -F myfile.gpi

gpsbabel will be invoked this way:

gpsbabel -i gpx -f myfile.gpx -o garmin_gpi,category="mycategory",user_bitmaps,sleep=1 -F myfile.gpi

For me, this is the only missing feature in gpsbabel.

FIT to GPX conversion ignores base time and provides times in 1989

When I try converting a Garmin FIT file to GPX I find all the times in the file are in 1989, rather than the date recorded.

Looking at the specification, it would seem that we should probably be reading the time_created value in the file_id message and adding that to the timestamp value, if timestamp is less than 0x10000000.

Command line:

gpsbabel -i garmin_fit -f "2016-09-09-10-29-53.fit" -o gpx -F 2016-09-09-10-29-53.gpx

I can provide data files on request (about 1Mb in size for the .fit).

Was testing with gpsbabel 1.5.3_1, installed with MacPorts, on MacOS X 10.12

Looking at the 'D00001309 FIT File Types Description Rev 2.1' in the FitSDKRelease_20.10.01, for specs.

RE: Working w/ Google Earth/Desktop

Hello,

I am new to your org and want to find out more. If I was to add a file and change the format with your software, could I view it in an external application, i.e. like Google Earth?

I am asking because I have tried before with your software and I cannot get it "tweaked" just right.

Seth

P.S. I have a kml file and/or .txt file and I do not know which file to choose to change into another file type. Sorry for this inexperienced question.

Alignment issue on SPARC64 in saroute.cc reader

When running "make check" on OpenBSD/sparc64 5.8 configured to use the system compiler (gcc-4.2.1), I found this:

Running ./testo.d/saroute.test
Bus error (core dumped)

GDB shows this:

Program terminated with signal 10, Bus error.
#0  my_read () at saroute.cc:371
371             memcpy(&mylatlon,latlon,sizeof(mylatlon));
(gdb) list
366             double lon;
367     
368             wpt_tmp = new Waypoint;
369     
370             // copy to make sure we don't violate alignment restrictions.
371             memcpy(&mylatlon,latlon,sizeof(mylatlon));
372             lat = (0x80000000UL -
373                    le_read32(&mylatlon.lat)) /
374                   (double)(0x800000);
375             lon = (0x80000000UL -

That's interesting because the memcpy was apparently put in place to avoid such issues. Looking at disass, it seems the memcpy has been inlined using a 8 byte load instruction for the source pointer:

(gdb) info registers
...
i3             0x8dbd06b04a     608761720906
...
pc             0x8b1bb44440     0x8b1bb44440 <my_read+1792>
npc            0x8b1bb44444     0x8b1bb44444 <my_read+1796>

(gdb) disass
0x0000008b1bb4443c <my_read+1788>:      mov  %o0, %l1
0x0000008b1bb44440 <my_read+1792>:      ld  [ %i3 ], %g2              ; <------- SIGBUS
0x0000008b1bb44444 <my_read+1796>:      mov  %i4, %o0

As you can see the address in %i3 is not 8 byte aligned. So gcc should place a call to libc memcpy rather then inlining it with non-aligned load. Apparently gcc is free to do inlining here since pointers to structs still need to have correct alignment, otherwise the behaviour is undefined (at least that's what searching for issues like this suggests).

To fix this, adding a forced non-inlined memcpy and using that in line 371 helps:

#if defined(__GNUC__) && __GNUC__ > 3
__attribute__ ((__noinline__))
#endif
static void*
safe_memcpy(void *dst, const void *src, size_t len)
{
  return memcpy(dst, src, len);
}

Another option in this case is to use gcc-4.9 from OpenBSD ports, which doesn't inline memcpy in this location.

Since there is an easy workaround (using gcc-4.9) and the platorm/compiler/input format combination is probably not in widespread use anyway, I'd be fine with closing this bug as wontfix. I just wanted to document this in case there might be some other platforms and compilers affected by similar bugs.

igc format parsing crash

I have fuzzed the igc format parser with afl and the attached file results in a crash (current master) for the following command:

gpsbabel -i igc -o gpx -f crash.igc -F -

crash.igc.txt

Export Humminbird HT

hi, when I export i do not have any depth values in CSV or GPX: can this because I have a none English PC?

2015-08-10T20:33:07.062Z 07/26/15 11:45 AM 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000

48.69745, -72.10734,
48.69748, -72.10738,
48.69751, -72.10744,
48.69754, -72.10749,
48.69757, -72.10753,
48.69759, -72.10759,
48.69762, -72.10764,

Push a 1.5.3?

It's been 11 months since 1.5.2 was released (January). Maybe we should push a 1.5.3.

1.5.2 is tripping over .fit files from my Garmin ForeRunner 230 with "fit: Bad field size in data message". I suspect d6ec2fe or ff0dea7 may resolve the problem. Neither is present in 1.5.2.

libusb-1.0 support

Hi,

libusb upstream switched to a new API (libusb-1.0 - http://libusb.org/static/api-1.0/) - please support or migrate to it as it will become the default libusb implementation in most Linux distrubutions soon(ish).

Thanks a lot,
Bernd

Address issues with MSVC

va_copy is apparently C++11. Misc wchar issues.

Symbols for fishing/boating application

GPS Babel is a great tool and I use it to convert information between my Humminbird and Lowrance fish finders. One pain point I have is that the symbols used by these tools don't match the names that the respective companies use. For example, when I convert a humminbird specific hwr file to a gpx file using GPS Babel, I can't import it into the manufacturers application called HumminbirdPC without losing symbol information. The same is true for Lowrance which now supports gpx. Furthermore, if I take a gpx file created by Humminbird, I can't import it into Lowrance without losing symbol information.

I propose to add a switch to GPS Babel called 'Use Fishing Symbols'. When this switch is present, the behavior of the Humminbird format and two Lowrance formats work in a way that use the manufacturer symbol names and a common set of symbol mappings in their conversion. I've done a bit of research on the devices so I have a good idea of what this symbol set and mapping has to look like. I've also done research using the GPS Babel code base and I know how the binary files need to be handled to use them. (I've also noticed that there are errors on how GPS Babel handles some of the Lowrance file formats.)

I've never contributed to an open source project so I'm looking for direction on what do from here. I'm an experienced software developer and got the tool chain working to a point where I can change and run the application on a Mac/OSX. This is my first brush with C++ in years so the quality of the code will need some help. Assuming the community likes the change, If I submit a pull request can/will someone help me create production code?

"Short GSA sentence" warning

I upgraded to GPSBabel 1.5.3 and now see thousands of "Short GSA sentence" warnings.

Raw NMEA output of Samsung Galaxy S5 phone:

$GPGSA,A,2,05,12,13,15,17,18,19,20,24,28,30,,0.9,0.7,0.7*30
$GNGSA,A,2,05,12,13,15,17,18,19,20,24,28,30,,0.9,0.7,0.7*2E
$GNGSA,A,2,69,70,71,73,79,80,,,,,,,0.9,0.7,0.7*28
$BDGSA,A,2,,,,,,,,,,,,,0.9,0.7,0.7*2B

nmea.cc now emits this "Short GSA sentence" warning (since July 2015) when there are less than 2 IDs (of SVs used in position fix) in a GSA sentence.

My BDGSA sentences have no satellite IDs (talker ID "BD" means Beidou constellation?), presumably because there were none visible (I was indeed far away from China).

Also seen in the NMEA log, when no satellites are visible in any constellation:

$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GNGSA,A,1,,,,,,,,,,,,,,,*00
$BDGSA,A,1,,,,,,,,,,,,,,,*0F

I don't consider these cases bad data and worth a warning, and suggest to change:

  if (scn < 4) {

to:

  if (scn < 2) {

on this line. May I proceed with PR?

rename concerns in mtk_logger and kml

In the review of #87 there were concerns about file renaming and failure modes.
In mtk_logger now QFile::rename will

If a file with the name newName already exists, rename() returns false (i.e., QFile will not overwrite it).

This is probably not what is wanted.
In kml an atomic rename was desired. MoveFileExW handles the windows case, but QFile::rename will fail if posnfilename exists. Additionally, there shouldn't be a need to do anything else in addition to MoveFileExW on windows, i.e. we don't also need to call QFile::rename for windows.

Garmin VIRB Edit

Receive the following error when using the most recent release of GPSbabel on Windows 7 with Garmin's VIRB Edit files:

fit: Bad field size in data message

When attempting to merge fit files such as the two attached files. The attached files have been renamed from *.fit to *.txt.

2015-09-01-12-07-54.txt
2015-09-01-12-15-11.txt

Fix compiler warnings

You probably want to fix these:

zlib/inflate.c:1507:61: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
    if (strm == Z_NULL || strm->state == Z_NULL) return -1L << 16;
                                                        ~~~ ^

garmin_txt.cc:826:10: warning: implicit conversion from 'const int' to 'char' changes value from 176 to -80 [-Wconstant-conversion]
    *c = kDegreeSymbol;  /* degree sign */
       ~ ^~~~~~~~~~~~~

Proximity alerts imply parser failure on non speed "@" use

Conversion fails completely if adding proximity alerts on a KML to GPI conversion with "@" in placemark names not meant to be interpreted as speed alerts:

error.kml:
<?xml version="1.0" encoding="utf-8"?><kml xmlns="http://www.opengis.net/kml/2.2"><Document><name>Test</name><Placemark><name>LAN@Work GmbH</name><Point><coordinates>10.3593499999999,48.98379</coordinates></Point></Placemark></Document></kml>

gpsbabel -i kml -f error.kml -o garmin_gpi,proximity=100m -F error.gpi
garmin_gpi: Unsupported speed unit 'Work GmbH' in item 'Work GmbH'!

Maybe an invalid speed unit could simply be a warning instead of a fatal error? Another option would be to allow enabling proximity alerts without implying speed alert parsing.

Synthesize speed GPX

Trying to make gpx file with speed values:

gpsbabel -t -i gpx -f 1037084.gpx -x track,speed -o gpx -F output.gpx

But resulting file doesn't contain speed info. Is it bug or limitation of GPX and I have to use another format?

potential crash when deferencing null pointer returned from localtime or gmtime

If localtime encounters an error it will return a null pointer. Dereferencing a null pointer may result in a program crash. One way to have this happen is from QDateTime::toTime_t() which will return (unsigned int) -1 if the date is outside the range 1970-01-01T00:00:00 to 2106-02-07T06:28:14. Passing this to localtime can result in the return of a null pointer. This was demonstrated with the MinGW 32 bit compiler on windows with the stmsdf writer.

These usages do not check to see if localtime returns a null pointer before dereferencing it:
csv_util.cc: tm = *localtime(&time);
exif.cc: tm = *localtime(&time);
garmin_gpi.cc: tm = *localtime(&rdata->crdate);
garmin_txt.cc: tm = *localtime(&time);
ignrando.cc: tm = *localtime(&now);
stmsdf.cc: tm = *localtime(&ct);
stmsdf.cc: tm = *localtime(&start_time);
trackfilter.cc: tm = *localtime(&default_time);
trackfilter.cc: tm = *localtime(&t);
trackfilter.cc: t1 = *localtime(&tt1);
trackfilter.cc: t2 = *localtime(&tt2);
util.cc: check = *localtime(&result);

GUI Options box for input file is confusing

Using GPSBabel 1.5.4 on Mac OS X 10.13

Actual behavior: The Options box for the input file has an option with the title, "Target GPX version for output," but the option in fact specifies the gpxver parameter for the input file.

Expected behavior: The title of the option should be "Target GPX version for input"

Support docker and rest API

Hi,
I've been using GPSBabel for quite a while now and I think it's great! (I even contributed a small bit).
Short summary:
Support REST API, support docker.
Long explanation:
I'm working a project and I would like to try and make it cross platform.
That's not an easy task. One of the things I would like to do is move everything to docker for easy deploy and to progress to micro-services architecture.
This means that I would like to convert all the executables running in my project to be HTTP services as it will make them cross platform by definition.
I know GPSBabel is a cross platform compiled library but in terms of deployment you'll need to manually deploy the right executable according to OS (correct me if I'm wrong).
A solution to this problem might be to create a cross-platform docker container to run GPSBabel as a web server (This way you can also remove the dependency on Qt if you'd like to create a web based UI, but it will introduce a dependency on an HTTP server).
I wonder what you think about it, I'd be happy to contribute my time to make it happen.

KML reader may swallow all memory

Another result of fuzzing: the KML reader may eventually swallow all available memory until the program crashes if fed with the attached files. Seems the parser gets stuck in an endless loop.

Its faster and safer to reproduce this when specifying artificial memory limits:

LIMIT_MB=200
( ulimit -Sv $[LIMIT_MB << 10]; gpsbabel -i kml -o gpx -f one-of-the-inputs.kml -F - )

kml-crashes.zip

When converting GPX file into Humminbird HT file with empty depth values

When I try to convert GPX file into Humminbird and I also use the option humminbirdextensions=1

i still have empty depth value on HT file

thank you

Build failure with Clang4

Build fails on FreeBSD with Clang 4.0 with following error:

bushnell.cc:138:36: error: ordered comparison between pointer and zero ('const char *' and 'int')
  for (t = bushnell_icons; t->icon > 0; t++) {
                           ~~~~~~~ ^ ~
bushnell.cc:150:36: error: ordered comparison between pointer and zero ('const char *' and 'int')
  for (t = bushnell_icons; t->icon > 0; t++) {
                           ~~~~~~~ ^ ~

Full build log here

I'll look to patch the FreeBSD port to resolve this. I created this issue to ensure upstream knows about it.

Accented characters not accepted in file names

gpsbabel does not seem to accept accented characters in file names. For example, I am trying to convert the "Kaktushöhle.kml" to gpx:

$ gpsbabel -i kml -f Kaktushöhle.kml -o gpx -F Kaktushöhle.gpx
Cannot open 'Kaktushöhle.kml' for read.  Error was 'No such file or directory'.

I can use STDIN to read the file. However, this call generates a file called "Kaktushhle.gpx" (without the "ö" umlaut):

$ gpsbabel -i kml -f - -o gpx -F Kaktushöhle.gpx < Kaktushöhle.kml

The only way is to use STDIN and STDOUT:

$ gpsbabel -i kml -f - -o gpx -F - > Kaktushöhle.gpx < Kaktushöhle.kml

It seems that gpsbabel strips all non-ascii characters from the file name before attempting to open it.

Tested on gpsbabel-1.5.2-3.fc23.x86_64 on Fedora 23. LANG is de_DE.utf8.

Provide support for exporting to GeoJSON

It would be useful to be able to export directly to GeoJSON. Currently I need to convert to GPX and then with another application GPX to GeoJSON. Having native GeoJSON would be useful.

GeoJSON is covered by RFC-7946

No cyrillic characters in garmin gpi output

The problem, which is described there, is still not solved.

MTK_logger.cc creates non-unique temp file 'data.bin' in OS environ temp path

As discussed on the misc mailing list , function GetTempName() at line 300 of mtk_logger.cc creates the temp path from (in Windows) the TMP environmental path and a file name that is not unique, 'data.bin'.

This is not optimal because

1. the tmp file is not deleted after export format (e.g. GPX) is created - a security issue as Robert Lipe brings up on the message board
2. the tmp file is not uniquely named, and can create data quality issues, especially if GPSBabel is called for parallel processes and TMP path is not uniquely set for each process.
3. (I've also noticed that if the data.bin already exists and is from the same tracker, the time to generate the GPX or CSV is 5 seconds, instead of 60 seconds with no data.bin file. I don't know what the code knows or does to make this the case, but deleting the temp file would probably be safer.)

A potential fix would be to use QTemporaryFile, which create a unique and multi-OS temporary file, which can then be deleted after the process runs.

Here's my attempt at a fix, although I don't have a setup that is yet able to compile C++ or test the code:

current:

static const char* GetTempName(bool backup) { 
  const char kData[]= "data.bin";
  const char kDataBackup[]= "data_old.bin";

  QString t = QDir::tempPath();
  t += QDir::separator();
  t += backup ? kDataBackup : kData;
  return t.toLatin1();
}

suggested:

static const char* GetTempName(bool backup) { 
  QTemporaryFile kFile; // create a unique temp file

  QString t = QDir::tempPath();
  t += QDir::separator();
  t += kFile;
  return t.toLatin1();
}

---

Background: My application uses GPSBabel for multiple identical devices. I use Python to scan the COM Ports and then generate a dos command to extract the GPX files from the MTK loggers. As a workaround, I can set a temporary and isolated environmental variable TMP which GPSBabel uses for each individual process. Sample Python script is here.

Man page lacks basic usage examples

Please add examples to the man page.
Yes, even if they are already in file:///usr/share/doc/gpsbabel/gpsbabel.html . Indeed, just

$ gpsbabel -i gpx -f /tmp/g.gpx -o kml -F /tmp/g.kml

would be fine.

OZI: Unsupported datum 'GRS 80'

I'm getting the following error message:
OZI: Unsupported datum 'GRS 80'
Here is the relevant file:
ozi.plt.txt
partial command line:
gpsbabel.exe -N -i ozi -f ...
Any change to support this?

V2.0 no success Unknown subtype (17)

All my V2 files are not running:

GPSBabel Version: 1.5.4
ovl: header = DOMGVCRD Ovlfile V2.0:
ovl: map name len 144 (0x0090)
ovl: name = Top. Karte 1:50.000 Bayern-S?d
------------------------------------ 0xa9
ovl: entry type 5 (0x0005)
ovl: entry group 1 (0x0001)
ovl: entry zoom 1 (0x0001)
ovl: entry subtype 17 (0x0011)
ggv_bin: Unknown subtype (17)

testing review system

Purpose of code changes on this branch:


When reviewing my code changes, please focus on:


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 24 Sep 2013 at 3:00

Attachments:

• string_scribble.patch

All EXIF Lat/Lon writes fail with "Aborted"

I'm attempting to write Lat/Lon values from a waypoint file into the EXIF section of a JPEG file. All attempts fail with "Aborted" being printed on stdout, no other error is reported. Strace of the gpsbabel executable reveals that it is calling the libc abort() function which is causing the process to be terminated with SIGABRT.

The offending line seems to be this: https://github.com/gpsbabel/gpsbabel/blame/master/exif.cc#L1393

From looking at the odd indentation and the other changes made in the same commit (847718d) I'm guessing this was added for debugging and not removed before commit.

This needs fixing as it looks like it prevents any write operations to JPEG files.