Guess I should mention the reason I want the speed portion (beside simply
having all the data transfered) is to assist in eliminating log records that
were recorded while at a standstill (ie: traffic lights) or other short term
delays. With this in mind, I wanted to set a minimum speed threshold as one
of my filters.
I do have lat/long filters for eliminating "standstill" records and also
added a fudge factor (threshold) for the small amount of gps drift in the
----- Original Message -----
From: "Immersive Technologies" <immersivetech@...>
To: "Robert Lipe" <robertlipe@...>
Sent: Thursday, July 01, 2004 8:46 AM
Subject: Re: [Gpsbabel-misc] Delorme .gpl to nmea format - missing altitude
> The "readgpl" conversion utility provided at
> http://www.frontiernet.net/~werner/gps/ does manage to extract the speed
> data from a gpl file. Unfortunately, his program does not produce the
> correct altitude value... at least from the Demo.gpl file version
> provided by Delorme (I think the last update for the readgpl program was
> 2002). So it would seem possible to include the speed portion in your
> GPSBabel program too.
> It would make sense that a ".anr" or ".rte" route file (ie: routes simply
> mapped out in the Delorme software) wouldn't have speed data and that's ok
> for this type, but still need the altitude from these formats.
> Oh please sir, may I have another helping?
> ----- Original Message -----
> From: "Robert Lipe" <robertlipe@...>
> To: "Immersive Technologies" <immersivetech@...>
> Cc: <gpsbabel-misc@...>
> Sent: Thursday, July 01, 2004 7:03 AM
> Subject: Re: [Gpsbabel-misc] Delorme .gpl to nmea format - missing
> and speed
> > Immersive Technologies wrote:
> > > has neither the altitude or speed data is included and only
> > > values are output for altitude, and I think a blank value for
> > Alt was omitted from the NMEA writer. I've fixed that. The guy that
> > requested the NMEA writer was confident that nobody used the speed
> > value and recalculated it anyway. Is that not the case? The delorme
> > file you're converting it from doesn't have this data, so we'd have to
> > compute it if whatever you're feeding it to wants that.
> > RJL