gpsbabel-misc — Miscellaneous GPSBabel discussions

Re: [Gpsbabel-misc] Unable to Download GPSbabel

[Greg <we...@we...>]



> On Mar 4, 2026, at 9:10 PM, ma...@mj... wrote:
> 
> Download works for me, PayPal does not.
> 
> 
> 
> On 2026-03-05 13:07, ran...@go... <mailto:ran...@go...> wrote:
> 
>> Download links worked only after disabling both my VPN and Free Download Manager (FDM). 
>>  
>> Randall J. Gow
>> 893 Mildred Rd.
>> Mc Kee, KY 40447-7158
>> Cell: (606) 865-4321
>> Email: ran...@go... <mailto:ran...@go...>
>>  
>> From: tsteven4 <tst...@gm... <mailto:tst...@gm...>> 
>> Sent: Wednesday, March 4, 2026 16:15
>> To: ran...@go... <mailto:ran...@go...>; gps...@li... <mailto:gps...@li...>
>> Subject: Re: [Gpsbabel-misc] Unable to Download GPSbabel
>>  
>> Thanks for letting us know.  However all 4 download links worked for me just now.  The paypal link did not work as you reported.
>> 
>> On 3/4/2026 10:05 AM, ran...@go... <mailto:ran...@go...> wrote:
>> Download links at https://www.gpsbabel.org/download.html are broken. All of the links return a webpage (plan9.php) which doesn't load.
>> 
>> Also, while attempting to find a method of contacting you, I clicked on your PayPal donation link which also returns an error.
>> 
>> <image001.png>
>>  
>> Randall J. Gow
>>  
>> 
>> 
>> 
>> _______________________________________________
>> Gpsbabel-misc mailing list http://www.gpsbabel.org <http://www.gpsbabel.org/>
>> Gps...@li... <mailto:Gps...@li...>
>> To unsubscribe, change list options, or see archives, visit:
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>> 
>> _______________________________________________
>> Gpsbabel-misc mailing list http://www.gpsbabel.org <http://www.gpsbabel.org/>
>> Gps...@li... <mailto:Gps...@li...>
>> To unsubscribe, change list options, or see archives, visit:
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org <http://www.gpsbabel.org/>
> Gps...@li... <mailto:Gps...@li...>
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Re: [Gpsbabel-misc] Unable to Download GPSbabel

[<ma...@mj...>]

Download works for me, PayPal does not.

On 2026-03-05 13:07, ran...@go... wrote:

> Download links worked only after disabling both my VPN and Free 
> Download Manager (FDM).
> 
> -------------------------
> 
> _Randall J. Gow_
> 
> _893 Mildred Rd._
> 
> _Mc Kee, KY 40447-7158_
> 
> _Cell: (606) 865-4321_
> 
> _Email: randall.gow@gows.net_
> 
> From: tsteven4 <tst...@gm...>
> Sent: Wednesday, March 4, 2026 16:15
> To: ran...@go...; gps...@li...
> Subject: Re: [Gpsbabel-misc] Unable to Download GPSbabel
> 
> Thanks for letting us know.  However all 4 download links worked for me 
> just now.  The paypal link did not work as you reported.
> 
> On 3/4/2026 10:05 AM, ran...@go... wrote:
> 
>> Download links at https://www.gpsbabel.org/download.html are broken. 
>> All of the links return a webpage (plan9.php) which doesn't load.
>> 
>> Also, while attempting to find a method of contacting you, I clicked 
>> on your PayPal donation link which also returns an error.
>> 
>> -------------------------
>> 
>> _Randall J. Gow_
>> 
>> _______________________________________________
>> 
>> Gpsbabel-misc mailing list http://www.gpsbabel.org
>> 
>> Gps...@li...
>> 
>> To unsubscribe, change list options, or see archives, visit:
>> 
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
> 
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Re: [Gpsbabel-misc] Unable to Download GPSbabel

[<ran...@go...>]

Download links worked only after disabling both my VPN and Free Download Manager (FDM). 

 

  _____  

Randall J. Gow

893 Mildred Rd.

Mc Kee, KY 40447-7158

Cell: (606) 865-4321

Email:  <mailto:ran...@go...> ran...@go...

 

From: tsteven4 <tst...@gm...> 
Sent: Wednesday, March 4, 2026 16:15
To: ran...@go...; gps...@li...
Subject: Re: [Gpsbabel-misc] Unable to Download GPSbabel

 

Thanks for letting us know.  However all 4 download links worked for me just now.  The paypal link did not work as you reported.

On 3/4/2026 10:05 AM, ran...@go... <mailto:ran...@go...>  wrote:

Download links at https://www.gpsbabel.org/download.html are broken. All of the links return a webpage (plan9.php) which doesn’t load.

Also, while attempting to find a method of contacting you, I clicked on your PayPal donation link which also returns an error.



 


  _____  


Randall J. Gow

 






_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
Gps...@li... <mailto:Gps...@li...> 
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Re: [Gpsbabel-misc] Unable to Download GPSbabel

[tsteven4 <tst...@gm...>]

Thanks for letting us know.  However all 4 download links worked for me 
just now.  The paypal link did not work as you reported.

On 3/4/2026 10:05 AM, ran...@go... wrote:
>
> Download links at https://www.gpsbabel.org/download.html are broken. 
> All of the links return a webpage (plan9.php) which doesn’t load.
>
> Also, while attempting to find a method of contacting you, I clicked 
> on your PayPal donation link which also returns an error.
>
> ------------------------------------------------------------------------
>
> /Randall J. Gow/
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gpsbabel-misc] Unable to Download GPSbabel

[<ran...@go...>]

Download links at https://www.gpsbabel.org/download.html are broken. All of
the links return a webpage (plan9.php) which doesn't load.

Also, while attempting to find a method of contacting you, I clicked on your
PayPal donation link which also returns an error.



 

  _____  

Randall J. Gow

 

Re: [Gpsbabel-misc] Converting NV2 and NV3 files to GPX

[Robert L. <rob...@gp...>]

Confirming that's none of the formats in

https://www.gpsbabel.org/capabilities.html

...or that i even recognize as requested in any significant way.



See the first two questions at

GPSBabel: Frequently Asked Questions https://www.gpsbabel.org/FAQ.html

On Tue, Feb 10, 2026, 8:43 AM Peter Klemm <pet...@ou...>
wrote:

> Hi
>
>
>
> I have obtained some Navionics .NV2 and .NV3 files and would like to
> convert them to GPX to load into a different sounder. Unfortunately I
> haven’t been successful in loading them into GPSBabel – there doesn’t
> appear to be a supported file format.
>
>
>
> The web searching I have done suggests that GPSBabel is the way to go, but
> I’m not having any luck so far.
>
>
>
> Have downloaded the latest version today and installed onto a Windows 11
> PC.
>
>
>
> Opening the files in Notepad shows the text NAVIONICS early in the file.
> Unfortunately I do not know the source device the files were downloaded
> from.
>
>
>
> Does anyone have any ideas?
>
>
>
> Thanks in advance
>
>
>
> Peter
>
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>

[Gpsbabel-misc] Converting NV2 and NV3 files to GPX

[Peter K. <pet...@ou...>]

Hi

I have obtained some Navionics .NV2 and .NV3 files and would like to convert them to GPX to load into a different sounder. Unfortunately I haven't been successful in loading them into GPSBabel - there doesn't appear to be a supported file format.

The web searching I have done suggests that GPSBabel is the way to go, but I'm not having any luck so far.

Have downloaded the latest version today and installed onto a Windows 11 PC.

Opening the files in Notepad shows the text NAVIONICS early in the file. Unfortunately I do not know the source device the files were downloaded from.

Does anyone have any ideas?

Thanks in advance

Peter

Re: [Gpsbabel-misc] TorquePro triplog format

[Robert L. <rob...@gp...>]

>
> In fact, it is (supposed to be) the timezone, but I think that the
> Torque Pro just sets it wrong.
>

Recording GPS-style data in localtime is just a bad idea, IMO. Was it
recorded when DST was in effect? What if you drive over a TZ boundary? What
if the data was recorded before a locale changed TZs?

Still, we should be able to handle this. Thank you, tsteven4, for tackling
that.

But can we get a way to override the Time header?
> It is all fine that gpsbabel sets it to the current time by default, but


No. Sorry. It's working per the GPX spec. You're free (and
encouraged—that's the point of open source) to modify
<https://github.com/GPSBabel/gpsbabel/blob/c1b200f3c12878ff6bf325b8369351d3c16e41d5/gpx.cc#L1069>
your copy to do whatever you like, but we're well past the days of
modifying our spec-conforming output to accommodate quirky readers that
didn't read and understand the specifications.

https://www.topografix.com/gpx_manual.asp#time

"Creation date/time of the GPX file
<https://www.topografix.com/gpx_manual.asp#time>"

Supporting custom writers for every different GPX reader is the opposite of
the goal of GPX.

That said, i have also asked the Calimoto devs to not assume that the

timestamp in the file is the time of the ride, as one cannot assume
>

That is the better approach.

It's a drag that you're caught between two pieces of software that aren't
cooperating, but it's really not our goal to be the janitor of all possible
data.

RJL

Re: [Gpsbabel-misc] TorquePro triplog format

[Mathias K. <ma...@ko...>]

Steven

On 22/1/26 22:31, tsteven4 wrote:
> In your data GMT is NOT the time zone abbreviation, which would be SGT 
> for Singapore time.  The offset is +08:00.  This is assumed to be 
> relative to UTC, i.e. UTC+08:00.  This matches what would be expected 
> for the location indicated which is in Singapore.

In fact, it is (supposed to be) the timezone, but I think that the 
Torque Pro just sets it wrong.
I had a check through my phone settings and the Torque settings, and 
found no way to actually set the timezone string.

I will report this to the Torque development team

> 
> There is some progress regarding the glibc bug decoding the day of the 
> week, hopefully that will be fixed soon.

Good to know :-)


But can we get a way to override the Time header?
It is all fine that gpsbabel sets it to the current time by default, but 
it woud be much more user-friendly if the user were given a chance to
decide how it is filled

That said, i have also asked the Calimoto devs to not assume that the
timestamp in the file is the time of the ride, as one cannot assume
that when tools like gpsbabel might be run much after the actual time 
the original track was recorded.



> 
> On 1/22/2026 6:52 AM, Mathias Koerber wrote:
>>
>>
>> On 22/1/26 04:49, tsteven4 wrote:
>>> We use a version of strptime from glib. The current documentation is 
>>> at https://sourceware.org/glibc/manual/latest/html_mono/ 
>> > libc.html#Interpret-string-according-to-given-format, although our > 
>> version is a bit down level.  python strptime is not used by gpsbabel.
>>>
>>> 1) glibc strptime expects the time zone abbreviation to be terminated 
>>> by a whitespace or at the end of a line.  This is problematic with 
>>> your input as the numeric time zone directly follows the time zone 
>>> abbreviation.  One way to work around this is to change your style 
>>> file replacing %Z by GMT.
>>
>> Sure, if I can be sure that all input files will be use GMT, but so 
>> far that is not clear.
>>
>> It would be useful if strptime has a means to ignore certain parts of 
>> the input string (maybe by specifying something like %-3.3i
>>
>>> IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S GMT%z %Y"
>>>
>>> 2) There is a bug in glibc that fails to advance the parse point in 
>>> the string for the abbreviated form of the weekday name for non- 
>>> localized weekday names.  This causes an issue if the weekday name 
>>> isn't the last field as in your case.  Normally the weekday name is 
>>> checked against localized versions, but we don't use localization.  
>>> If your data is always from the same day of the week you should be 
>>> able to replace %a by that literal, e.g.
>>>
>>> IFIELD                LOCAL_TIME,"","Fri %b %d %H:%M:%S GMT%z %Y"
>>>
>>> I have submitted a patch to glibc for the weekday name issue.  I 
>>> don't know when and if they will act on it.
>>
>> Thanks. Sadly the Weekday does change i my input data
>>
>> I guess I will have to extend my preprocess to replace any timezone
>> abbreviation at that point with 'GMT ', esp as the parsed value is not 
>> interpreted by strptime (does not any field in the tm struct)
>>
>>
>>
>> Re the other issue:
>>> 1. The time tag in the header is annotated as "GPX file creation time"
>> > in the gpx 1.0 schema.  It is optional, however gpsbabel always
>> > includes it.  The gpx file produced by gpsbabel should validate
>> > against the gpx 1.0 or 1.1 schema.  It sound like your downstream
>> > program is making assumptions that aren't required by the schema.
>>
>> Sure, but as it often the case that avvess to the developers 
>> of )possibly several) downstream applications may be hard, iI think 
>> gpsbabel would do good to add some option to allow selective 'fudging' 
>> of this header to a user-specified value (or also to select the first 
>> or earliest individual timestamp found in the file for that header)
>>
>> This would make it much more user-friendly, esp when processing old
>> input files for applications that use the header time for indexing.
>>
>> This also would avoid having to separately post=process thge gpsbabel 
>> output just to replace that timestamp.
>>
>>
>>
>>
>>
>> > Issues can be opened at https://github.com/GPSBabel/gpsbabel/issues.
>>
>>
>>> On 1/20/2026 4:51 PM, Robert Lipe wrote:
>>>> Preprocess with sed, awk, perl, python, spreadsheet, or whatever 
>>>> other army knife you're comfortable with... Or just go modify the 
>>>> xcsv parser to fit.
>>>>
>>>> You can just ignore fields at end of line if you're only reading.
>>>>
>>>> On Tue, Jan 20, 2026, 11:27 AM Mathias Koerber <ma...@ko...> 
>>>> wrote:
>>>>
>>>>     I am trying to convert some triplogs from the Android Torque Pro 
>>>> app
>>>>     to GPX
>>>>
>>>>     The format TorquePro exports is a CSV file:
>>>>     > GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h),
>>>>     Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity
>>>>     X(G), Gravity Y(G), Gravity Z(G),
>>>>     > Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021
>>>> 19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
>>>>     > Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021
>>>> 19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,
>>>>
>>>>     I am currently syumbling over how to parse the the time formats,
>>>>     esp the
>>>>        GMT+08:00
>>>>     part
>>>>
>>>>     My current style file looks line this:
>>>>     > # GPSBabel Style: Torque Pro triplog
>>>>     > # Author: Mathias Koerber
>>>>     > # Version: 0.01
>>>>     > # Date: 2026-01-21
>>>>     >
>>>>     > DESCRIPTION           Torque Pro triplog
>>>>     > EXTENSION             csv
>>>>     >
>>>>     > ENCODING              US-ASCII
>>>>     > FIELD_DELIMITER       COMMA
>>>>     > RECORD_DELIMITER      NEWLINE
>>>>     >
>>>>     >
>>>>     > PROLOGUE              GPS Time, Device Time, Longitude,
>>>>     Latitude,GPS Speed(km/h), Horizontal Dilution of Precision,
>>>>     Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
>>>>     >
>>>>     > IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>>>     > IGNORE                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>>>     > IFIELD                LAT_DECIMAL,"","%f"
>>>>     > IFIELD                LON_DECIMAL,"","%f"
>>>>     > IFIELD                PATH_SPEED,"","%f"
>>>>     > IFIELD                GPS_HDOP,"","%f"
>>>>     > IFIELD                ALT_METERS,"","%.0f"
>>>>
>>>>     However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03
>>>>     GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.
>>>>
>>>>     So I gather the %z representing included in my system's strftime
>>>>     is not
>>>>     supported?
>>>>
>>>>     >      %z    is replaced by the time zone offset from UTC; a
>>>>     leading plus sign stands for east of UTC, a minus sign for
>>>>     >            west of UTC, hours and minutes follow with two digits
>>>>     each and no delimiter between them (common form for
>>>>     >            RFC 822 date headers).
>>>>
>>>>     which suggests it wants the RFC822 timezone format +HHmm but 
>>>> this is
>>>>     +HH:MM,. Python from 3.7 allows the colon for the %z conversion
>>>>     but that
>>>>     does not seem to apply here.
>>>>
>>>>     How can I parse that part of the time definition?
>>>>     Is there a way to ignore parts of a field?
>>>>
>>>>     or do I need to preprocess the files with python to reformat the
>>>>     timestamps?
>>>>
>>>>     Do I also have to IGNORE the final fields (Bearing, Gravity etc) 
>>>> I am
>>>>     not interested in?
>>>>     (I could not find any IFIELD definitions for those)
>>>>
>>>>
>>>>     I am using gpsbabel 1.10.0 on Mac (from homebrew)
>>>>
>>>>
>>>>     Any help appreciated
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Gpsbabel-misc mailing list http://www.gpsbabel.org
>>>>     Gps...@li...
>>>>     To unsubscribe, change list options, or see archives, visit:
>>>>     https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
>>>> Gps...@li...
>>>> To unsubscribe, change list options, or see archives, visit:
>>>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>

Re: [Gpsbabel-misc] TorquePro triplog format

[tsteven4 <tst...@gm...>]

In your data GMT is NOT the time zone abbreviation, which would be SGT 
for Singapore time.  The offset is +08:00.  This is assumed to be 
relative to UTC, i.e. UTC+08:00.  This matches what would be expected 
for the location indicated which is in Singapore.

There is some progress regarding the glibc bug decoding the day of the 
week, hopefully that will be fixed soon.

On 1/22/2026 6:52 AM, Mathias Koerber wrote:
>
>
> On 22/1/26 04:49, tsteven4 wrote:
>> We use a version of strptime from glib. The current documentation is 
>> at https://sourceware.org/glibc/manual/latest/html_mono/ 
> > libc.html#Interpret-string-according-to-given-format, although our > 
> version is a bit down level.  python strptime is not used by gpsbabel.
>>
>> 1) glibc strptime expects the time zone abbreviation to be terminated 
>> by a whitespace or at the end of a line.  This is problematic with 
>> your input as the numeric time zone directly follows the time zone 
>> abbreviation.  One way to work around this is to change your style 
>> file replacing %Z by GMT.
>
> Sure, if I can be sure that all input files will be use GMT, but so 
> far that is not clear.
>
> It would be useful if strptime has a means to ignore certain parts of 
> the input string (maybe by specifying something like %-3.3i
>
>> IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S GMT%z %Y"
>>
>> 2) There is a bug in glibc that fails to advance the parse point in 
>> the string for the abbreviated form of the weekday name for 
>> non-localized weekday names.  This causes an issue if the weekday 
>> name isn't the last field as in your case.  Normally the weekday name 
>> is checked against localized versions, but we don't use 
>> localization.  If your data is always from the same day of the week 
>> you should be able to replace %a by that literal, e.g.
>>
>> IFIELD                LOCAL_TIME,"","Fri %b %d %H:%M:%S GMT%z %Y"
>>
>> I have submitted a patch to glibc for the weekday name issue.  I 
>> don't know when and if they will act on it.
>
> Thanks. Sadly the Weekday does change i my input data
>
> I guess I will have to extend my preprocess to replace any timezone
> abbreviation at that point with 'GMT ', esp as the parsed value is not 
> interpreted by strptime (does not any field in the tm struct)
>
>
>
> Re the other issue:
>> 1. The time tag in the header is annotated as "GPX file creation time"
> > in the gpx 1.0 schema.  It is optional, however gpsbabel always
> > includes it.  The gpx file produced by gpsbabel should validate
> > against the gpx 1.0 or 1.1 schema.  It sound like your downstream
> > program is making assumptions that aren't required by the schema.
>
> Sure, but as it often the case that avvess to the developers of 
> )possibly several) downstream applications may be hard, iI think 
> gpsbabel would do good to add some option to allow selective 'fudging' 
> of this header to a user-specified value (or also to select the first 
> or earliest individual timestamp found in the file for that header)
>
> This would make it much more user-friendly, esp when processing old
> input files for applications that use the header time for indexing.
>
> This also would avoid having to separately post=process thge gpsbabel 
> output just to replace that timestamp.
>
>
>
>
>
> > Issues can be opened at https://github.com/GPSBabel/gpsbabel/issues.
>
>
>> On 1/20/2026 4:51 PM, Robert Lipe wrote:
>>> Preprocess with sed, awk, perl, python, spreadsheet, or whatever 
>>> other army knife you're comfortable with... Or just go modify the 
>>> xcsv parser to fit.
>>>
>>> You can just ignore fields at end of line if you're only reading.
>>>
>>> On Tue, Jan 20, 2026, 11:27 AM Mathias Koerber <ma...@ko...> 
>>> wrote:
>>>
>>>     I am trying to convert some triplogs from the Android Torque Pro 
>>> app
>>>     to GPX
>>>
>>>     The format TorquePro exports is a CSV file:
>>>     > GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h),
>>>     Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity
>>>     X(G), Gravity Y(G), Gravity Z(G),
>>>     > Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021
>>> 19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
>>>     > Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021
>>> 19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,
>>>
>>>     I am currently syumbling over how to parse the the time formats,
>>>     esp the
>>>        GMT+08:00
>>>     part
>>>
>>>     My current style file looks line this:
>>>     > # GPSBabel Style: Torque Pro triplog
>>>     > # Author: Mathias Koerber
>>>     > # Version: 0.01
>>>     > # Date: 2026-01-21
>>>     >
>>>     > DESCRIPTION           Torque Pro triplog
>>>     > EXTENSION             csv
>>>     >
>>>     > ENCODING              US-ASCII
>>>     > FIELD_DELIMITER       COMMA
>>>     > RECORD_DELIMITER      NEWLINE
>>>     >
>>>     >
>>>     > PROLOGUE              GPS Time, Device Time, Longitude,
>>>     Latitude,GPS Speed(km/h), Horizontal Dilution of Precision,
>>>     Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
>>>     >
>>>     > IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>>     > IGNORE                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>>     > IFIELD                LAT_DECIMAL,"","%f"
>>>     > IFIELD                LON_DECIMAL,"","%f"
>>>     > IFIELD                PATH_SPEED,"","%f"
>>>     > IFIELD                GPS_HDOP,"","%f"
>>>     > IFIELD                ALT_METERS,"","%.0f"
>>>
>>>     However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03
>>>     GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.
>>>
>>>     So I gather the %z representing included in my system's strftime
>>>     is not
>>>     supported?
>>>
>>>     >      %z    is replaced by the time zone offset from UTC; a
>>>     leading plus sign stands for east of UTC, a minus sign for
>>>     >            west of UTC, hours and minutes follow with two digits
>>>     each and no delimiter between them (common form for
>>>     >            RFC 822 date headers).
>>>
>>>     which suggests it wants the RFC822 timezone format +HHmm but 
>>> this is
>>>     +HH:MM,. Python from 3.7 allows the colon for the %z conversion
>>>     but that
>>>     does not seem to apply here.
>>>
>>>     How can I parse that part of the time definition?
>>>     Is there a way to ignore parts of a field?
>>>
>>>     or do I need to preprocess the files with python to reformat the
>>>     timestamps?
>>>
>>>     Do I also have to IGNORE the final fields (Bearing, Gravity etc) 
>>> I am
>>>     not interested in?
>>>     (I could not find any IFIELD definitions for those)
>>>
>>>
>>>     I am using gpsbabel 1.10.0 on Mac (from homebrew)
>>>
>>>
>>>     Any help appreciated
>>>
>>>
>>>     _______________________________________________
>>>     Gpsbabel-misc mailing list http://www.gpsbabel.org
>>>     Gps...@li...
>>>     To unsubscribe, change list options, or see archives, visit:
>>>     https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>>
>>>
>>>
>>> _______________________________________________
>>> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
>>> Gps...@li...
>>> To unsubscribe, change list options, or see archives, visit:
>>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>

Re: [Gpsbabel-misc] TorquePro triplog format

[Mathias K. <ma...@ko...>]

On 22/1/26 04:49, tsteven4 wrote:
> We use a version of strptime from glib.  The current documentation is at 
> https://sourceware.org/glibc/manual/latest/html_mono/ 
 > libc.html#Interpret-string-according-to-given-format, although our > 
version is a bit down level.  python strptime is not used by gpsbabel.
> 
> 1) glibc strptime expects the time zone abbreviation to be terminated by 
> a whitespace or at the end of a line.  This is problematic with your 
> input as the numeric time zone directly follows the time zone 
> abbreviation.  One way to work around this is to change your style file 
> replacing %Z by GMT.

Sure, if I can be sure that all input files will be use GMT, but so far 
that is not clear.

It would be useful if strptime has a means to ignore certain parts of 
the input string (maybe by specifying something like %-3.3i

> IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S GMT%z %Y"
> 
> 2) There is a bug in glibc that fails to advance the parse point in the 
> string for the abbreviated form of the weekday name for non-localized 
> weekday names.  This causes an issue if the weekday name isn't the last 
> field as in your case.  Normally the weekday name is checked against 
> localized versions, but we don't use localization.  If your data is 
> always from the same day of the week you should be able to replace %a by 
> that literal, e.g.
> 
> IFIELD                LOCAL_TIME,"","Fri %b %d %H:%M:%S GMT%z %Y"
> 
> I have submitted a patch to glibc for the weekday name issue.  I don't 
> know when and if they will act on it.

Thanks. Sadly the Weekday does change i my input data

I guess I will have to extend my preprocess to replace any timezone
abbreviation at that point with 'GMT ', esp as the parsed value is not 
interpreted by strptime (does not any field in the tm struct)



Re the other issue:
> 1. The time tag in the header is annotated as "GPX file creation time"
 > in the gpx 1.0 schema.  It is optional, however gpsbabel always
 > includes it.  The gpx file produced by gpsbabel should validate
 > against the gpx 1.0 or 1.1 schema.  It sound like your downstream
 > program is making assumptions that aren't required by the schema.

Sure, but as it often the case that avvess to the developers of 
)possibly several) downstream applications may be hard, iI think 
gpsbabel would do good to add some option to allow selective 'fudging' 
of this header to a user-specified value (or also to select the first or 
earliest individual timestamp found in the file for that header)

This would make it much more user-friendly, esp when processing old
input files for applications that use the header time for indexing.

This also would avoid having to separately post=process thge gpsbabel 
output just to replace that timestamp.





 > Issues can be opened at https://github.com/GPSBabel/gpsbabel/issues.


> On 1/20/2026 4:51 PM, Robert Lipe wrote:
>> Preprocess with sed, awk, perl, python, spreadsheet, or whatever other 
>> army knife you're comfortable with... Or just go modify the xcsv 
>> parser to fit.
>>
>> You can just ignore fields at end of line if you're only reading.
>>
>> On Tue, Jan 20, 2026, 11:27 AM Mathias Koerber <ma...@ko...> 
>> wrote:
>>
>>     I am trying to convert some triplogs from the Android Torque Pro app
>>     to GPX
>>
>>     The format TorquePro exports is a CSV file:
>>     > GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h),
>>     Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity
>>     X(G), Gravity Y(G), Gravity Z(G),
>>     > Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021
>>     19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
>>     > Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021
>>     19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,
>>
>>     I am currently syumbling over how to parse the the time formats,
>>     esp the
>>        GMT+08:00
>>     part
>>
>>     My current style file looks line this:
>>     > # GPSBabel Style: Torque Pro triplog
>>     > # Author: Mathias Koerber
>>     > # Version: 0.01
>>     > # Date: 2026-01-21
>>     >
>>     > DESCRIPTION           Torque Pro triplog
>>     > EXTENSION             csv
>>     >
>>     > ENCODING              US-ASCII
>>     > FIELD_DELIMITER       COMMA
>>     > RECORD_DELIMITER      NEWLINE
>>     >
>>     >
>>     > PROLOGUE              GPS Time, Device Time, Longitude,
>>     Latitude,GPS Speed(km/h), Horizontal Dilution of Precision,
>>     Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
>>     >
>>     > IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>     > IGNORE                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>>     > IFIELD                LAT_DECIMAL,"","%f"
>>     > IFIELD                LON_DECIMAL,"","%f"
>>     > IFIELD                PATH_SPEED,"","%f"
>>     > IFIELD                GPS_HDOP,"","%f"
>>     > IFIELD                ALT_METERS,"","%.0f"
>>
>>     However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03
>>     GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.
>>
>>     So I gather the %z representing included in my system's strftime
>>     is not
>>     supported?
>>
>>     >      %z    is replaced by the time zone offset from UTC; a
>>     leading plus sign stands for east of UTC, a minus sign for
>>     >            west of UTC, hours and minutes follow with two digits
>>     each and no delimiter between them (common form for
>>     >            RFC 822 date headers).
>>
>>     which suggests it wants the RFC822 timezone format +HHmm but this is
>>     +HH:MM,. Python from 3.7 allows the colon for the %z conversion
>>     but that
>>     does not seem to apply here.
>>
>>     How can I parse that part of the time definition?
>>     Is there a way to ignore parts of a field?
>>
>>     or do I need to preprocess the files with python to reformat the
>>     timestamps?
>>
>>     Do I also have to IGNORE the final fields (Bearing, Gravity etc) I am
>>     not interested in?
>>     (I could not find any IFIELD definitions for those)
>>
>>
>>     I am using gpsbabel 1.10.0 on Mac (from homebrew)
>>
>>
>>     Any help appreciated
>>
>>
>>     _______________________________________________
>>     Gpsbabel-misc mailing list http://www.gpsbabel.org
>>     Gps...@li...
>>     To unsubscribe, change list options, or see archives, visit:
>>     https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>>
>>
>>
>> _______________________________________________
>> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
>> Gps...@li...
>> To unsubscribe, change list options, or see archives, visit:
>> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Re: [Gpsbabel-misc] TorquePro triplog format

[tsteven4 <tst...@gm...>]

We use a version of strptime from glib.  The current documentation is at 
https://sourceware.org/glibc/manual/latest/html_mono/libc.html#Interpret-string-according-to-given-format, 
although our version is a bit down level.  python strptime is not used 
by gpsbabel.

1) glibc strptime expects the time zone abbreviation to be terminated by 
a whitespace or at the end of a line.  This is problematic with your 
input as the numeric time zone directly follows the time zone 
abbreviation.  One way to work around this is to change your style file 
replacing %Z by GMT.

IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S GMT%z %Y"

2) There is a bug in glibc that fails to advance the parse point in the 
string for the abbreviated form of the weekday name for non-localized 
weekday names.  This causes an issue if the weekday name isn't the last 
field as in your case.  Normally the weekday name is checked against 
localized versions, but we don't use localization.  If your data is 
always from the same day of the week you should be able to replace %a by 
that literal, e.g.

IFIELD                LOCAL_TIME,"","Fri %b %d %H:%M:%S GMT%z %Y"

I have submitted a patch to glibc for the weekday name issue.  I don't 
know when and if they will act on it.

On 1/20/2026 4:51 PM, Robert Lipe wrote:
> Preprocess with sed, awk, perl, python, spreadsheet, or whatever other 
> army knife you're comfortable with... Or just go modify the xcsv 
> parser to fit.
>
> You can just ignore fields at end of line if you're only reading.
>
> On Tue, Jan 20, 2026, 11:27 AM Mathias Koerber <ma...@ko...> 
> wrote:
>
>     I am trying to convert some triplogs from the Android Torque Pro app
>     to GPX
>
>     The format TorquePro exports is a CSV file:
>     > GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h),
>     Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity
>     X(G), Gravity Y(G), Gravity Z(G),
>     > Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021
>     19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
>     > Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021
>     19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,
>
>     I am currently syumbling over how to parse the the time formats,
>     esp the
>        GMT+08:00
>     part
>
>     My current style file looks line this:
>     > # GPSBabel Style: Torque Pro triplog
>     > # Author: Mathias Koerber
>     > # Version: 0.01
>     > # Date: 2026-01-21
>     >
>     > DESCRIPTION           Torque Pro triplog
>     > EXTENSION             csv
>     >
>     > ENCODING              US-ASCII
>     > FIELD_DELIMITER       COMMA
>     > RECORD_DELIMITER      NEWLINE
>     >
>     >
>     > PROLOGUE              GPS Time, Device Time, Longitude,
>     Latitude,GPS Speed(km/h), Horizontal Dilution of Precision,
>     Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
>     >
>     > IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>     > IGNORE                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
>     > IFIELD                LAT_DECIMAL,"","%f"
>     > IFIELD                LON_DECIMAL,"","%f"
>     > IFIELD                PATH_SPEED,"","%f"
>     > IFIELD                GPS_HDOP,"","%f"
>     > IFIELD                ALT_METERS,"","%.0f"
>
>     However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03
>     GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.
>
>     So I gather the %z representing included in my system's strftime
>     is not
>     supported?
>
>     >      %z    is replaced by the time zone offset from UTC; a
>     leading plus sign stands for east of UTC, a minus sign for
>     >            west of UTC, hours and minutes follow with two digits
>     each and no delimiter between them (common form for
>     >            RFC 822 date headers).
>
>     which suggests it wants the RFC822 timezone format +HHmm but this is
>     +HH:MM,. Python from 3.7 allows the colon for the %z conversion
>     but that
>     does not seem to apply here.
>
>     How can I parse that part of the time definition?
>     Is there a way to ignore parts of a field?
>
>     or do I need to preprocess the files with python to reformat the
>     timestamps?
>
>     Do I also have to IGNORE the final fields (Bearing, Gravity etc) I am
>     not interested in?
>     (I could not find any IFIELD definitions for those)
>
>
>     I am using gpsbabel 1.10.0 on Mac (from homebrew)
>
>
>     Any help appreciated
>
>
>     _______________________________________________
>     Gpsbabel-misc mailing list http://www.gpsbabel.org
>     Gps...@li...
>     To unsubscribe, change list options, or see archives, visit:
>     https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

Re: [Gpsbabel-misc] RFEs?

[tsteven4 <tst...@gm...>]

1. The time tag in the header is annotated as "GPX file creation time" 
in the gpx 1.0 schema.  It is optional, however gpsbabel always includes 
it.  The gpx file produced by gpsbabel should validate against the gpx 
1.0 or 1.1 schema.  It sound like your downstream program is making 
assumptions that aren't required by the schema.  Issues can be opened at 
https://github.com/GPSBabel/gpsbabel/issues.

2. We have some regret over exposing strptime/strpftime to the user.  I 
also think your problem is deeper than %z and may have exposed a bug in 
the current release of glibc related to the name of the day of the week!

3. I am not aware of a repository of user submitted style files other 
than those in https://github.com/GPSBabel/gpsbabel/tree/master/style 
which are included automatically as formats in gpsbabel.

On 1/21/2026 8:09 AM, Mathias Koerber wrote:

> I found this old thread on the -misc mailimg list:
>
> Thread: [Gpsbabel-misc] Converting FIT to GPX introduces weird <time> 
> tag https://sourceforge.net/p/gpsbabel/mailman/message/37651605/
>
> and I am having the same issue.
>
> The recommendation there was to build one's own local copy of gpsbabel 
> with added functionality,
>
> but I wonder whether it would not be better to add an option (filter?) 
> that achieves this like:
>
>   - omit the time stamp
>
>   - use the first timestamp (chronologically) for the GPX file timestamp
>
>   - use a time specified on the command line for the GPX file time header
>
>
> Is the project accepting suggestions/RFE?
>
>
> Another one I'd have is to extend the strptime support to add
>
> %z (on both forms: +/-HHmm and +/-HH:MM)
>
> Which would need to be done OS independently, as eg the MAC strptime
>
> library function does not support %z natively?
>
>
> Finally, is there a repository of user-submitted style files somewhere
>
>
> Tha
>
> M
>
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gpsbabel-misc] RFEs?

[Mathias K. <ma...@ko...>]

I found this old thread on the -misc mailimg list:

Thread: [Gpsbabel-misc] Converting FIT to GPX introduces weird <time> 
tag https://sourceforge.net/p/gpsbabel/mailman/message/37651605/

and I am having the same issue.

The recommendation there was to build one's own local copy of gpsbabel 
with added functionality,

but I wonder whether it would not be better to add an option (filter?) 
that achieves this like:

   - omit the time stamp

   - use the first timestamp (chronologically) for the GPX file timestamp

   - use a time specified on the command line for the GPX file time header


Is the project accepting suggestions/RFE?


Another one I'd have is to extend the strptime support to add

%z (on both forms: +/-HHmm and +/-HH:MM)

Which would need to be done OS independently, as eg the MAC strptime

library function does not support %z natively?


Finally, is there a repository of user-submitted style files somewhere


Tha

M

Re: [Gpsbabel-misc] TorquePro triplog format

[Robert L. <rob...@gp...>]

Preprocess with sed, awk, perl, python, spreadsheet, or whatever other army
knife you're comfortable with... Or just go modify the xcsv parser to fit.

You can just ignore fields at end of line if you're only reading.

On Tue, Jan 20, 2026, 11:27 AM Mathias Koerber <ma...@ko...> wrote:

> I am trying to convert some triplogs from the Android Torque Pro app
> to GPX
>
> The format TorquePro exports is a CSV file:
> > GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h), Horizontal
> Dilution of Precision, Altitude(m), Bearing, Gravity X(G), Gravity Y(G),
> Gravity Z(G),
> > Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021
> 19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
> > Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021
> 19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,
>
> I am currently syumbling over how to parse the the time formats,
> esp the
>    GMT+08:00
> part
>
> My current style file looks line this:
> > # GPSBabel Style: Torque Pro triplog
> > # Author: Mathias Koerber
> > # Version: 0.01
> > # Date: 2026-01-21
> >
> > DESCRIPTION           Torque Pro triplog
> > EXTENSION             csv
> >
> > ENCODING              US-ASCII
> > FIELD_DELIMITER       COMMA
> > RECORD_DELIMITER      NEWLINE
> >
> >
> > PROLOGUE              GPS Time, Device Time, Longitude, Latitude,GPS
> Speed(km/h), Horizontal Dilution of Precision, Altitude(m), Bearing,
> Gravity X(G), Gravity Y(G), Gravity Z(G),
> >
> > IFIELD                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
> > IGNORE                LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
> > IFIELD                LAT_DECIMAL,"","%f"
> > IFIELD                LON_DECIMAL,"","%f"
> > IFIELD                PATH_SPEED,"","%f"
> > IFIELD                GPS_HDOP,"","%f"
> > IFIELD                ALT_METERS,"","%.0f"
>
> However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03
> GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.
>
> So I gather the %z representing included in my system's strftime is not
> supported?
>
> >      %z    is replaced by the time zone offset from UTC; a leading plus
> sign stands for east of UTC, a minus sign for
> >            west of UTC, hours and minutes follow with two digits each
> and no delimiter between them (common form for
> >            RFC 822 date headers).
>
> which suggests it wants the RFC822 timezone format +HHmm but this is
> +HH:MM,. Python from 3.7 allows the colon for the %z conversion but that
> does not seem to apply here.
>
> How can I parse that part of the time definition?
> Is there a way to ignore parts of a field?
>
> or do I need to preprocess the files with python to reformat the
> timestamps?
>
> Do I also have to IGNORE the final fields (Bearing, Gravity etc) I am
> not interested in?
> (I could not find any IFIELD definitions for those)
>
>
> I am using gpsbabel 1.10.0 on Mac (from homebrew)
>
>
> Any help appreciated
>
>
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>

[Gpsbabel-misc] TorquePro triplog format

[Mathias K. <ma...@ko...>]

I am trying to convert some triplogs from the Android Torque Pro app
to GPX

The format TorquePro exports is a CSV file:
> GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h), Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
> Fri Nov 19 19:52:39 GMT+08:00 2021,19-Nov-2021 19:52:39.102,103.74247846189135,1.3347234277319422,0.5935301,400.0,39.23157153287289,12.472237,-0.041589096,0.97694755,0.07076515,
> Fri Nov 19 19:52:40 GMT+08:00 2021,19-Nov-2021 19:52:40.102,103.74257139855422,1.334281496027564,0.2867428,400.0,-21.290203536857433,168.71567,-0.041589096,0.97694755,0.07076515,

I am currently syumbling over how to parse the the time formats,
esp the
   GMT+08:00
part

My current style file looks line this:
> # GPSBabel Style: Torque Pro triplog
> # Author: Mathias Koerber
> # Version: 0.01
> # Date: 2026-01-21
> 
> DESCRIPTION		Torque Pro triplog
> EXTENSION		csv
> 
> ENCODING		US-ASCII
> FIELD_DELIMITER	COMMA
> RECORD_DELIMITER	NEWLINE
> 
> 
> PROLOGUE		GPS Time, Device Time, Longitude, Latitude,GPS Speed(km/h), Horizontal Dilution of Precision, Altitude(m), Bearing, Gravity X(G), Gravity Y(G), Gravity Z(G),
> 
> IFIELD		LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
> IGNORE		LOCAL_TIME,"","%a %b %d %H:%M:%S %Z%z %Y"
> IFIELD		LAT_DECIMAL,"","%f"
> IFIELD		LON_DECIMAL,"","%f"
> IFIELD		PATH_SPEED,"","%f"
> IFIELD		GPS_HDOP,"","%f"
> IFIELD		ALT_METERS,"","%.0f"

However yields:> xcsv: date parse of string 'Fri Nov 19 20:05:03 
GMT+08:00 2021' with format '%a %b %d %H:%M:%S %Z%z %Y' failed.

So I gather the %z representing included in my system's strftime is not 
supported?

>      %z    is replaced by the time zone offset from UTC; a leading plus sign stands for east of UTC, a minus sign for
>            west of UTC, hours and minutes follow with two digits each and no delimiter between them (common form for
>            RFC 822 date headers).

which suggests it wants the RFC822 timezone format +HHmm but this is 
+HH:MM,. Python from 3.7 allows the colon for the %z conversion but that 
does not seem to apply here.

How can I parse that part of the time definition?
Is there a way to ignore parts of a field?

or do I need to preprocess the files with python to reformat the timestamps?

Do I also have to IGNORE the final fields (Bearing, Gravity etc) I am 
not interested in?
(I could not find any IFIELD definitions for those)


I am using gpsbabel 1.10.0 on Mac (from homebrew)


Any help appreciated

[Gpsbabel-misc] GDB-->CSV

[job l. <job...@gm...>]

Please shame on me. Forgive my stupidy. I mixed two different files 
thinking that I was watching a file with only W Longitudes but as a 
matter of fact  I had opened another file with a mix of W and E Longitudes.

jobloman

Re: [Gpsbabel-misc] GDB --> CSV

[tsteven4 <tst...@gm...>]

Assuming you mean "gpsbabel" where you say "Babelgps" the signs of 
latitude and longitude appear to be handled correctly:

> $ cat testsign.sh
> #!/bin/bash -e
>
> echo "lat,lon" > both.csv
> echo "-1,-1" >> both.csv
> echo "-1,1" >> both.csv
> echo "1,-1" >> both.csv
> echo "1,1" >> both.csv
>
> # as waypoints
> echo "as waypoints"
> gpsbabel -i unicsv -f both.csv -o gdb -F both.gdb
> gpsbabel -i gdb -f both.gdb
>
> # as a track
> echo "as a track"
> gpsbabel -t -i unicsv -f both.csv -o gdb -F both.gdb
> gpsbabel -t -i gdb -f both.gdb -x transform,wpt=trk,del
> (venv-py3132) tsteven4@PEDALDAMNIT:~$ ./testsign.sh
> as waypoints
> 1.000000S 1.000000W WPT001/WPT001
> 1.000000S 1.000000E WPT002/WPT002
> 1.000000N 1.000000W WPT003/WPT003
> 1.000000N 1.000000E WPT004/WPT004
> as a track
> 1.000000S 1.000000W WPT001/WPT001
> 1.000000S 1.000000E WPT002/WPT002
> 1.000000N 1.000000W WPT003/WPT003
> 1.000000N 1.000000E WPT004/WPT004

On 1/12/2026 5:16 AM, job loman wrote:
> Hi There,
>
> I have translated a Garmin GDB file into a CSV filer with the help of 
> Babelgps. When I look at the ranslated fike I can see that some 
> Longitude  are written -d.ddddd and some don't have the - sign though 
> in the original GDB file all Longitude are W. Is there anything I can 
> do to get the - sign before every Longitudes ?
>
> Best regards.
>
> jobloman
>
>
>
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gpsbabel-misc] GDB --> CSV

[job l. <job...@gm...>]

Hi There,

I have translated a Garmin GDB file into a CSV filer with the help of 
Babelgps. When I look at the ranslated fike I can see that some 
Longitude  are written -d.ddddd and some don't have the - sign though in 
the original GDB file all Longitude are W. Is there anything I can do to 
get the - sign before every Longitudes ?

Best regards.

jobloman

Re: [Gpsbabel-misc] Columbus CSV file conversion

[tsteven4 <tst...@gm...>]

Kevin,

I am testing a rewrite of the v900 format that will accommodate your file.

1) Do you give us permission to use your file in our regression tests?  
The file will be publicly available as part of our source repository.  I 
would like to verify that the sample you provided was as generated from 
your device, i.e. you didn't modify it.

2) Do you have other samples you would like to contribute?  We have some 
code that created waypoints from lines in the csv file with tags other 
than 'T'.  I don't know if you can cause these to be created on your 
device.  We have seen tags 'T', 'C', 'V' and 'G' but only have samples 
of 'T'.

3) Would you be willing to test an updated gpsbabel on your files?  If 
so I can tell you how to built test code from scratch or supply an 
installer with the test code.  If you want an installer I need to know 
if you are running windows, macos or linux.

Thanks,

Steve

On 10/31/2025 7:10 PM, Kevin Bartlett wrote:
> It's a Columbus "P-1 Mark II GNSS Logger" set to record in CSV format.
>
> On Fri, 31 Oct 2025 at 17:57, tsteven4 <tst...@gm...> wrote:
>
>     "The the V-900 stores logs on a microSD card in a custom csv
>     format. This format contains NULL characters and fixed length fields"
>
>     1. "The the" is a bug in our documentation.
>
>     2. The v900 reader expects fixed length fields and cr lf line
>     endings.  Your file does not have the expected lengths for each of
>     the fields.  The samples we have seen are padded with nulls.  Some
>     of your fields are shorter than expected and aren't padded, others
>     are longer than expected, and the last field is missing.
>
>     Here is rendering of our sample file for the basic format, with ^@
>     indicating a null character.
>
>>     INDEX,TAG,DATE,TIME,LATITUDE N/S,LONGITUDE
>>     E/W,HEIGHT,SPEED,HEADING,VOX
>>     68^@^@^@^@,T,090404,063510,31.765973N,035.206901E,827^@^@,12^@^@,357,^@^@^@^@^@^@^@^@^@
>>     <mailto:68%5E@%5E@%5E@%5E@,T,090404,063510,31.765973N,035.206901E,827%5E@%5E@,12%5E@%5E@,357,%5E@%5E@%5E@%5E@%5E@%5E@%5E@%5E@%5E@>
>     There is also an advance format with more fields.
>
>     What device created your columbus.CSV file?
>
>     On 10/31/2025 6:24 PM, Kevin Bartlett wrote:
>>     Hello,
>>
>>     The page
>>     https://www.gpsbabel.org/htmldoc-development/fmt_v900.html gives
>>     the syntax for converting a Columbus CSV file to .gpx format, but
>>     when I try it, I get an error message:
>>
>>     gpsbabel -i v900 -f columbus.CSV -o gpx -F columbus.gpx
>>        ==> v900: skipping malformed record at line 1
>>
>>     I've attached the CSV file. Is it possible this failure is
>>     because the CSV file was uploaded from a Columbus GPS onto a
>>     Windows computer, and I am running gpsbabel on a Mac? Something
>>     to do with carriage returns and linefeeds, perhaps?
>>
>>     Thanks,
>>     Kevin
>>
>>     -- 
>>     Kevin Bartlett | Marine Equipment Specialist
>>     Ocean Networks Canada | oceannetworks.ca <http://oceannetworks.ca/>
>>     University of Victoria Marine Technology Centre
>>     #206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
>>     *A UNIVERSITY OF VICTORIA INITIATIVE*
>>
>>
>>     _______________________________________________
>>     Gpsbabel-misc mailing listhttp://www.gpsbabel.org
>>     Gps...@li...
>>     To unsubscribe, change list options, or see archives, visit:
>>     https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>
>
>
> -- 
> Kevin Bartlett | Marine Equipment Specialist
> Ocean Networks Canada | oceannetworks.ca <http://oceannetworks.ca/>
> University of Victoria Marine Technology Centre
> #206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
> *A UNIVERSITY OF VICTORIA INITIATIVE*

[Gpsbabel-misc] Mailing list confusion resolved

[Kevin B. <kp...@oc...>]

Please disregard my previous message. A second "Welcome" email arrived
giving the correct email address to use for this mailing list, so I'm no
longer confused.

-- 
Kevin Bartlett | Marine Equipment Specialist
Ocean Networks Canada | oceannetworks.ca
University of Victoria Marine Technology Centre
#206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
*A UNIVERSITY OF VICTORIA INITIATIVE*

[Gpsbabel-misc] Mailing list confusion

[Kevin B. <kp...@oc...>]

I hope I'm sending this to the right address. The page at
https://www.gpsbabel.org/lists.html said to join this mailing list to ask
questions, but it didn't say what to do once you've joined. I got a
confirmation email, but it didn't include the address, either, and that
email came from a "noreply" address, so I couldn't just reply.

Eventually, I resorted to asking an AI for the email address, and this is
what it came up with.

So my first suggestion to gpsbabel is to make the instructions for sending
support requests clearer.

If I get through with this attempt, I'll follow up with my actual bug
report.

-- 
Kevin Bartlett | Marine Equipment Specialist
Ocean Networks Canada | oceannetworks.ca
University of Victoria Marine Technology Centre
#206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
*A UNIVERSITY OF VICTORIA INITIATIVE*

Re: [Gpsbabel-misc] Columbus CSV file conversion

[Kevin B. <kp...@oc...>]

It's a Columbus "P-1 Mark II GNSS Logger" set to record in CSV format.

On Fri, 31 Oct 2025 at 17:57, tsteven4 <tst...@gm...> wrote:

> "The the V-900 stores logs on a microSD card in a custom csv format. This
> format contains NULL characters and fixed length fields"
>
> 1. "The the" is a bug in our documentation.
>
> 2. The v900 reader expects fixed length fields and cr lf line endings.
> Your file does not have the expected lengths for each of the fields.  The
> samples we have seen are padded with nulls.  Some of your fields are
> shorter than expected and aren't padded, others are longer than expected,
> and the last field is missing.
>
> Here is rendering of our sample file for the basic format, with ^@
> indicating a null character.
>
> INDEX,TAG,DATE,TIME,LATITUDE N/S,LONGITUDE E/W,HEIGHT,SPEED,HEADING,VOX
>
> 68^@^@^@^@,T,090404,063510,31.765973N,035.206901E,827^@^@,12^@^@,357,^@^@^@^@^@^@^@^@^@
>
> There is also an advance format with more fields.
>
> What device created your columbus.CSV file?
> On 10/31/2025 6:24 PM, Kevin Bartlett wrote:
>
> Hello,
>
> The page https://www.gpsbabel.org/htmldoc-development/fmt_v900.html gives
> the syntax for converting a Columbus CSV file to .gpx format, but when I
> try it, I get an error message:
>
> gpsbabel -i v900 -f columbus.CSV -o gpx -F columbus.gpx
>    ==> v900: skipping malformed record at line 1
>
> I've attached the CSV file. Is it possible this failure is because the CSV
> file was uploaded from a Columbus GPS onto a Windows computer, and I am
> running gpsbabel on a Mac? Something to do with carriage returns and
> linefeeds, perhaps?
>
> Thanks,
> Kevin
>
> --
> Kevin Bartlett | Marine Equipment Specialist
> Ocean Networks Canada | oceannetworks.ca
> University of Victoria Marine Technology Centre
> #206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
> *A UNIVERSITY OF VICTORIA INITIATIVE*
>
>
> _______________________________________________
> Gpsbabel-misc mailing list http://www.gp...@li...
> To unsubscribe, change list options, or see archives, visit:https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
>
>

-- 
Kevin Bartlett | Marine Equipment Specialist
Ocean Networks Canada | oceannetworks.ca
University of Victoria Marine Technology Centre
#206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
*A UNIVERSITY OF VICTORIA INITIATIVE*

Re: [Gpsbabel-misc] Columbus CSV file conversion

[tsteven4 <tst...@gm...>]

"The the V-900 stores logs on a microSD card in a custom csv format. 
This format contains NULL characters and fixed length fields"

1. "The the" is a bug in our documentation.

2. The v900 reader expects fixed length fields and cr lf line endings.  
Your file does not have the expected lengths for each of the fields.  
The samples we have seen are padded with nulls.  Some of your fields are 
shorter than expected and aren't padded, others are longer than 
expected, and the last field is missing.

Here is rendering of our sample file for the basic format, with ^@ 
indicating a null character.

> INDEX,TAG,DATE,TIME,LATITUDE N/S,LONGITUDE E/W,HEIGHT,SPEED,HEADING,VOX
> 68^@^@^@^@,T,090404,063510,31.765973N,035.206901E,827^@^@,12^@^@,357,^@^@^@^@^@^@^@^@^@
There is also an advance format with more fields.

What device created your columbus.CSV file?

On 10/31/2025 6:24 PM, Kevin Bartlett wrote:
> Hello,
>
> The page https://www.gpsbabel.org/htmldoc-development/fmt_v900.html 
> gives the syntax for converting a Columbus CSV file to .gpx format, 
> but when I try it, I get an error message:
>
> gpsbabel -i v900 -f columbus.CSV -o gpx -F columbus.gpx
>    ==> v900: skipping malformed record at line 1
>
> I've attached the CSV file. Is it possible this failure is because the 
> CSV file was uploaded from a Columbus GPS onto a Windows computer, and 
> I am running gpsbabel on a Mac? Something to do with carriage returns 
> and linefeeds, perhaps?
>
> Thanks,
> Kevin
>
> -- 
> Kevin Bartlett | Marine Equipment Specialist
> Ocean Networks Canada | oceannetworks.ca <http://oceannetworks.ca/>
> University of Victoria Marine Technology Centre
> #206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
> *A UNIVERSITY OF VICTORIA INITIATIVE*
>
>
> _______________________________________________
> Gpsbabel-misc mailing listhttp://www.gpsbabel.org
> Gps...@li...
> To unsubscribe, change list options, or see archives, visit:
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc

[Gpsbabel-misc] Columbus CSV file conversion

[Kevin B. <kp...@oc...>]

Hello,

The page https://www.gpsbabel.org/htmldoc-development/fmt_v900.html gives
the syntax for converting a Columbus CSV file to .gpx format, but when I
try it, I get an error message:

gpsbabel -i v900 -f columbus.CSV -o gpx -F columbus.gpx
   ==> v900: skipping malformed record at line 1

I've attached the CSV file. Is it possible this failure is because the CSV
file was uploaded from a Columbus GPS onto a Windows computer, and I am
running gpsbabel on a Mac? Something to do with carriage returns and
linefeeds, perhaps?

Thanks,
Kevin

-- 
Kevin Bartlett | Marine Equipment Specialist
Ocean Networks Canada | oceannetworks.ca
University of Victoria Marine Technology Centre
#206-9865 West Saanich Road, North Saanich, BC V8L 5Y8
*A UNIVERSITY OF VICTORIA INITIATIVE*