+-=(GEO)=- Posted January 20, 2004 Share Posted January 20, 2004 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 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. Link to comment
+Mopar Posted January 20, 2004 Share Posted January 20, 2004 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. Link to comment
robertlipe Posted January 20, 2004 Share Posted January 20, 2004 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. Link to comment
+parkrrrr Posted January 20, 2004 Share Posted January 20, 2004 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 Link to comment
Jeremy Posted January 20, 2004 Share Posted January 20, 2004 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. Link to comment
+DustyJacket Posted January 20, 2004 Share Posted January 20, 2004 (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 January 21, 2004 by DustyJacket Link to comment
+planetrobert Posted January 21, 2004 Share Posted January 21, 2004 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. Link to comment
+Team GPSaxophone Posted January 21, 2004 Share Posted January 21, 2004 If your query is for ONLY finds, why would it matter if it is labeled as geocache found or not? You can put it into EasyGPS and give all caches the same icon if it's that important Link to comment
+-=(GEO)=- Posted January 21, 2004 Author Share Posted January 21, 2004 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. Link to comment
Recommended Posts