[gpsbabel-Feature Requests-1220573 ] Vito Navigator II track file (.smt)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[gpsbabel-Feature Requests-1220573 ] Vito Navigator II track file (.smt)

Etasse
I have produced a vitosmt_contrib.zip file which now includes all diffs
encountered plus added files.

 - As noted, I replaced strcasecmp() with case_ignore_strcmp() in
vecs*.c to prevent MSVC compile error
 - Found a style_vec pointer declared but not used in vecs.c
disp_formats(), left it alone

The new files, diffs and test data can be consulted in the RFE #
1220573 :

http://sourceforge.net/tracker/index.php?func=detail&aid=1220573&group_id=58972&atid=489478




       

       
               
__________________________________________________________
Lèche-vitrine ou lèche-écran ?
magasinage.yahoo.ca


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: [gpsbabel-Feature Requests-1220573 ] Vito Navigator II track file (.smt)

Robert Lipe
Etasse wrote:
> I have produced a vitosmt_contrib.zip file which now includes all diffs
> encountered plus added files.

Thanx.  This seems about right.  I've applied this with only minor
tweaking.  Whatever you used to produce the patch chewed things up, so I
did have to edit those on the way in.

Your test suite entry does fail, though.  It looks like there's a timezone
problem on most of the entries.  Remember, the person running the suite is
probably in a different TZ than you are, so you may need to tweak your
computer's concept of TZ to expose this.

8c8
< <time>1970-01-01T00:00:00Z</time>
---
> <time>2005-06-15T02:39:36Z</time>
12c12
< <time>2004-10-30T18:36:00Z</time>
---
> <time>2004-10-30T17:36:00Z</time>
19c19
< <time>2004-10-30T18:36:00Z</time>
---
> <time>2004-10-30T17:36:00Z</time>
26c26
< <time>2004-10-30T18:36:00Z</time>
---
> <time>2004-10-30T17:36:00Z</time>
33c33
< <time>2004-10-30T18:37:00Z</time>
---
> <time>2004-10-30T17:37:00Z</time>
40c40
< <time>2004-10-30T18:37:00Z</time>
---

Please do update to the CVS top-of-tree and submit a new patch that
corrects this.

Thanx,

RJL


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Vito Navigator II track file (.smt) - revisions

Etasse
--- Robert Lipe  wrote :
> Your test suite entry does fail, though.  It looks like there's
> a timezone problem on most of the entries.  Remember, the person
> running the suite is probably in a different TZ than you are, so
> you may need to tweak your computer's concept of TZ to expose this.

The time stored in the SMT file is the local time from the Pocket PC.
I think the timestamp in the GPX is converted to UTC correctly.  

Should I do a SET TZ to force gpsbabel to run in a specific timezone
(i.e. EST5EDT) in testo?

Any idea how to resolve the TZ problem?

Also here's a diff of changes to vitosmt.c  It can now produce either
waypoints or tracks if -t is specified.

*** CVS.rev.1.1-vitosmt.c Mon Jun 20 10:58:35 2005
--- vitosmt.c Wed Jun 15 11:31:58 2005
*************** vitosmt_read(void)
*** 83,92 ****
  unsigned short version =0;
  unsigned long count =0;
  const unsigned long recsize =64;
! unsigned short stringlen =0;
! static int serial =0;
!
! /* route_head *track_head =0; */
  waypoint *wpt_tmp =0;
  double latrad =0;
  double lonrad =0;
--- 83,90 ----
  unsigned short version =0;
  unsigned long count =0;
  const unsigned long recsize =64;
! unsigned short stringlen =0;
! route_head *track_head =0;
  waypoint *wpt_tmp =0;
  double latrad =0;
  double lonrad =0;
*************** vitosmt_read(void)
*** 104,113 ****
  ReadLong(infile); /* 599 */
  ReadLong(infile); /* 600 */
 
- /* track_head = route_head_alloc(); */
- /* route_add_head(track_head); */
-
-
  while (count) {
  /*
  * 64 bytes of data
--- 102,107 ----
*************** vitosmt_read(void)
*** 115,122 ****
  latrad =ReadDouble(infile); /* WGS84 latitude in radians */
  lonrad =ReadDouble(infile); /* WGS84 longitude in radians */
  elev =ReadDouble(infile); /* elevation in meters */
! timestamp =ReadRecord(infile,8); /* local time */
! Skip(infile,32); /* remainder, unknown fmt */
 
  wpt_tmp = waypt_new();
 
--- 109,116 ----
  latrad =ReadDouble(infile); /* WGS84 latitude in radians */
  lonrad =ReadDouble(infile); /* WGS84 longitude in radians */
  elev =ReadDouble(infile); /* elevation in meters */
! timestamp =ReadRecord(infile,5); /* local time */
! Skip(infile,35); /* remainder, unknown fmt */
 
  wpt_tmp = waypt_new();
 
*************** vitosmt_read(void)
*** 129,147 ****
  tmStruct.tm_mday =timestamp[2];
  tmStruct.tm_hour =timestamp[3];
  tmStruct.tm_min =timestamp[4];
! tmStruct.tm_sec =timestamp[5];
  tmStruct.tm_isdst =-1;
 
! wpt_tmp->creation_time = mktime(&tmStruct); /* + get_tz_offset();
*/
!
! wpt_tmp->shortname = (char *) xmalloc(10);
! snprintf(wpt_tmp->shortname, 10, "SMT%04d",++serial);
  wpt_tmp->wpt_flags.shortname_is_synthetic = 1;
 
! waypt_add(wpt_tmp);
 
! xfree(timestamp);
 
 
  count--;
  }
--- 123,155 ----
  tmStruct.tm_mday =timestamp[2];
  tmStruct.tm_hour =timestamp[3];
  tmStruct.tm_min =timestamp[4];
! tmStruct.tm_sec =0;
  tmStruct.tm_isdst =-1;
 
! wpt_tmp->creation_time = mktime(&tmStruct);
  wpt_tmp->wpt_flags.shortname_is_synthetic = 1;
+
 
! switch (global_opts.objective)
! {
! case wptdata:
! waypt_add(wpt_tmp);
! break;
! case trkdata:
! if (track_head == NULL) {
! track_head = route_head_alloc();
! track_add_head(track_head);
! }
! route_add_wpt(track_head, wpt_tmp);
! break;
! default:
! fatal(MYNAME ": This file type only supports "
! "waypoint or track (-w or -t) mode.");
 
! break;
! }
 
+ xfree(timestamp);
 
  count--;
  }

*** CVS.rev.1.96-README Mon Jun 20 10:58:16 2005
--- C:\SOURCEFORGE\gpsbabel\README Mon Jun 20 22:30:08 2005
*************** THE FORMATS
*** 842,849 ****
      VitoSMT
 
  Vito Navigator II is a Pocket PC GPS application.  This format reads
! a Vito Navigator II .SMT track file in waypoint mode.  It is still
! a work in progress.
 
 
  DATA FILTERS
--- 842,849 ----
      VitoSMT
 
  Vito Navigator II is a Pocket PC GPS application.  This format reads
! a Vito Navigator II .SMT track file and can work in either waypoint
! or track mode.  It is still a work in progress.
 
 
  DATA FILTERS


Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre Yahoo! Mail sur http://mail.yahoo.fr


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: Vito Navigator II track file (.smt) - revisions

Robert Lipe
> The time stored in the SMT file is the local time from the Pocket PC.

It's still amazing to me how many file formats do such silly things...

> Should I do a SET TZ to force gpsbabel to run in a specific timezone
> (i.e. EST5EDT) in testo?

What if we instead use another environmental variable
(GPSBABEL_TZ_LOCAL) that can be set by testo that makes get_tz_offset
just always return that constant?   That way we don't encode UNIX-style
timezone info.

(No, I'm not saying that's not gross.)

> ! switch (global_opts.objective)
> ! {
> ! case wptdata:
> ! waypt_add(wpt_tmp);
> ! break;
> ! case trkdata:
> ! if (track_head == NULL) {
> ! track_head = route_head_alloc();
> ! track_add_head(track_head);
> ! }
> ! route_add_wpt(track_head, wpt_tmp);

Can any one file in this format contain both waypoints and tracks?

If so, let's try to eliminate the switch (meaning only one can be done
at time) and do everything we can for any recognized formats.    Users
like this since they don't have to specify -t/-r/-w and they can deal
with "mixed mode" files that contain both tracks _and_ wpts.

Of course, this may not apply to this format...

--
Support GPSBabel by helping to improve it or fund those that that have
done so.  Visit:

        http://sourceforge.net/donate/index.php?group_id=58972


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code