From: Ron Parker <ron@pa...> - 2003-04-23 15:37:08
Something's been bugging me about the -s option to gpsbabel. Specifically,
it seems to me that -s only works if the output format takes it into
account, and there seem to be a number of output formats that don't do
so. Would it be a worthwhile use of my time to create a -x filter to
From: Robert Lipe <robertlipe@us...> - 2003-04-23 16:04:21
Ron Parker wrote:
> Something's been bugging me about the -s option to gpsbabel. Specifically,
> it seems to me that -s only works if the output format takes it into
> account, and there seem to be a number of output formats that don't do
> so. Would it be a worthwhile use of my time to create a -x filter to
> replace -s?
You're not the first to be troubled by this. I've never been terribly
happy with this behaviour and this was one of Alex's justification for
-x to begin with.
The problem is that filters are "destructive" to the data stream while
doing the work in the backend allows commands like
gpsbabel -s -i gpx -f blah.gpx -o magellan -F /dev/ttyS0 -o garmin /dev/ttyS1
to still work sensibly. Two different receivers on two different serial
ports is a bit funky, but it exaggerates the problems nicely to make it
easier to see. Garmin will see different waypoint lengths depending on
what's negotiated at runtime on the receiver, so chomping the names up
front is a problem.
Maybe we could put something like a mkshort handle into the ff_vec
that would allow main to invoke a copy/filter cycle on the data before
invoking it, but I'm not really sure the "gore factor" would be any
lower with this approach.
What do you think?
Get latest updates about Open Source Projects, Conferences and News.