gpsbabel-code — Discussions about development of gpsbabel

[Gpsbabel-code] Magellan NAV Companion for PalmOS support

[Ron P. <pa...@fw...>]

Robert (and other interested parties),

I have just finished cleaning up the support for Magellan NAV Companion 
for PalmOS.  I'm sure it's not up to snuff with the coding standards 
for this project, but I hope it's reasonably close.  In any case, you 
can find the changed source files as well as a set of diffs against the 
current CVS in http://216.202.195.127/magnav.zip .

The output from this module has been tested with the current version of
NAV Companion.

I'm planning to fix the GPSPilot output support next, but I'll wait 
for feedback on any problems you might have with this code before I 
do that.

[Gpsbabel-code] topousa4 support

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

A discussion revealed that we can almost  process Delorme Topo USA 4 files.

http://opentopic.groundspeak.com/0/OpenTopic?a=tpc&s=1750973553&f=5740990093&m=2950934435

If anyone with TUSA4 can confirm this works, I'll commit it.

(Yes, this CSV code should be refactored...It's on my list.)

RJL

Index: README
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/README,v
retrieving revision 1.13
diff -p -u -r1.13 README
--- README	1 Oct 2002 21:39:42 -0000	1.13
+++ README	4 Oct 2002 20:40:00 -0000
@@ -87,6 +87,12 @@ THE FORMATS
 	There are a billion variants of Comma Separated Value data.  This
 	is the one that makes Delorme S&A Deluxe 9 happy.
 
+    Delorme Topo USA 4
+
+	This is one of the billion CSV variants mentioned above.  It's just
+	like S&A with the addition of a completely pointless line at the
+	beginning and end of the file.
+
     MAPSEND
 
 	Magellan was smart enough to document their file format to make
Index: csv.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/csv.c,v
retrieving revision 1.7
diff -p -u -r1.7 csv.c
--- csv.c	20 Sep 2002 17:47:45 -0000	1.7
+++ csv.c	4 Oct 2002 20:40:00 -0000
@@ -54,12 +54,27 @@ wr_init(const char *fname)
 }
 
 static void
+tusa4_wr_init(const char *fname)
+{
+	wr_init(fname);
+	fprintf(file_out, "BEGIN SYMBOL\n");
+}
+
+
+static void
 wr_deinit(void)
 {
 	fclose(file_out);
 }
 
 static void
+tusa4_wr_deinit(void)
+{
+	fprintf(file_out, "END\n");
+	wr_deinit();
+}
+
+static void
 data_read(void)
 {
 	char buff[1024];
@@ -107,9 +122,10 @@ data_read(void)
 		wpt_tmp->creation_time = time(NULL);
 		
 		/* We'll make up our own shortname. */
-		wpt_tmp->shortname = mkshort(wpt_tmp->description);
-		
-		waypt_add(wpt_tmp);
+		if (wpt_tmp->description) {
+			wpt_tmp->shortname = mkshort(wpt_tmp->description);
+			waypt_add(wpt_tmp);
+		}
 
 	} else {
 		/* empty line */
@@ -151,6 +167,15 @@ ff_vecs_t csv_vecs = {
 	wr_init,
 	rd_deinit,
 	wr_deinit,
+	data_read,
+	data_write,
+};
+
+ff_vecs_t tusa4_vecs = {
+	rd_init,
+	tusa4_wr_init,
+	rd_deinit,
+	tusa4_wr_deinit,
 	data_read,
 	data_write,
 };
Index: testo
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/testo,v
retrieving revision 1.12
diff -p -u -r1.12 testo
--- testo	1 Oct 2002 21:39:42 -0000	1.12
+++ testo	4 Oct 2002 20:40:00 -0000
@@ -96,3 +96,10 @@ diff ${TMPDIR}/ozi.ozi reference
 # identical reference.
 ${PNAME} -i holux -f reference/paris.wpo -o holux -F ${TMPDIR}/paris.wpo
 diff reference/paris.wpo ${TMPDIR}/paris.wpo
+
+rm -f ${TMPDIR}/tusa4-1.gpx ${TMPDIR}/tusa4-2.gpx ${TMPDIR}/tusa4 
+${PNAME} -i tusa4 -f reference/tusa4 -o tusa4 -F ${TMPDIR}/tusa4
+${PNAME} -i tusa4 -f reference/tusa4 -o gpx -F ${TMPDIR}/tusa4-1.gpx
+${PNAME} -i tusa4 -f ${TMPDIR}/tusa4 -o gpx -F ${TMPDIR}/tusa4-2.gpx
+diff ${TMPDIR}/tusa4-1.gpx ${TMPDIR}/tusa4-2.gpx
+diff reference/tusa4 ${TMPDIR}/tusa4
Index: vecs.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/vecs.c,v
retrieving revision 1.9
diff -p -u -r1.9 vecs.c
--- vecs.c	1 Oct 2002 21:39:42 -0000	1.9
+++ vecs.c	4 Oct 2002 20:40:00 -0000
@@ -46,6 +46,7 @@ extern ff_vecs_t mxf_vecs;
 extern ff_vecs_t holux_vecs;
 extern ff_vecs_t ozi_vecs;
 extern ff_vecs_t dna_vecs;
+extern ff_vecs_t tusa4_vecs;
 
 static
 vecs_t vec_list[] = {
@@ -98,6 +99,11 @@ vecs_t vec_list[] = {
 		&csv_vecs,
 		"csv",
 		"Comma separated values"
+	},
+	{
+		&tusa4_vecs,
+		"tusa4",
+		"Delorme Topo USA4"
 	},
 	{
 		&dna_vecs,

[Gpsbabel-code] adding routes to gpsbabel

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

I've had two folks recently ask me about routes in gpsbabel.  From my
view, routes are just an ordered list of waypointed and tracks are just
a BIG ordered list of waypoints.  Last night I sketched out how routes
might be represented.  I tossed in a skeleton route reader for magellan
protocol.  A track reader would be easier in some ways.

I'm proposing a pair of new command line arguments
	-R    	work with routes
	-T 	work with tracks
Thus, the command to read the tracks stored in my magellan is:
	gpsbabel -R -i magellan -f /dev/ttyS0
(If I'd implemented any output formats, they'd follow, of course.)

Internally, we gain a few data structures.  We get a route head that
describes the route itself.  It contains a linked list of waypoints that
can be trawled when we need them and other fields that look like they
can be used to satisfy both GPX and Mapsend when the time comes We get a
pair of vectors for reading and writing these.  Maybe we need separate
open/close points, but I doubt it.

The questions for the crowd are:
  A) Could your favorite file formats be implemented in this framework?
  B) Based on what you know about tracks and routes, have I missed anything?

Nothing is immutable and I haven't committed this.  I want to toss it
out for discussion before I do.  I don't want to get hung up in nits
about the print formats or constness; I just want to see if we have
the right structures and handlers in place.  

Of course, if there is no discussion, I'll do it anyway. :-)

RJL


Index: defs.h
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/defs.h,v
retrieving revision 1.10
diff -p -u -r1.10 defs.h
--- defs.h	23 Sep 2002 19:51:17 -0000	1.10
+++ defs.h	4 Oct 2002 19:03:46 -0000
@@ -82,6 +82,14 @@ typedef struct {
 	time_t creation_time;
 } waypoint;
 
+typedef struct {
+	queue Q;		/* Link onto parent list. */
+	queue waypoint_list;	/* List of child waypoints */
+	char *rte_name;
+	char *rte_desc;
+	int rte_num;
+} route_head;
+
 typedef void (*ff_init) (char const *);
 typedef void (*ff_deinit) (void);
 typedef void (*ff_read) (void);
@@ -91,13 +99,21 @@ typedef void (*waypt_cb) (const waypoint
 void waypt_add (waypoint *);
 void route_add (waypoint *);
 void waypt_disp_all(waypt_cb);
+void route_disp (route_head *);
 unsigned int waypt_count(void);
 void fprintdms(FILE *, const coord *, int);
+route_head *route_head_alloc(void);
+
 char *mkshort (const char *);
 void setshort_length(int n);
 void setshort_badchars(const char *);
 void setshort_mustupper(int n);
 
+typedef struct rte_vecs {
+	ff_read rte_read;
+	ff_write rte_write;
+} rte_vecs_t;
+
 typedef struct ff_vecs {
 	ff_init rd_init;
 	ff_init wr_init;
@@ -105,6 +121,7 @@ typedef struct ff_vecs {
 	ff_deinit wr_deinit;
 	ff_read read;
 	ff_write write;
+	rte_vecs_t *trk_vecs;
 } ff_vecs_t;
 
 void waypt_init(void);
Index: gpx.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/gpx.c,v
retrieving revision 1.9
diff -p -u -r1.9 gpx.c
--- gpx.c	1 Oct 2002 18:37:27 -0000	1.9
+++ gpx.c	4 Oct 2002 19:03:46 -0000
@@ -106,7 +106,7 @@ gpx_end(void *data, const char *el)
 		in_wpt--;
 	}
 	else if (strcmp(el, "rtept") == 0) {
-		route_add(wpt_tmp);
+/*		route_add_wpt(wpt_tmp); */
 		in_rte--;
 	} else if (strcmp(el, "name") == 0) {
 		in_name--;
Index: magproto.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/magproto.c,v
retrieving revision 1.20
diff -p -u -r1.20 magproto.c
--- magproto.c	1 Oct 2002 18:27:01 -0000	1.20
+++ magproto.c	4 Oct 2002 19:03:47 -0000
@@ -46,6 +46,24 @@ typedef enum {
 } mag_rxstate;
 
 
+/*
+ *   An individual element of a route.
+ */
+typedef struct mag_rte_elem {
+	queue Q;	 		/* My link pointers */
+	char *wpt_name;
+	char *wpt_icon;
+} mag_rte_elem;
+
+/*
+ *  A header of a route.  Related elements of a route belong to this.
+ */
+typedef struct mag_rte_head {
+	queue Q;			/* Queue head for child rte_elems */
+	int nelems;
+} mag_rte_head;
+
+
 static FILE *magfile_in;
 static FILE *magfile_out;
 static int magfd;
@@ -59,6 +77,7 @@ static int is_file = 0;
 
 
 static waypoint * mag_wptparse(char *);
+static waypoint * mag_rteparse(char *);
 typedef char * (cleanse_fn) (char *);
 static cleanse_fn *mag_cleanse;
 
@@ -360,6 +379,10 @@ if (debug_serial)
 		waypoint *wpt = mag_wptparse(ibuf);
 		waypt_add(wpt);
 	} 
+	if (strncmp(ibuf, "$PMGNRTE,", 7) == 0) {
+		/* Something = */ 
+		mag_rteparse(ibuf);
+	} 
 	if (IS_TKN("$PMGNVER,")) {
 		mag_verparse(ibuf);
 		return;
@@ -656,6 +679,92 @@ mag_trkparse(char *trkmsg)
 }
 #endif
 
+/*
+ * Given an incoming route messages of the form:
+ * $PMGNRTE,4,1,c,1,DAD,a,Anna,a*61
+ * generate a track.
+ */
+waypoint * 
+mag_rteparse(char *rtemsg)
+{
+	char descr[100];
+	int n;
+	int frags,frag,rtenum;
+	char xbuf[100],next_stop[100],abuf[100];
+	char *currtemsg;
+	static mag_rte_head *mag_rte_head;
+	mag_rte_elem *rte_elem;
+
+	descr[0] = 0;
+
+	sscanf(rtemsg,"$PMGNRTE,%d,%d,%c,%d%n", 
+		&frags,&frag,xbuf,&rtenum,&n);
+
+	/*
+	 * This is the first component of a route.  Allocate a new
+	 * queue head.   It's kind of unfortunate that we can't know
+	 * a priori how many items are on this track, so we have to
+	 * alloc and chain those as we go.
+	 */
+	if (frag == 1) {
+		mag_rte_head = xmalloc(sizeof (*mag_rte_head));
+		QUEUE_INIT(&mag_rte_head->Q);
+		mag_rte_head->nelems = frags;
+	}
+
+	currtemsg = rtemsg + n;
+
+	/*
+	 * The individual line may contain several route elements.
+	 * loop and pick those up.
+	 */
+	while (sscanf(currtemsg,",%[^,],%[^,]%n",next_stop, abuf,&n)) {
+		if (next_stop[0] == 0) {
+			break;
+		}
+		rte_elem = xmalloc(sizeof (*rte_elem));
+		QUEUE_INIT(&rte_elem->Q);
+		rte_elem->wpt_name = xstrdup(next_stop);
+		rte_elem->wpt_icon = xstrdup(abuf);
+		ENQUEUE_TAIL(&mag_rte_head->Q, &rte_elem->Q);
+		next_stop[0] = 0;
+		currtemsg += n;
+	}
+
+	/*
+	 * If this was the last fragment of the route, add it to the
+	 * gpsbabel internal structs now.
+	 */
+	if (frag == mag_rte_head->nelems) {
+		queue *elem, *tmp;
+		route_head *rte_head;
+
+		rte_head = route_head_alloc();
+		route_add_head(rte_head);
+
+		/*
+		 *  TODO: I suppose we have to fetch the waypoints to
+		 *  get the underlying data for each stop in the route.
+		 */
+		QUEUE_FOR_EACH(&mag_rte_head->Q, elem, tmp) {
+			static int lat; /* Dummy data */
+			mag_rte_elem *re = (mag_rte_elem *) elem;
+			waypoint *waypt;
+
+			waypt  = xcalloc(sizeof *waypt, 1);
+
+			/* TODO Populate rest of waypoint. */
+			waypt->shortname = re->wpt_name;
+			waypt->position.latitude.degrees = ++lat;
+
+			route_add_wpt(rte_head, waypt);
+			dequeue(&re->Q);
+			free(re);
+		}
+	}
+	return 0;
+}
+
 const char *
 mag_find_descr_from_token(const char *token)
 {
@@ -771,6 +880,28 @@ mag_readwpt(void)
 	}
 }
 
+static void
+mag_rd_trk(void)
+{
+#if 0
+	mag_readwpt();
+#endif
+
+	if (!is_file) {
+		mag_writemsg("PMGNCMD,ROUTE");
+	}
+
+	while (!found_done) {
+		mag_readmsg();
+	}
+}
+
+static void
+mag_wr_trk(void)
+{
+	fatal("Track writing not supported yet.\n");
+}
+
 static
 void
 mag_waypt_pr(const waypoint *waypointp)
@@ -842,6 +973,11 @@ mag_write(void)
 	waypt_disp_all(mag_waypt_pr);
 }
 
+rte_vecs_t mag_rte_vecs = {
+	mag_rd_trk,
+	mag_wr_trk,
+};
+
 ff_vecs_t mag_vecs = {
 	mag_rd_init,	
 	mag_wr_init,	
@@ -849,4 +985,5 @@ ff_vecs_t mag_vecs = {
 	mag_deinit,	
 	mag_readwpt,
 	mag_write,
+	&mag_rte_vecs
 };
Index: main.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/main.c,v
retrieving revision 1.7
diff -p -u -r1.7 main.c
--- main.c	17 Sep 2002 23:13:02 -0000	1.7
+++ main.c	4 Oct 2002 19:03:47 -0000
@@ -41,6 +41,7 @@ main(int argc, char *argv[])
 	ff_vecs_t *ovecs = NULL;
 	char *fname = NULL;
 	char *ofname = NULL;
+	int do_route = 0;
 
 	waypt_init();
 	route_init();
@@ -79,7 +80,11 @@ main(int argc, char *argv[])
 					fatal ("No valid input type specified");
 				}
 				ivecs->rd_init(fname);
-				ivecs->read();
+				if (do_route)
+					ivecs->trk_vecs->rte_read();
+				else {
+					ivecs->read();
+				}
 				ivecs->rd_deinit();
 				break;
 			case 'F':
@@ -98,6 +103,9 @@ main(int argc, char *argv[])
 				global_opts.debug_level = atoi(optarg);
 				argn++;
 				break;
+			case 'R':
+				do_route = 1;
+				break;
 			case 'h':
 			case '?':
 				usage(argv[0]);
@@ -105,8 +113,13 @@ main(int argc, char *argv[])
 		}
 	}
 
-	if (ovecs == NULL)
-		waypt_disp_all(waypt_disp);
+	if (ovecs == NULL) {
+		if (do_route) {
+			route_disp_all();
+		} else {
+			waypt_disp_all(waypt_disp);
+		}
+	}
 
 	exit(0);
 }
Index: route.c
===================================================================
RCS file: /cvsroot/gpsbabel/gpsbabel/route.c,v
retrieving revision 1.1.1.1
diff -p -u -r1.1.1.1 route.c
--- route.c	31 Jul 2002 22:55:08 -0000	1.1.1.1
+++ route.c	4 Oct 2002 19:03:47 -0000
@@ -20,28 +20,57 @@
 #include <stdio.h>
 #include "defs.h"
 
-static queue route_head;
+static queue my_route_head;
 
 void
 route_init(void)
 {
-	QUEUE_INIT(&route_head);
+	QUEUE_INIT(&my_route_head);
 }
 
+
+route_head *
+route_head_alloc(void)
+{
+	route_head *rte_head;
+	rte_head = xmalloc(sizeof (*rte_head));
+	QUEUE_INIT(&rte_head->Q);
+
+}
+
+
 void
-route_add(waypoint *wpt)
+route_add_head(route_head *rte)
 {
-	ENQUEUE_TAIL(&route_head, &wpt->Q);
+	ENQUEUE_TAIL(&my_route_head, &rte->Q);
+	QUEUE_INIT(&rte->waypoint_list);
 }
 
 void
-route_disp_all(waypt_cb cb)
+route_add_wpt(route_head *rte, waypoint *wpt)
 {
-	queue *elem, *tmp;
-	waypoint *waypointp;
+	ENQUEUE_TAIL(&rte->waypoint_list, &wpt->Q);
+}
 
-	QUEUE_FOR_EACH(&route_head, elem, tmp) {
+void
+route_disp (route_head *rh)
+{
+	queue *elem, *tmp;
+	printf("NEW ROUTE\n");
+	QUEUE_FOR_EACH(&rh->waypoint_list, elem, tmp) {
+		waypoint *waypointp;
 		waypointp = (waypoint *) elem;
-		(*cb)(waypointp);
+			waypt_disp(waypointp);
+	}
+		
+}	
+void 
+route_disp_all()
+{
+	queue *elem, *tmp;
+	QUEUE_FOR_EACH(&my_route_head, elem, tmp) {
+		route_head *rh;
+		rh = (route_head *) elem;
+		route_disp(rh);
 	}
 }

Re: [Gpsbabel-code] Expat.h

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

> I tried to build on OSX and ran into the following build error. I need to
> install some package first, but not sure where expat resides or does.

Apparently expst is less common than I thought.  Since it's part of
apache, I guess I considered it pretty ubiquitous.  I make a brief
mention of it in README.contrib and on the web page.

Where can we document this so people would notice it?

RJL

[Gpsbabel-code] Never mind on expat.h

[Casey K. <cas...@am...>]

Found the expat project, built it, installed it, and rebuilt gpsbabel.
Looking forward to trying it tonight assuming I have the correct cable ;).

casey

[Gpsbabel-code] Expat.h

[Casey K. <cas...@am...>]

Wan't to download some waypoints into my etrex and ran across this project.
I tried to build on OSX and ran into the following build error. I need to
install some package first, but not sure where expat resides or does.

Thanks.

casey

[pb1k71:~/Desktop/gpsbabel] casey% make
cc -g   -c -o main.o main.c
cc -g   -c -o queue.o queue.c
cc -g   -c -o route.o route.c
cc -g   -c -o waypt.o waypt.c
cc -g   -c -o util.o util.c
cc -g   -c -o vecs.o vecs.c
cc -g   -c -o magproto.o magproto.c
cc -g   -c -o gpx.o gpx.c
gpx.c:22: header file 'expat.h' not found
gpx.c:32: undefined type, found `XML_Parser'
gpx.c:124: undefined type, found `XML_Char'
cpp-precomp: warning: errors during smart preprocessing, retrying in basic
mode
make: *** [gpx.o] Error 1

Re: [Gpsbabel-code] Removing Duplicate Waypoints... how to / where to?

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

Alex Mottram wrote:

> My problem:  I've got multiple input files, some with the same
> waypoints with the same name/same coordinates, some with a different
> name/same coordinates, and probably some that I haven't seen that need
> to be dealt with (different name / points within a few feet).

I've had to deal with this a few times.  I'll confess that I'd been
handling it by exporting to gpsutil becuase a format that's easy to
machine-process with standard UNIX-y tools (diff, sort, uniq, awk. etc.)
doing the processing there, and sucking them back into gpsbabel to the
format I need.

> depending on the options.  Toss in the need / want to synthesize
> shortnames on output, dequeue by name, matching position, or both, and
> you've got a potential mess.  Which came first, the chicken or the

I've given this very problem some thought over recent weeks. I'm
thinking that it'd be OK for gpsbabel to have a global "coalesce" flag
on the command line.  If you want to read three files and merge them
into this output format but not into that output format, you just plain
need to run gpsbabel twice.

An easy way to detect duplicates it to test for numeric equality of the
three coords of the waypoints.  I think that making waypt_add weed these
out would be a very reasonable thing to do.  I've been thinking that a
hash table, keying off the last couple digits of the coords would be
a reasonable way to avoid quadratic performance when slogging through
thousands of waypoints.

I hadn't thought about numeric proximity instead of equality.  That's a
slightly harder problem.

A still related problem is that some formats don't allow duplicate
shortnames and worse, there may already be waypoints in the receiver
that may duplicate the names you're about to shoot in.  It's for this
reason that I find geocaches named "geocache" unamusing. :-) This is the
reason that programs like Magellan's Mapsend say "I'm going to vaporize
any waypoints now in your receiver and replace them with this set".  I
don't find that behaviour very useful, either...

RJL

[Gpsbabel-code] Removing Duplicate Waypoints... how to / where to?

[Alex M. <al...@co...>]

My problem:
I've got multiple input files, some with the same waypoints with the 
same name/same coordinates,
some with a different name/same coordinates, and probably some that I 
haven't seen that need
to be dealt with (different name / points within a few feet).  

These are both lists of waypoints I've collected over the years from 
various sources, as well as
weekly "geocaching.com" updates of hundreds of waypoints, hundreds of 
which are duplicates
(everything in my state / everything within 500 miles of me = 50% or so 
duplicates).

My interim solution:
Currently, I've sloppily hooked into -o processing in main (as opposed 
to output processing
for each output type), and all works as *I* need it to (pointer array -> 
sort ->dequeue dupes
->output).  However, gpsbabel's flexibility to handle  parameters like 
"-i xxx -f xxx -o xxx -F
xxxx -i xxx -f  xxx -o xxx -o xxxx (ad nauseum)"  would be serious waste 
of time, or maybe not,
depending on the options.   Toss in the need / want to synthesize 
shortnames on output, dequeue
by name,  matching position, or both,  and you've got a potential mess. 
 Which came first, the
chicken or the egg?

There has to be a clean(er) solution.  Any ideas?

Thanks,

Alex Mottram

[Gpsbabel-code] endianness fixes (mostly) in

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

I think the portability gpsbabel has now recovered from the recent
rash of binary file formats we've added.  Testo now runs on
Linux/IA32 and OSX/PowerPC.  (I don't own/want a mac; I use the
compilefarm.sourceforge.net hosts.)

Floating point numbers are largely a crapshoot on hosts of different
processors, but IEEE math is used on most modern processors so things
tend to work "well enough".  Strangely, the mapsend file formats
(another file format that's depressingly PC-centric) bit-matches on
Sparc and it uses doubles.  But for psp, I'm always off one bit and
I've given up trying to find that bit.  Linux on PowerPC shows the same
artifact.

If anyone here does floating point and can find the detail with that
bit, it'd be most appreciated.


I believe this gets us "feature complete" for a 1.0 release.  I'd still
like to get Toby's gpspoint backend (it's text, so it won't have the
portability grief of these others) slotted in and work out the i18n
issues with GPX, but I think we're in the home stretch...

Thanx for all your help.
RJL




bash-2.05a$ cat g
./gpsbabel -i psp -f reference/ps.psp -o psp -F xxx.psp
od -A x -t x1 xxx.psp > xxx.hd
od -A x -t x1 reference/ps.psp > ref.hd
diff *.hd
bash-2.05a$ sh g
10c10
< 000090 6c 6a ac 26 28 e4 3f 20 6c f5 6d 9b 34 f8 bf 14
---
> 000090 6c 6a ac 26 28 e4 3f 1f 6c f5 6d 9b 34 f8 bf 14
16c16
< 0000f0 00 79 00 00 00 00 00 00 03 a0 d7 a9 d0 a6 1a e4
---
> 0000f0 00 79 00 00 00 00 00 00 03 a1 d7 a9 d0 a6 1a e4
22,23c22,23
< 000150 00 6d 00 69 00 6c 00 79 00 00 00 00 00 00 03 78
< 000160 86 cc 09 b0 20 e4 3f 05 28 bd 50 65 32 f8 bf 14
---
> 000150 00 6d 00 69 00 6c 00 79 00 00 00 00 00 00 03 77
> 000160 86 cc 09 b0 20 e4 3f 06 28 bd 50 65 32 f8 bf 14
41c41
< 000280 00 00 00 00 00 00 03 a5 80 c4 ea bb 27 e4 3f 3f
---
> 000280 00 00 00 00 00 00 03 a6 80 c4 ea bb 27 e4 3f 3f
55c55
< 000360 3f dd c2 1e 28 07 42 f8 bf 14 00 00 00 00 00 00
---
> 000360 3f dc c2 1e 28 07 42 f8 bf 14 00 00 00 00 00 00

[Gpsbabel-code] malloc procedures

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

Since gpsbabel is a short-running program and even the largest data sets
should easily fit within memory (real or virtual) on any interesting host,
always feel free to dynamically allocate memory and treat it as a fatal
error if that allocation fails.   No data should ever really be lost as
gpsbabel is always converting from something to something else.