Jump to content

Pocket Queries Bug


-=(GEO)=-

Recommended Posts

Posted

I've just found a bug in the Pocket Queries Generator on the site <_<

 

It turns out that that Pocket Queries don't produce consistent results depending on the criteria used to create them B) If you create a query containing ONLY your finds, the caches will not all be tagged properly as 'GeoCache Found'. Instead, only some of them, seemingly randomly, will be tagged as 'Found' while the majority will appear to be still 'Un-Found' caches. This problem does not exist when a query returns a mixed set of "Found" and "Unfound" caches.

 

Regards,

Fabien.

Posted

Hmmm, if that's true, that would explain one of the "technical difficulties" we experienced caching last weekend. Geo Ho and myself were caching in an area where we both have a lot of finds individually. Looking for caches neither of had done, she created a PQ for the weekend using both our accounts that should have been just caches neither of us had found. Wouldn't you know it, the very 1st one we hit looks familiar to her. Yup, she did it last year. We couldn't figure out why it was in the query, especially since a nearby cache she had done at the same time wasn't. Found a few others like mixed in as well. At the time, I assumed the error was a mistake on our end. Now I guess I'll go back and see how she put our query together, and if she saved the originals.

Posted

Mopar, you could have planned your trip with some admittedly esoteric options to GPSBabel. Here's how I'd have done it. Take one pocket query of the area to be search, and a PQ of each of your respective finds. (These could probably be of type 'geo', but for simplicity, order them up as GPX.)

 

gpsbabel -i gpx -f biglist.gpx -f hers.gpx -f yours.gpx -x duplicate,all -o gpx -F hunt.gpx

 

Now 'hunt.gpx' will contain only caches that neither of you have found and it's much more reliable than depending on specific SYM tags.

Posted
gpsbabel -i gpx -f biglist.gpx -f hers.gpx -f yours.gpx -x duplicate,all -o gpx -F hunt.gpx

Actually, hunt.gpx will contain nothing. You know the options are esoteric when the chief babel-head gets 'em wrong. <_<

 

gpsbabel -i gpx -f biglist.gpx -f hers.gpx -f yours.gpx -x duplicate,shortname,all -o gpx -F hunt.gpx

Posted

Yesterday and today we had implemented a flawed idea in our pocket query generator. We were storing caches in memory with only the last 5 logs, since some caches (especially locationless) can have upwards to 500+ logs. Unfortunately in doing so it can't walk through all the logs to determine if user A found the cache.

 

I corrected this and will have to find an alternative solution that reduces the size of caches for the generator, but maintains the current features.

Posted (edited)

Jeremy answered too soon, because I wanted to post a similar problem about my query called "Tough Nuts". <_<

 

These are higher difficulty rated caches in my area (darned few).

 

I believe Jeremy's answer fits the symptoms that I saw.

 

I needed a "good" reason to post Tough Nuts in these forums.........

Edited by DustyJacket
Posted

i was going to say i must be something like that jeremy. maybe a listing of account names that the generator looks at to determine if the cache has been fond by that user, that way it doesnt have to read all the logs.

Posted

Team GPSaxophone...

 

The point is that PQs should be deterministic in their output. In other words, a "Found" cache should always be tagged as such, regardless of the intent of the query.

 

This has nothing to do with EasyGPS which is oblivious to all of the interesting stuff in PQs anyways. But other pieces of software that do care about it are at a loss when inconsistencies are introduced like that.

 

Regards,

Fabien.

Guest
This topic is now closed to further replies.
×
×
  • Create New...