gpsbabel-misc Mailing List for GPSBabel (Page 341)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Has anyone come across maps shown in Scalable Vector Graphics format?

regards DaveP

> (And it turned out "cvs up" didn't work earlier simply because I
> wasn't IN the gpsbabel directory -- I was one step above it.)

Suspected such.

> But now that I look at it, -s is almost the only one that matters,
> isn't it?

By popularity, yes.

> What exactly does -N do?

If you aren't a geocacher, not very much.

If you have an input format that contains enough information that we
KNOW this waypoint represents a geocache, GPSBabel does some cute
processing like writing key geocache information in the waypoint comment
and setting the icon so you know what you're looking for.  -N tells it
to not do that.

> (Hey, speaking of short waypoint names, why does GPSBabel insist on
> stripping out the hyphens from my waypoints when I re-upload them to
> my Garmin Legend?!)

Because hyphens are very clearly spelled out in the Garmin protocol spec
as being an invalid character in a waypoint name.  See:

http://forums.groundspeak.com/GC/index.php?showtopic=91293&st=500&#entry1391065

RJL

On 10/31/05, Robert Lipe wrote:
>
> > Any idea when the -^3 trick will work?
>
>It should work today after our round of commits.  Update the tree and
>you should have it.

Got it.  (And it turned out "cvs up" didn't work earlier simply because I wasn't IN the gpsbabel directory -- I was one step above it.)

>Please consider a global flag that sets our "-s" flag if the type is
>'w'.  That allows GPSBabel to build "smart" names during conversion by
>smooshing the description, comments, or notes down into something that
>can replace the shortname.  It works poorly with tracks and routes, but
>waypoint users like it.

I'm certainly planning to add widgets for the non-format-specific options, and maybe even filters at some point.  But now that I look at it, -s is almost the only one that matters, isn't it?  What exactly does -N do?

(Hey, speaking of short waypoint names, why does GPSBabel insist on stripping out the hyphens from my waypoints when I re-upload them to my Garmin Legend?!)

Adam

> Any idea when the -^3 trick will work?

It should work today after our round of commits.  Update the tree and
you should have it.

> I've made some more progress: http://www.gpsvisualizer.com/gpsbabel/
> -- the JavaScript works now, so it doesn't let you select formats that

That's very nice!

Please consider a global flag that sets our "-s" flag if the type is
'w'.  That allows GPSBabel to build "smart" names during conversion by
smooshing the description, comments, or notes down into something that
can replace the shortname.  It works poorly with tracks and routes, but
waypoint users like it.

I really like how this is shaping up.

RJL

On 10/31/05, Robert Lipe wrote:
>
> > On the other hand, having all the possibilities, for things like
>> "deficon", stored SOMEWHERE might be kind of cool...
>
>That's a more expensive undertaking than I'm prepared to tackle right
>now.

And I wouldn't expect you to!  But at some point, if this goes well, I may want to include that information.

Any idea when the -^3 trick will work?

I've made some more progress: http://www.gpsvisualizer.com/gpsbabel/ -- the JavaScript works now, so it doesn't let you select formats that don't match the data type.  (To begin with, I'm not going to deal with the "multiple data type" situation -- at least not in the input form.)

Adam

> No, we don't.  I just wanted to make sure that any easy ones, like
> "3,4,5", WERE in there if possible.

Let me know if you know of any such data types in there.

> On the other hand, having all the possibilities, for things like
> "deficon", stored SOMEWHERE might be kind of cool...

That's a more expensive undertaking than I'm prepared to tackle right
now.

> A couple of tweaks: you have kml:line_width and kml:line_color listed
> as boolean, but they should be integer (or string?) and string,

Fixed.

> Robert, when you get this new stuff checked in, can you send me
> (but not the list) a new .tar file?  (I tried looking at the CVS
> instructions page, but it's greek to me.)

Olaf and I have been playing ping pong in this code.  I'll get you a new
version after that settles.

(That's why I really was trying to point you to CVS - so you'd be 
no more than one command away from always having the latest...)

RJL

On 10/31/05, Robert Lipe wrote:
>
>There are a few that are enumerations that we probably don't want to make
>into a picklist.  (Do we really want 214 deficon options for an1?)

No, we don't.  I just wanted to make sure that any easy ones, like "3,4,5", WERE in there if possible.

On the other hand, having all the possibilities, for things like "deficon", stored SOMEWHERE might be kind of cool...

>Take a look at the attached.  I think I got your requests, but added a
>'default' at the end. 

Good idea.

>Let me know how this works for you and I'll check it in with any
>needed tweaks.

A couple of tweaks: you have kml:line_width and kml:line_color listed as boolean, but they should be integer (or string?) and string, respectively.

Robert, when you get this new stuff checked in, can you send me (but not the list) a new .tar file?  (I tried looking at the CVS instructions page, but it's greek to me.)

Adam

On Mon, 2005-10-31 at 12:15 -0600, Robert Lipe wrote:

> 
> It's ironic that if your friend is "very low tech", she's more likely to
> _use_ the LegendC with City Select.  It's not uncommon to want to pick a
> Chinese restaraunt or a hotel and get turn-by-turn directions instead of
> a straight line or an arrow to follow.

What struck me as really crazy is the fact that I can buy the City
Select
maps for the states, here in Europe... but I can't buy the City Select
maps for Europe... which you guys in the states can buy.

Garmin didn't respond when I made the point.

regards DaveP

Beverly Howard wrote:
> A (very low tech) neighbor bought a Garmin Legend and when she couldn't 
> figure out how to turn it on, she put it back in the box and was going 

Is it really a Legend or a LegendC?

> point, but I was wondering if it's possible to buy a single Garmin map 
> for a specific local area to get people started rather than popping for 
> the $100+ mapsource CD as step one?

The answer optimizes down to "no".

I'm recalling you're in the U.S., so I'll guide this answer appropriately.

City Select is around $100 (various package deals such as the auto
nav kit and the GPS18 kit can get the total price down) and includes
autorouting data.  That's lovely if you have a LegendC that can use
routing data.

If you have a Legend, look for the older packages like Topo or
Metroguide.  Street price on those is around a third to a half that of
City Select.

It's ironic that if your friend is "very low tech", she's more likely to
_use_ the LegendC with City Select.  It's not uncommon to want to pick a
Chinese restaraunt or a hotel and get turn-by-turn directions instead of
a straight line or an arrow to follow.

RJL

> with the new list.)  And don't forget to take "(0/1)" off of the
> description of tpo:dumpheader!  By the way, if there are any others

That was in my local copy.  I've now committed the whole thing.  Thanx.

> that require a specific range of choices (like "1..16" or "3,4,5"),
> adding those would be helpful as well; I've got my form set up to read
> output those as drop-downs.

There are very few that are enumerated lists.  Serial speeds are the only
ones that come to mind.

There are a few that are enumerations that we probably don't want to make
into a picklist.  (Do we really want 214 deficon options for an1?)

We do have some internal infrastructure for representing pick lists,
but the stack filter is the only one that seems to use it.  (Since
Ron did both the stack filter and the arg typing, that's not terribly
suprising.)

> It might also be possible to define a context for each of the options;
> I assume most of them are only for output, but are some used on the
> input as well?

There are a few that make sense on input but you're correct that the
huge majority of them are output only.  We don't have them marked
internally which is which.

Take a look at the attached.  I think I got your requests, but added a
'default' at the end.  

"file" is probably "file open"   (or file upload in your case) 
"outfile" is probably "save as"

Let me know how this works for you and I'll check it in with any
needed tweaks.

RJL

C Coons wrote:
> I bought Garmins "MetroGuide" on ebay for less than $40 that has the 
> same roads as the City Select.  It doesn't have to be matched up with 
> only two GPS's like the City Select.  I think only version 4 will 
> download maps to a GPS AND allow autorouting in the GPS.  This is 
> discussed on this page http://gpsinformation.net/mgii.htm
> 
> Charlie

Great info... thanks,
Beverly Howard

 >> no <<

That's what I figured, but had to ask.

Thanks,
Beverly Howard

On 10/30/05, Beverly Howard wrote:
>
>We discussed downloadable maps but she has a way to go before that point, but I was wondering if it's possible to buy a single Garmin map for a specific local area to get people started rather than popping for the $100+ mapsource CD as step one?

The Legend has a built-in base map for the U.S. that should show major roads, cities, rivers, etc.

Other than that, no, it doesn't seem that you can buy individual maps, which is really asinine, but there you go.  Her best hope may be to find a friend who can "loan" her some map data via his/her PC.

Adam

A (very low tech) neighbor bought a Garmin Legend and when she couldn't 
figure out how to turn it on, she put it back in the box and was going 
to return it until I found out and gave her a comprehensive tutorial and 
think I got her started.

We discussed downloadable maps but she has a way to go before that 
point, but I was wondering if it's possible to buy a single Garmin map 
for a specific local area to get people started rather than popping for 
the $100+ mapsource CD as step one?

Beverly Howard

On 10/30/05, Robert Lipe wrote:
>
>I'm not opposed to a '-^3' that intermingles the options with the format
>info.

That would be pretty helpful, especially if it had a field for boolean, string, or integer.  (I'd make the text input boxes for integers shorters.)

>Yes, that's pretty close to how I'd imagine it working.  Even then, it
>might be under an "advanced options" button.

Good idea, since I'll have to come up with a way to hide/show them anyway.

> > Anyway, I have some questions about that "-h" screen: it looks like
>> there are a lot more boolean variables than are marked by "(0/1)"
>
>Now that you mention it, how about we remove the "(0/1)" from the
>literal strings and make that a property of "boolness"?  See attached
>patch and sample output.

Much better.  (I've updated http://www.gpsvisualizer.com/gpsbabel/ with the new list.)  And don't forget to take "(0/1)" off of the description of tpo:dumpheader!  By the way, if there are any others that require a specific range of choices (like "1..16" or "3,4,5"), adding those would be helpful as well; I've got my form set up to read output those as drop-downs.

> > it could be machine-read?  Or could something like -^2 be created for
>> listing all the options?
>
>We can't change the version two output, but if you're interested in helping
>spec out a version three, I'm hip with that.

I imagine it could look something like this:

TYPE    CONTEXT  CODE    SUFFIX  DESCRIPTION                            OPT_CODE     OPT_TYPE
----    -------  ----    ------  -----------                            --------     --------
file    rwrwrw   pcx     pcx     Garmin PCX 5
option           pcx             Default icon name                      deficon      string
serial  rwrwrw   garmin          Garmin serial/USB protocol
option           garmin          Length of generated shortnames         snlen        integer
option           garmin          Allow whitespace synth. shortnames     snwhite      boolean
option           garmin          Default icon name                      deficon      string
option           garmin          Return current position as a waypoint  get_posn     boolean
option           garmin          Command unit to power itself down      power_off    boolean
file    rw----   geo     loc     Geocaching.com .loc
option           geo             Default icon name                      deficon      string
option           geo             Omit Placer name                       nuke_placer  boolean
file    rw----   gcdb    pdb     GeocachingDB for Palm/OS

It might also be possible to define a context for each of the options; I assume most of them are only for output, but are some used on the input as well?

Adam

> I think the problem before was that if you didn't specify any of -t -r -w 
> then you would get nothing!

No.  The default was -w.  If you didn't specify -t and you had a file
that contained only tracks you got nothing becuaes you didn't specify
-t.

> Now it sounds like it always returns waypoints, and also returns routes and 
> tracks if -r or -t is specified.

We don't have _all_ the formats moved over yet, but -t, -r, and -w are
increasingly vestigal for the non-protocol formats.  (Protocol formats
still require these because at serial speeds, transferring everything by
default is just plain annoying.)  If we have all three on input, we try
our hardest to write all three on output.

> How do you tell it NOT to return waypoints?

By not giving it a file that contains waypoints?

RJL

> > Here's where -w, -t, and -r could come in handy... you could set it up
> > such that if one, and only one, of those flags is present, you create that
> > kind of file.  (I personally think it should work that way for things like
> > GPX as well: if -t is included in the command, but not -w, I think the
> > waypoints should be omitted!)
> 
> When it did work that way, it was by far the biggest support problem we had.

I think the problem before was that if you didn't specify any of -t -r -w 
then you would get nothing!
Now it sounds like it always returns waypoints, and also returns routes and 
tracks if -r or -t is specified.
How do you tell it NOT to return waypoints?

The way it should work, IMNSHO, is that if any one or two outputs are 
specified, JUST return those. If none are specified, return waypoints only.

Brian

> Here's where -w, -t, and -r could come in handy... you could set it up
> such that if one, and only one, of those flags is present, you create
> that kind of file.  (I personally think it should work that way for
> things like GPX as well: if -t is included in the command, but not -w,
> I think the waypoints should be omitted!)

When it did work that way, it was by far the biggest support problem we
had.

> >No there isn't. Of the 80+ formats we support only one of them
> >runs around renaming files behind your back.  I'm more in favor of
>
> It's really ONLY OziExplorer that does this?  I guess that's good

I can't any evidence that anyone else does this.

> to assume the following?:  If I ask for an output file named "ABC",
> gpsbabel will ALWAYS put out a single file called "ABC" (not even
> "ABC.pdb" or "ABC.gpx"), 

Right.

And I just 'fixed' the stdout case to not do the goofy rename thing with
the attached patch.

Of course, you now have the wierd case of multimode output on stdout.
"Doctor, doctor..."

> unless the output format is OziExplorer, in which case I will get
> one or more of the following: "ABC.wpt", "ABC.plt", "ABC.rte" -- and

Buy me a beer and I'll add an option to make that an error.  It really
does feel wrong.

RJL

Adam Schneider wrote:
> I thought people might like to see the half-finished thing I'm working on:
> 
> http://www.gpsvisualizer.com/gpsbabel/

Wow.  Looks promising!

I'm not opposed to a '-^3' that intermingles the options with the format
info.

> way, once it's finished, I'm hoping to use JavaScript to ONLY display
> the options for whichever format is selected as output!)

Yes, that's pretty close to how I'd imagine it working.  Even then, it
might be under an "advanced options" button.

> Anyway, I have some questions about that "-h" screen: it looks like
> there are a lot more boolean variables than are marked by "(0/1)"

Now that you mention it, how about we remove the "(0/1)" from the
literal strings and make that a property of "boolness"?  See attached
patch and sample output.

> it could be machine-read?  Or could something like -^2 be created for
> listing all the options?

We can't change the version two output, but if you're interested in helping
spec out a version three, I'm hip with that.

RJL

I thought people might like to see the half-finished thing I'm working on:

http://www.gpsvisualizer.com/gpsbabel/

I don't even know if it actually works yet as far as converting files (and so I've disabled the upload box just in case!).  I've just been trying to get the interface together.  The whole form is automatically generated from running "gpsbabel -^2" and "gpsbabel --help".  (By the way, once it's finished, I'm hoping to use JavaScript to ONLY display the options for whichever format is selected as output!)

Anyway, I have some questions about that "-h" screen: it looks like there are a lot more boolean variables than are marked by "(0/1)" in the help text.  For instance, a lot of the formats include a "prefer_shortnames" option, and I'd think that would also be 0/1.  If so, would it be possible to get that list cleaned up further so that it could be machine-read?  Or could something like -^2 be created for listing all the options?

Adam

On 10/29/05, Robert Lipe wrote:
>
> > The question then becomes, what do you output to STDOUT if the input
>> file contains both tracks and waypoints?
>
>I'm thinking we should treat that as a fatal error as the user has asked
>us to express the unexpressable, right?  If the user has said "put this
>in the single file called '-' (which represent STDOUT)" and has an input
>file that's not expressable in any one file, they deserve an error
>message becuase we have conflicted directions, right?

Here's where -w, -t, and -r could come in handy... you could set it up such that if one, and only one, of those flags is present, you create that kind of file.  (I personally think it should work that way for things like GPX as well: if -t is included in the command, but not -w, I think the waypoints should be omitted!)

> > is there a way to force GPSBabel to return only the file names that
>> it's going to create, without actually creating the files?
>
>No there isn't. Of the 80+ formats we support only one of them runs
>around renaming files behind your back.  I'm more in favor of bringing
>that format into line with the others than expanding on that.

It's really ONLY OziExplorer that does this?  I guess that's good to know.  So, correct me if I'm wrong, but should I always be able to assume the following?:  If I ask for an output file named "ABC", gpsbabel will ALWAYS put out a single file called "ABC" (not even "ABC.pdb" or "ABC.gpx"), unless the output format is OziExplorer, in which case I will get one or more of the following: "ABC.wpt", "ABC.plt", "ABC.rte" -- and I guess I can find out what was created by just checking for the existence of those three.

Adam

> >Shall we make it not do this renaming thing if the name already ends
> >in "plt", "wpt" or "rte" ir is "-"?
>
> Well, it's definitely a problem in the case of "-", and I think that
> has to be fixed.  

I think I agree.  I'll put that on my list for the next couple of days.

> The question then becomes, what do you output to STDOUT if the input
> file contains both tracks and waypoints?

I'm thinking we should treat that as a fatal error as the user has asked
us to express the unexpressable, right?  If the user has said "put this
in the single file called '-' (which represent STDOUT)" and has an input
file that's not expressable in any one file, they deserve an error
message becuase we have conflicted directions, right?

> is there a way to force GPSBabel to return only the file names that
> it's going to create, without actually creating the files?

No there isn't. Of the 80+ formats we support only one of them runs
around renaming files behind your back.  I'm more in favor of bringing
that format into line with the others than expanding on that.

RJL

I've taken Dave's recent examples and tied them into the GPSBabel build
process.  The interaction with our existing web framework and style
sheets isn't great, but we can work on that.

Neither of these shoudld be considered permanent, but here you can see
the somewhat gpsbabel-ified and somewhat less gpsbabel-ified mockups.

	http://www.gpsbabel.org/nr.html
	http://www.gpsbabel.org/readme.xhtml

The build process does also hock up a plain text text version that's
very much like what we've had.

Over the next few days I'll tug at the content, the markup, and the
delivery.  This would be a lovely time for everyone to review their
favorite sections (True Babelheads keep printouts of this stuff next
to the fireplace to enjoy with a favorite beverage...) and send me any
corrections or clarifications that sprout to mind.

RJL

On Thu, 27 Oct 2005 23:56:43 -0500
Robert Lipe <rob...@us...> wrote:

> Geeko-Boy wrote:
> > Can you up load multiple loc files to a garmin vista c?  Or must
> > the be upload one at a time?
> 
> Sure.  You can merge anything you like.  This is almost the example
> given in our README, but the syntax is:
> 
> gpsbabel -i geo -f 1.loc -f 2.loc -f 3.loc -f 4.loc -o garmin -F usb:
> 
> to merge those four files together and squirt them to a VistaC.  This
> example can be extended in the obvious ways by adding or deleting the
> '-f BLAH' entries.
> 
> 
> There are another zillion tricks you can do having GPSBabel suppress
> points within specified distance of each other and such, but for a
> simple merge, that's all it takes.
> 

Thanks.  I read that README 3 or 4 times I don't know how I missed this
example.  I appreciate the quick response though.  :-)

--
bruce

On 10/28/05, Robert Lipe wrote:
>
> > tracks.  And it automatically adds the filename suffixes.  But if you
>> select GPX or anything else (I tried Cetus, for example) as the output
>> format, it DOESN'T add a file suffix.  Is that correct?  (Is that
>> expected?)  I was really surprised to see those Ozi suffixes on my
>> files, since I didn't ask for them.
>
>Shall we make it not do this renaming thing if the name already ends
>in "plt", "wpt" or "rte" ir is "-"?

Well, it's definitely a problem in the case of "-", and I think that has to be fixed.  The question then becomes, what do you output to STDOUT if the input file contains both tracks and waypoints?

> > * I see that -w, -t, and -r tell GPSBabel to process waypoints,
>> tracks, and routes, respectively.  But if I feed in a file containing
>> BOTH tracks and waypoints (a GPX file), how do I STOP it from
>> processing one of those types??
>
>For the non receiver formats (i.e Magellan/Garmin serial/usb) -w -t and
>-r are increasingly vestigal.  If we have multile input types, we write
>multiple output types.  (We used to get a lot of complaining until we
>did.)
>
>I suppose we could add a "retain only" filter if this was important.

The problem I'm having is that I'm never sure exactly which files are output because I'm not peering into the input file to see what's there -- and I need to know that if I want to spit them out through a CGI; is there a way to force GPSBabel to return only the file names that it's going to create, without actually creating the files?

Adam

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct (11)	Nov (24)	Dec (45)
2003	Jan (17)	Feb (19)	Mar (26)	Apr (38)	May (20)	Jun (11)	Jul (39)	Aug (47)	Sep (14)	Oct (18)	Nov (6)	Dec (14)
2004	Jan (41)	Feb (46)	Mar (98)	Apr (71)	May (25)	Jun (40)	Jul (68)	Aug (59)	Sep (78)	Oct (34)	Nov (25)	Dec (52)
2005	Jan (51)	Feb (63)	Mar (47)	Apr (36)	May (23)	Jun (80)	Jul (78)	Aug (56)	Sep (34)	Oct (117)	Nov (145)	Dec (102)
2006	Jan (158)	Feb (117)	Mar (85)	Apr (116)	May (102)	Jun (80)	Jul (168)	Aug (161)	Sep (112)	Oct (88)	Nov (90)	Dec (84)
2007	Jan (115)	Feb (142)	Mar (76)	Apr (90)	May (165)	Jun (91)	Jul (158)	Aug (108)	Sep (58)	Oct (69)	Nov (136)	Dec (60)
2008	Jan (50)	Feb (87)	Mar (79)	Apr (90)	May (114)	Jun (55)	Jul (89)	Aug (105)	Sep (77)	Oct (91)	Nov (29)	Dec (89)
2009	Jan (83)	Feb (44)	Mar (58)	Apr (70)	May (62)	Jun (69)	Jul (96)	Aug (82)	Sep (100)	Oct (43)	Nov (44)	Dec (32)
2010	Jan (69)	Feb (61)	Mar (70)	Apr (85)	May (93)	Jun (145)	Jul (36)	Aug (57)	Sep (54)	Oct (89)	Nov (44)	Dec (58)
2011	Jan (39)	Feb (59)	Mar (29)	Apr (35)	May (37)	Jun (31)	Jul (43)	Aug (48)	Sep (23)	Oct (30)	Nov (74)	Dec (49)
2012	Jan (43)	Feb (35)	Mar (38)	Apr (44)	May (60)	Jun (32)	Jul (34)	Aug (43)	Sep (42)	Oct (38)	Nov (46)	Dec (21)
2013	Jan (16)	Feb (30)	Mar (21)	Apr (25)	May (13)	Jun (29)	Jul (31)	Aug (25)	Sep (17)	Oct (22)	Nov (19)	Dec (31)
2014	Jan (11)	Feb (16)	Mar (65)	Apr (27)	May (24)	Jun (45)	Jul (56)	Aug (23)	Sep (18)	Oct (26)	Nov (11)	Dec (11)
2015	Jan (25)	Feb (24)	Mar (30)	Apr (26)	May (25)	Jun (23)	Jul (22)	Aug (30)	Sep (17)	Oct (21)	Nov (43)	Dec (31)
2016	Jan (46)	Feb (55)	Mar (24)	Apr (17)	May (27)	Jun (9)	Jul (47)	Aug (15)	Sep (8)	Oct (16)	Nov (3)	Dec (17)
2017	Jan (3)	Feb (8)	Mar (18)	Apr (6)	May (17)	Jun (6)	Jul (22)	Aug (6)	Sep (19)	Oct (11)	Nov (20)	Dec (12)
2018	Jan	Feb (8)	Mar (7)	Apr (1)	May (24)	Jun (9)	Jul (34)	Aug (24)	Sep (17)	Oct (16)	Nov (4)	Dec (17)
2019	Jan (9)	Feb (4)	Mar (27)	Apr (31)	May (26)	Jun (28)	Jul (41)	Aug (29)	Sep (9)	Oct (14)	Nov (12)	Dec (38)
2020	Jan (13)	Feb	Mar (10)	Apr (4)	May (30)	Jun (10)	Jul (7)	Aug (62)	Sep (12)	Oct (5)	Nov (29)	Dec (19)
2021	Jan (5)	Feb (7)	Mar (11)	Apr (3)	May (29)	Jun (10)	Jul	Aug	Sep (2)	Oct (6)	Nov (1)	Dec (2)
2022	Jan (7)	Feb (31)	Mar (17)	Apr	May (3)	Jun (21)	Jul (11)	Aug	Sep (16)	Oct (7)	Nov (6)	Dec (6)
2023	Jan (1)	Feb (2)	Mar	Apr	May	Jun (2)	Jul (13)	Aug (3)	Sep	Oct	Nov	Dec (2)
2024	Jan (8)	Feb (2)	Mar (11)	Apr (10)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

gpsbabel-misc Mailing List for GPSBabel (Page 341)

gpsbabel-misc — Miscellaneous GPSBabel discussions