Re: [Gpsbabel-code] Almost ready to send in a module for Quo Vadis for PalmOS

[Bruce T. <dr...@ot...>]

On Thursday, Jun 12, 2003, at 11:49 US/Pacific, Robert Lipe wrote:

> Bruce Thompson wrote:
>
>>     I'm going to try a fresh checkout of the cvs tree and see if that
>> compiles and runs testo clean out of the gate. If not then I'll get in
>> touch with you about where to go from here. Setting up an account for
>> you shouldn't be a problem if need be.
>
> Feel free.  I haven't installed RH9 here yet and it's not available on
> compilefarm.  I can put it on a lab system, but that's a couple hours
> I'd rather not burn if I could avoid it.

I'll try it out from a clean build and see what I get as I'm getting 
better (some minor issues, see below) results on the Mac right now.

>
>>     I will give a look at the magproto code to see how that handles
>> icons. Thanks for the pointer.
>
> It's a pretty straight forward table lookup.

sounds good. I think for a first cut I'll just key off the cachetype 
for choosing an icon then get more elaborate later...

>
>>    Building on Mac OS X is a definite convenience factor, I carry my
>
> It should Just Work.  (At least the GPSBabel part should.)  Since expat
> is part of several programs including Apache, I feel good that someone
> somewhere has done whatever needs to be done to make it fly on OS/X.

And it does. Thanks for the heads up about fink BTW, it did the trick. 
FYI, fink is a package fetch/installer for open source projects that 
have been ported to Mac OS X. It uses the Debian package format and is 
in a lot of ways similar to CPAN in usage.

I'm building fine now, though gdb is giving me fits. I may have screwed 
something up when I attempted to upgrade gcc a while back. Not a 
showstopper.

I am seeing a couple of trivial errors and a serious error when running 
testo. The order of the output from the dup and pos tests change. The 
contents are the same but one line has changed position from line 1 to 
line 8. I've worked around it by sorting the output before the compare 
in the script.

A more serious error is the last test. It outright fails:

---- Begin Transcript ----
Red-Dwarf:~/src/projects/gpsbabel] bruce% ./testo
9c9
< <wpt lat="35.972033" lon="-87.134700">
---
 > <wpt lat="0.000000" lon="0.000000">
16c16
< <wpt lat="36.090683" lon="-86.679550">
---
 > <wpt lat="0.000000" lon="0.000000">
23c23
< <wpt lat="35.996267" lon="-86.620117">
---
 > <wpt lat="0.000000" lon="0.000000">
30c30
< <wpt lat="36.038483" lon="-86.648617">
---
 > <wpt lat="0.000000" lon="0.000000">
37c37
< <wpt lat="36.112183" lon="-86.741767">
---
 > <wpt lat="0.000000" lon="0.000000">
44c44
< <wpt lat="36.064083" lon="-86.790517">
---
 > <wpt lat="0.000000" lon="0.000000">
51c51
< <wpt lat="36.087767" lon="-86.809733">
---
 > <wpt lat="0.000000" lon="0.000000">
58c58
< <wpt lat="36.057500" lon="-86.892000">
---
 > <wpt lat="0.000000" lon="0.000000">
65c65
< <wpt lat="36.082800" lon="-86.867283">
---
 > <wpt lat="0.000000" lon="0.000000">
ERROR comparing /tmp/gpsbabel.4845/ez1.gpx /tmp/gpsbabel.4845/ez2.gpx
[Red-Dwarf:~/src/projects/gpsbabel] bruce%
---- End Transcript ----

I haven't yet investigated the cause, but I wanted to pass it on. I did 
a cvs update just now and other than my locally changed files nothing 
is out of date.

I'll do a clean build without quovadis on my home machine for a 
comparison.


>
>>     Oh, on a side note. How does the duplicate removal process choose
>> which waypoint to keep? The reason I ask is that I eventually plan to
>
> Are you asking about the duplicate waypoint filter?  It can suppress
> dupes based on shortnames or location.  It looks like the first one 
> read
> is the "winner" in case of a conflict.  I could be wrong.
>
>> have a small set of files that I regularly build into a new Marker
>> Database. In that set I'd like to have one file containing my manually
>> entered waypoints, another set with Caches I've found (to override
>> the icon selection so they are distinctive on the map) and possibly
>> to have a set with additional notes, say from a cache that I tried to
>> find but was unable to. There is a real possibility that some of these
>> will show up in my PocketQueries so I'd like to be able to predict
>> which of several identically named waypoints will be kept by the
>> duplicate filter.
>
> Interesting idea.  I think the key would be in the ordering of the 
> input
> files on the command line.
>
> 	-f you_really_really_want -f you_really_want -f you_kinda_want
>
> If you have duplicates, presumably with additional information beyond
> simply the coordinates, the first one found will be the one kept.
>
> [ Begin experiment. ]
>
> $ echo "1.0, 2.0, one" > /tmp/one ; echo "1.0, 2.0, two" > /tmp/two
> (robertl) rjloud:/home/robertl/src/gpsbabel
> $ ./gpsbabel -i csv -f /tmp/two -i csv -f /tmp/one
> 1.000000N 2.000000E two/two 0.000000
> 1.000000N 2.000000E one/one 0.000000
> (robertl) rjloud:/home/robertl/src/gpsbabel
> $ ./gpsbabel -i csv -f /tmp/two -i csv -f /tmp/one -xduplicate
> 1.000000N 2.000000E two/two 0.000000
> (robertl) rjloud:/home/robertl/src/gpsbabel
> $ ./gpsbabel -i csv -f /tmp/one -i csv -f /tmp/two -xduplicate
> 1.000000N 2.000000E one/one 0.000000
>
>
> Yes.   First one in the waypoint list (which is populated in command
> line order) is the "winner".
>
> RJL
>
>

Perfect, that's exactly what I was hoping for. What I'm thinking of is 
something like:
./gpsbabel -i gpx -f PersonalWaypoints.gpx -f GeoCachingFound.gpx -x 
icon=present -f GeoCachingInProgress.gpx -x icon=question -f 16188.gpx 
-f 15716.gpx -f 15715.gpx -x duplicate,shortname -o quovadis -F 
QuoVadisMarkerDB.PDB

in fact that will probably be literally the command line I'll use. The 
three last files are my current PocketQueries. Now to see if I can make 
this thing choke on lots of waypoints...

	Cheers,
	Bruce.