From: Robert Lipe <robertlipe@us...> - 2002-11-13 15:10:11
> foolishness or shortsightedness on my side :-) I once again reiterate my
> former suggestion to split the complete gpsbabel processing flow into
> three parts:
> # Input scan of (possibly several) input files
> # Invocation of some intermediate data massaging steps, to prepare
> the read-in data in an appropriate way for the adjacent output step.
> Some of the provided intermediate processing steps here would be
> targeted towards special kinds of receivers, but would at least
> clearly be specifiable.
> # Output to the desired format, with the module just ensuring the
> do's and don't's, or producing informative belches otherwise in case
> the intermdediate steps didn't reprocess the incoming data
There are already distinct input and output phases. My resistance to
step #2 (which is lowering, but mostly for route optimizations) is that you
can have multiple outputs for each input so having those middle stages
modify the input is a problem.
gpsbabel -i blah -f blerf -o garmin -F /dev/ttyS0 -o magellan -F /dev/ttyS1
(Yes, people really do this sort of thing.)
So now you get involved in cloning the data internally so this
"massaging" really has to happen for each output independently anyway
for this to work. (If the garmin unit is a banana and waypoint names
get whacked to 6 upper case characters and the magellan is a Meridian
with 8 and mixed case, you can't let the first output modify the data
becuase it'd lose for the second.)
Maybe we keep talking past each other. Show me a patch.
Would the change I proposed last night solve your specific problem with
Get latest updates about Open Source Projects, Conferences and News.