GPSBabel Frequently Asked Questions
- When will a new feature be added for me?
- How complicated is it to add a new format?
- Why did it change the filename I typed?
- How do you distinguish USB vs. serial Garmins?
- Why is GPSBabel a DOS program?
- How do I get help with GPSBabel?
- When will a new feature be added?
- Can I use GPSBabel as a library in my own program?
GPSBabel isn't developed by a company; it's done by volunteers. Much of the development is done by people solving their own problems. Sometimes, if you ask nicely, and your request is reasonably sized, developers will implement things for you. If you want something done badly enough and can't find volunteers to do it, contract programmers can often get it done.
- Human-readable text. Open a representative file in your favorite text editor such as TextEdit.app or Notepad. If you can read and explain everything you see ("here's a longitude, there's a name, this is the altitude in meters, etc."), it's probably pretty easy to add this format. If the format is recognizable and trivial, a non-programmer can probably write a description for it with our style scheme in under an hour.
If you write a paragraph or two of explanation and send the resulting style definition to the GPSBabel list, we may add it to our next version, saving the next user of that program the effort.
If you can read and explain everything in the file, but it's not really a something-separated format that can be represented by a GPSBabel style, it'll have to be done by a programmer. We have pretty good internal infrastructure for these, but a typical time to implement and test one of these is on the order of half a day.
- Binary data that's easily recognizable. If you open the file in a binary editor or a hex dumper and you see a pattern or barber-pole effect which indicates that the file consists of fixed length records, it may be straight-forward to reverse-engineer it. Often a developer can figure out the length of the record and recognize the patterns. Position is often stored as IEEE doubles, but may be big or little endian. Sometimes they're floats. Sometimes they're integers with scales applied. Sometimes they may use radians or semicircles instead of degrees. They may be any of the above, but in a different datum. But it's a bit like a crossword puzzle. If we know some of the pieces (this is a track taken in Mountain View, CA on the afternoon of August 9, 2010) and we know the size of each record, we can usually implement a a reader for these. Writers depend on the number of unknown pieces we find. As an rough estimate, a developer can usually implement one of these formats (reverse engineering, implementation, testing) in about a day.
The key trait of this class is a pattern of the repeat pops out when you just look at it; the challenge is to find what's in the record. For example, a Bushnell trail file looks like:
00000000 54 4c 30 30 33 00 00 00 00 00 00 00 00 00 00 00 |TL003...........|It's pretty obvious that there's some kind of a header and something that repeats every 16 bytes. Knowing that, finding a lat/long/time/alt in those 16 bytes isn't too hard and experimenting with the file - or profiling a large set - usually makes the header pretty easy to figure out. In this case, we have a 20 byte header, We have to figure out allowable characters, what character set it is, if it's a 20 byte track name or a 19 byte name followed by a terminating zero, if it's an 8 byte name followed by other fields that happen to be zero, such as colors or something, but we know the basic shape is a 20 byte header followed by lat/long pairs scaled by 1000000. Even if the repeat is longer, a "barber pole" effect will usually stand out.
00000010 00 00 00 00 82 82 04 15 6e 3d e6 c8 de 80 04 15 |........n=......|
00000020 fc 40 e6 c8 a4 7e 04 15 12 44 e6 c8 5a 7d 04 15 |.@...~...D..Z}..|
00000030 50 47 e6 c8 60 7c 04 15 8e 4a e6 c8 da 7a 04 15 |PG..`|...J...z..|
00000040 1c 4e e6 c8 82 78 04 15 56 50 e6 c8 da 75 04 15 |.N...x..VP...u..|
00000050 32 51 e6 c8 1e 73 04 15 ec 50 e6 c8 c6 70 04 15 |2Q...s...P...p..|
00000060 12 53 e6 c8 bc 70 04 15 d2 56 e6 c8 2c 6f 04 15 |.S...p...V..,o..|
00000070 4c 5a e6 c8 f0 6e 04 15 52 5e e6 c8 78 6e 04 15 |LZ...n..R^..xn..|
00000080 08 62 e6 c8 e2 6d 04 15 e6 65 e6 c8 ce 6d 04 15 |.b...m...e...m..|
- Binary data that just looks like nonsense with no immediately recognizable pattern. We have successfully reverse engineered a few such formats, but they're a complete wild card. These are very expensive to figure out and success can range from complete to qualified success ("we know enough to read some of the data") to total failure ("we've spent three weeks staring at this page of numbers and can't correlate it to anything we know about the source data.")
- Vaguely describe a problem you're having some place other than the GPSBabel-misc mailing list
- don't list the operating system in use
- don't list the versions of anything involved
- don't offer a test case.
- Be evasive when asked about the precise steps to reproduce the problem.
The author pronounces the product name to spell out the letters "GPS" and "Babel" with a short a to rhyme with "Scrabble".
The license chosen by GPSBabel allows you to do that if your program is GPL and you distribute the source. It expressly prohibits linking with other programs that are not GPL except via the standard command line interface.
The project itself is also focused on delivering a program and not an API. We change internals without much regard for preserving compatibility, deprecation schedules, API shims, DLL/dylib/shared object concerns or other things reasonably expected of providing a library instead of a finished program