Thread: Re: [Gpsbabel-code] Alan Map500 (Holux GM101) support
Brought to you by:
robertl
From: Robert L. <rob...@us...> - 2007-01-18 06:00:40
|
[ redirected to -code after finding in obscure mailbox ] 0x...@qu... wrote: > Here's a CVS patch that integrates support for the Alan Map 500 > handheld GPS (identical to Holux GM101). Both waypoint+route files > (.wpr) and tracklog files (.trl) can be read and written. Support is > currently limitted to OS Alan/Holux OS Versions 2.x. That is current, > 3.x is still beta. Thanx for the contribution. This is pretty much a poster child for a contribution. Complete code that's not a pain in relying on vendor extensions undefined behaviour , doc, test cases, and so on. It's hard to be too critical of anything that drops in this easily, so thanx for your dilligence! Part of me cringes at yet another reimplementation of the endianness handlers as we have plenty of those already and have spent much effort this year trying to reduce those, not add to them. The architecture geek in me appreciates paying attention to details like PDP endianness (and, yes, as a UNIX dude of 20-ish years, I DO know what that is all about) but the pragmatic part of me just doesn't care any more. It didn't bother me enough to rip it out, though. I think the code could really be simplified (and shrunk) by using replacing byte_order...trl_swap with code in the various functions that handled this. For example, I see you're already using the gbfread family of functions. If, instead of doing a 'gbfread' on the structures, you'd do a gbfgetint16 (or 8 or 32 or dbl or whatever) on the members one by one, you wouldn't have to do the swapping manually later. I made some trivial edits to play nicer with our memory management code and checked it in as it passes both leaktest and vtesto. This happens this easily almost never from a first time contributor. :-) If you can "punch up" the doc, that would be great, but I certainly can't say we don't have existing formats with less doc. Please do sit in on the list for a while to help catch issues on CPU architectures and compilers and such that I didn't exercise on initial checkin. > The Alan community at www.alan-germany.com/forum would love to have > support in gpsbabel. My German is non-existent but we have one very experienced Babelhead, Olaf Klein, that speaks it fluently in case we don't can't make each other understand something. Mind you, your English appears more coherent than what I see from some native speakers, so I'm not seeing that as a problem; it's just offering that we have experienced ears. Thanx. RJL |
From: <0x...@qu...> - 2007-01-24 19:07:58
|
Hello! Thanks for your comments and fixes. It's nice to receive positive feedback from a pro! That made my day. I share your point about reusing code. However, the alan module brings its own endianess functions because it's heavily copied from the current release of map500conv. (Which had the same bugs, so thanks for fixing!) Slurping in all data at once and fixing endianess later has the advantage that we can use the same approach when reading/writing from/to the device directly. It seems to be more reliable to upload/download data in chunks rather than item by item. My idea was that direct device access could be integrated into gpsbabel sometime later. So I chose not to use the existing functions. I'll see what I can do about alan.xml. Cheers, 0xff -- - "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail |