Re: [Gpsbabel-code] Building gpsbabel on windows using msvc

[Gerhard O. <ger...@gm...>]

On 9/23/07, Robert Lipe <rob...@gp...> wrote:
> > There are a few things before the second patch can be applied: I
> > should remove debug printouts, clarify what is a valid GPS point etc.
>
> Perhaps the two of you can partner up on that.

We have had a little offlist discussion. I can fixup the "garmin" part
if someone else tackles the GTC part (or an option to "garmin" is
accepted). I see no point cleaning up to add more dead code to
"garmin" though....

>
> > handling for normal handling, I have seen no reason to do so. Robert
> > has pointed that the special stuff should be in the GTC format. So for
> > the patch to be useful, I have waited for motivation to work on GTC
> > format (which is much more job than implement the device support,
>
> My point was that something needed to use it. Having a couple extra
> hundred lines of code in garmin.c without any formats that can use the
> extra data didn't seem like a plan. So turned off the code until someone
> was ready to hook it up to something.

The extra "fitness" data (laps, distance etc) is put the extra
information in description/Notes, to be able to post process it in
other programs. However, I did not want to change the existing
functionality why an option to "garmin" to handle data fitness style
or a full implementation in GTC. GTC _is_ a better solution, but it
gives me personally nothing why it just has lower priority for me.

Even with full GTC support, there are still some open issues in the
"garmin" driver: A user may not want to collect all data all the time,
why either an option to "garmin" is required or some funky output
format input hook.

>
> > a secondary is to support GPS devices. With my view, handling tracks
> > without GPS information is natural, which gives a "fitness" behavior
> > to track handling that may not be desired to other uses (for instance
> > track points with only heartrate and no GPS info). We agree that
>
>
>
> That can be handled in extra_data. Data not associated with a position
> is not a core concept in GPSBabel becuase it's not a common trait in the
> data files we convert or the devices we use. Create trackpoints with
> invalid lat/lons if you like. The moment you convert those to any progam
> that expects lat lons or try to do math like distance of a path when
> some of your trackpoints are at the north pole and life will be bad.
> (I'd probably just use the most recent location info which would avoid
> some of that wierdness.)

Fake position is how that is handled right now. (That is a large
portion of the patch...) However, I would be hesitant to activate this
behaviour by default, even just for "fitness" users.


Thanks for the great job with GPSBabel.

Gerhard