GPSBabel

[oops, forgot to reply all on this one; resending it to the list for the 
archives.]

At 09:09 PM 3/6/2004, you wrote:
>Could the limited GPX file created by st2gpx somehow be used to query the 
>original pocket query GPX file and create a GPX file suitable for GSAK (or 
>Spinner) with only the caches in the st2gpx file.

I'm in the mood to write ugly GPSBabel command lines today, obviously, so 
here ya go:

gpsbabel
   -i gpx -f fromst2gpx.gpx \
   -i gpx -f original.gpx \
   -x duplicate,location,all \
   -i gpx -f original.gpx \
   -x duplicate,location,all \
   -o gpx -F whatyouwant.gpx

This is ugly.  What it does is read in the pushpins and the original 
caches, then uses the pushpins as an "ignore" list on the original 
list.  The resulting list is all of the caches that aren't in the pushpin 
file.  It then uses THAT list as an "ignore" list for the original cache 
list again, resulting in just the caches that were in the pushpin file, but 
as read from the original Groundspeak GPX.

James Sherring wrote:

> It would be non-trivial for st2gpx to give the full
> GPX back, but I will
> consider stuffing some more of the original gpx into

Considering that "the full GPX" in this case goes way beyond simple
coordinates and, while technically unbounded by size, ranges from 4K
to 28K based on 3,570 waypoints I happened to have laying around.  The
average size for this sample set was 5,195 bytes.

It's quite non-trivial...

RJL

At 09:56 PM 3/7/2004 -0700, pdops wrote:
 >Ron
 >
 >Thanks I was able to get the command line to work as you suggested. After
 >Babel is
 >done the result contains the same caches listed in the st2gpx file but
 >unfortunately they appear to be a mixture of some with complete information
 >and
 >some with the limited information originally in the st2gpx GPX file.
 >
 >Did you have the same result?

Okay, I've tested it now and I see what's happening.  Unfortunately,
it's not going to work without a major miracle.  The problem is that
duplicate,location wants *perfect* duplication of locations, and the
gpx->S&T->gpx process seems to lose a lot of precision.  For example:

[ron@... foodle]$ gpsbabel -i gpx -f 28914.gpx -f 28914est.gpx -x 
duplicate,location,all | grep Wilcox
  52.227667N 117.218983W GCGH93/Wilcox Cap by reastick, Virtual Cache (1/4)
52.227670N 117.219000W GCGH93 Wilcox Cap by reastick Virtual Cache 
(1/4)/GCGH93 Wilcox Cap by reastick Virtual Cache (1/4)

duplicate,shortname doesn't seem to work, either.

The 'distance' filter could do this kind of "fuzzy" location filtering,
but it doesn't have an 'all' option like 'duplicate' does.  Until now,
I don't think anyone ever saw a need for such a thing.

Actually, size is not much of a problem, as long as
you don't mind a larger
S&T file.

I have successfully stuffed wpt fragments into the
pushpin's GeocodeLong
field (which apparently has a 1GB limit...) and
retrieved them again when
converting to GPX. Mostly this gives GPX output that
looks identical to the
original.

The 2 problems so far are due to the difficulty in
extracting the complete
GPX fragment when parsing the original GPX to create
the S&T file:
1. Expat does not track it's current buffer position
well in some some
buffer transition situations, sometimes causing me to
loose the start of the
wpt element read BEFORE the start wpt read element
callback. I can string
together the following parts ok across buffer reads.
2. Expat's read buffer seems to have been preprocesed,
translating escaped
chars etc. So the fragment I get is not always the
original GPX.

There are various solutions to this, all of which
involve varying degrees of
reprocessing the original gpx, with or without Expat's
help. This is the
non-trivial part :)

Given the solution already proposed by Ron using
GPSBabel filters, I am not
inclined to pursue this further unless it really
excites a number of people.

Cheers,
James

-----Original Message-----
From: gpsbabel-misc-admin@...
[mailto:gpsbabel-misc-admin@...] On
Behalf Of Robert Lipe
Sent: Monday, 8 March 2004 5:12 PM
To: James Sherring
Cc: 'pdops'; gpsbabel-misc@...
Subject: Re: [Gpsbabel-misc] st2gpx


James Sherring wrote:



> It would be non-trivial for st2gpx to give the full

> GPX back, but I will

> consider stuffing some more of the original gpx into



Considering that "the full GPX" in this case goes way
beyond simple

coordinates and, while technically unbounded by size,
ranges from 4K

to 28K based on 3,570 waypoints I happened to have
laying around.  The

average size for this sample set was 5,195 bytes.



It's quite non-trivial...



RJL





-------------------------------------------------------

This SF.Net email is sponsored by: IBM Linux Tutorials

Free Linux tutorial presented by Daniel Robbins,
President and CEO of

GenToo technologies. Learn everything from
fundamentals to system

administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

_______________________________________________

Gpsbabel-misc mailing list

Gpsbabel-misc@...

https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

At 09:04 AM 3/8/2004 -0800, James Sherring wrote:
 >Given the solution already proposed by Ron using
 >GPSBabel filters, I am not
 >inclined to pursue this further unless it really
 >excites a number of people.

For the record, my solution didn't work, due to some inaccuracies in the 
S&T representation of the coordinates.  See my other email to this list for 
more details, and see my upcoming email to -code for the continuing saga.

At 11:33 AM 3/8/2004 -0500, Ron Parker wrote:
 >The 'distance' filter could do this kind of "fuzzy" location filtering,
 >but it doesn't have an 'all' option like 'duplicate' does.  Until now,
 >I don't think anyone ever saw a need for such a thing.

For what it's worth, and for future reference, I've added this 'all' option 
to the 'position' filter (I misspoke when I said 'distance') in CVS.  The 
command line to do what you want is then:

gpsbabel -i gpx -f fromst.gpx -f original.gpx -x position,distance=10m,all 
-f original.gpx -x duplicate,location,all -o gpx -F output.gpx

(Again, this WILL NOT WORK with the current version of GPSBabel; you need 
the CVS version, or the next released version.)

James Sherring wrote:

> callback. I can string
> together the following parts ok across buffer reads.

Yes, that's what you have to do.   Yes, it's klunky.

> 2. Expat's read buffer seems to have been preprocesed, translating
> escaped chars etc. So the fragment I get is not always the original
> GPX.

That, too, is correct.  To reconstitute it, you have to be prepared to
reconstruct the entity encoding.

> I am not inclined to pursue this further unless it really excites a
> number of people.

I'm not inclined to pursue it much further even then, but if someone
submits a sensible patch that solves the problem for them (and doesn't
dogmeat-ify anything else) I'd consider integrating it.

RJL

> For the record, my solution didn't work,

Ok, perhaps I spoke too quickly... 

> gpx->S&T->gpx process seems to lose a lot of
precision.

> 52.227667N 117.218983W GCGH93
> 52.227670N 117.219000W GCGH93 

That's still a sub meter/foot difference, but should
be better. I don't have this inaccuracy with my
current builds, I'll take a look at where this crept
in.

Cheers,
James



__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com