Jump to content

Pocket Queries Not Working Properly


Kilted Cacher

Recommended Posts

The Pocket queries are not generating like they usually do. They usually are in distance order from the point of origin, now the last two times I ran a query it has come in some sort of random order, with no pattern to the order (alphabetical, numerical, or distance). Any info would be helpful, thanks.

Link to comment

Thanks very much. I just downloaded and tested out the GSAK program and also the gpxview program for my PocketPC, which is what I want a program for in the first place. If I am going to use the PocketPC, is there any reason to use the GSAK or can I still use this in some way. Another question I have is when I open the GPX file in either one of the programs listed it only shows the first 4 logs and not the latest logs for a cache. Is there any way to change this?

Link to comment

I'm not familiar with gpxview, so I'm not sure if it does everything that GSAK does. GSAK is very good at managing cache files including sorting caches, selectively ignoring those you do not intend to seek, merging gpx lists, and converting these files to other formats such as csv for importing to MS Streets and Trips.

 

I believe the log issue you referred to is a recent bug that is being discussed in a different thread. Normally, the gpx files include the most recent five logs.

Link to comment
They usually are in distance order from the point of origin, now the last two times I ran a query it has come in some sort of random order, with no pattern to the order (alphabetical, numerical, or distance).

I've just noticed the same: :) I use the Mobi-pocket version with a weekly update of all caches in the area straight onto the Palm (600kb file).

 

Could there be a damaged index in the SQL tables somewhere?

Link to comment

Is anyone else having trouble with PQ's today?

 

I would have thought that a few hours would be enough time on a Monday. They don't even seem to have been generated. I have waited before on PQ's stuck in the mail queue but this seems to be slightly different.

 

Chances are that they will show up because I took the time to ask.

 

Thanks,

 

Team Geo-Jedi

Link to comment

Jeremy,

My Zipcode 10801 caches are also scrambled as to order. They used to be in distance order from my zipcode, now they are all over the place yet in groups. Ie: all the caches 3 miles out then 17 miles alternating with those 13 miles out then 18miles alternating with 13miles then 4miles out!!!

 

Cache identifier is GSP10-49198

 

Also my caches for 10801 which are rated 1/1 are just totally scrambled.

id is GSP10-49199

 

AND zip 11375 ID # GSP10-49200

 

All from 5/16 download. :grin:

Edited by Crusso
Link to comment

I have found that PQ number 41984 is giving me random Caches from various geographical regions. since this is a file I don't use alot I don't know how long it's been acting up. But Last week's PQ for this file gave me 300 caches from near TitusVille Fl. This week's file gave me 500 caches just southeast of Great Salt Lake in Utah! it'll be interesting to see what it's going to give me next....

 

BTW this file is to give me all the caches I found., which is less than 100 right now, all in PA

Link to comment

I'm not having the "scrambled" problem (or maybe I am, and just don't notice, cuz I pass 'em all through GSAK first thing). I'll take a look at that and report back...

 

In the meantime - I AM having a different problem with PQs, and didn't find another relevant thread, so figured I'd post here rather than starting a new one.

 

I've got a PQ for (the last 500) caches found in CA. It's:

 

"CA_found" : http://www.geocaching.com/pocket/gcquery.a...68-c59dede846d0

 

For some reason, I've noticed over the past some time (month or so?) that I haven't been catching all my finds in this query. Everyone once in awhile, one will slip through. After confirming that it IS properly classified as a CA cache, and that my "found" log is still present... I typically download a GPX file of the individual cache, and add it to my GSAK "found" database.

 

I recently had another such example, so I thought I'd ask about it before simply resolving the problem. Back on 5/19, I found "June's Cache" (GC60E6) - and yet this find still doesn't appear in my PQ received today, more than 5 days later. I even went so far as to grep through the GPX file, just to make sure GSAK wasn't dropping it for some reason. Nope - it's not there.

 

I didn't notice any such pattern with past ommissions - but perhaps the fact that there's a single-quote in the title? I know that can do some damage if not properly escaped (at least in my world ;-) - but I'm rather clueless as to why it's not working.

 

Interesting: When I select "Preview" from the PQ page, and scroll to the right spot in the list - the cache is listed. However, I'm quite certain that it isn't present in the GPX file being delivered to me.

 

Any thoughts / suggestions / similar experiences?

 

Thanks much,

Billy

(aka SnoWake)

Link to comment

Hello!!??? Anyone out there? After more than 10 days this issue still has not been resolved. After all, this IS a feature we are PAYING for!!! My cache downloads are still scrambled and the last time we heard any status an the issue was on the 16th when Jeremy said he would look into it. :tongue:

Edited by Crusso
Link to comment
Hello!!??? Anyone out there? After more than 10 days this issue still has not been resolved. After all, this IS a feature we are PAYING for!!! My cache downloads are still scrambled and the last time we heard any status an the issue was on the 16th when Jeremy said he would look into it. :tongue:

Is there a different membership for sorting queries?

I guess I didn't pay for it, because I searched all over my PQ setup page, and couldnt find any option to sort the caches in any particular order.

If it's really an issue, use Watcher or GSAK, and the caches are centered on any spot you like.

Link to comment
Is there a different membership for sorting queries?

Agreed.

 

If Jeremy hasn't promised a certain order for the output, you really can't complain if you don't like the order. (Well, I guess you CAN complain, but you can't expect sympathy.)

 

SnoWake doesn't see a problem because GSAK doesn't care what order the updates arrive in....

 

Now if Jeremy removed the "ORDER BY DISTANCE" clause from his SQL by mistake and wants to put it back, fine with me. But it's safer not to assume an order that is not documented.

Link to comment

If I were the prgrammer building the PQs, I wouldn't sort them as there's no reason to burn the compute time on the server as most applications are going to sort them ont he client side anyway.

 

But if you really are using an app that can't sort them, just presort them before handing them to that app. Reordering 1300 caches takes under two seconds if you have the right tools.

 

gpsbabel -i gpx -f MiddleTN -x radius,lat=35.89,lon=-86.89,distance=100 -o gpx -F MiddleTN-sorted.gpx

 

Will take the PQ named MiddleTN, include everything that's within 100 miles of the center coordinates, sort them by that distance, and create a new GPX file called MiddleTN-sorted that you can then play with. Append a 'k' to the distance if you do kilometers. Coords are given in decimal degrees.

 

Full explanation at http://gpsbabel.sourceforge.net/readme.html

Link to comment

Because of some issues with a move I am currently on dialup, so it has been difficult to test code. Hopefully I'll have high-speed access later today and can have better access to the machines in production.

 

I did make some changes earlier in the week that should have resulted in better sorting by distance. I'll be checking individual pocket queries to determine why they aren't working.

Link to comment
Because of some issues with a move I am currently on dialup,

Man, you woulda thought a house like that woulda come with something better then MSN dialup! :tongue:

 

gateshse4.jpg

Jeremy's new House. (the yellow Jeep is parked out front)

Link to comment

Note: I was having trouble getting a pocket query named "post 4-20-2004" (and similar variations).

 

I changed the name to "arrggghhh" (or something like that).

 

It worked perfectly.

 

Are '-' symbols in the query name a bad idea?

 

Edit: nevermind. They're showing up now. A few days late, but they're here. :tongue:

Edited by bons
Link to comment
But if you really are using an app that can't sort them, just presort them before handing them to that app. Reordering 1300 caches takes under two seconds if you have the right tools.

Works fine for the GPX and LOC extracts to sort post-generation, but if you're using the e-book format, then it's just a handy undocumented feature that's gone bye-bye :tongue:

Link to comment
But if you really are using an app that can't sort them,  just presort them before handing them to that app.  Reordering 1300 caches takes under two seconds if you have the right tools.

Works fine for the GPX and LOC extracts to sort post-generation, but if you're using the e-book format, then it's just a handy undocumented feature that's gone bye-bye :tongue:

Aaaah, I should have known if there was one consumer of that data on the entire planet that used that data that stupidly it would be that one. I didn't realize anyone was using those any more since so many better tools were now widely available. I do now see why this is a problem for you.

 

(Though I'd still not sort the PQ itself; if I were Elias/Jeremy, I'd sort it in the thingy that handed it to the Mobipocket smoosher...)

Link to comment
Aaaah, I should have known if there was one consumer of that data on the entire planet that used that data that stupidly it would be that one. I didn't realize anyone was using those any more since so many better tools were now widely available. I do now see why this is a problem for you.

[ducks as flame balls go whooshing overhead] :lol:

Nyaaaa Nyaaaa, missed me! ;)

Link to comment

I'm STILL having troubles with pocket queries, returning all the "matching" caches. Of most interest (and most easily verifiable) is my "CA_Found" PQ. This query is configured to return my 500 most recent finds in California.

 

However, for some reason, every once in awhile certain finds fail to show up in this query. Once I figure out which ones aren't showing, I can go pull down GPX files of the individual cache, for import into GSAK.

 

So, the current example: I hit up 6 caches on my way up to a camping trip at East Park Reservoir, all found on 6/5/04. Yet, a few of the finds don't appear in my "CA_found" PQ. I've double-checked the PQ criteria, AND the individual caches (make sure they're properly identified as "California" caches, etc) - I don't see any explanation for the missing finds.

 

In the latest runs of my PQ dated today, 6/11, the following caches are missing:

 

Maranatha on Allendale - GC4F09 (found 6/5)

I-80 Gold Run WB - GC2197 (found 5/30)

 

I've had multiple instances of this - but if I stay on it, I can usually catch the stragglers, and pull them down individually.

 

Any ideas as to what might be going on?

 

Thanks,

Billy

(aka SnoWake)

Link to comment

I'm also having problems with pocket queries in mobipocket format turning up in a bizarre, random order. So the first cache listed in my query (#80889) is 10 miles S, then the next is 8mi E, then the next is 12 mi W. I get to the closest unfournd cache to my home on page 127 of the mobipocket doc. Is there a fix planned for this anytime soon?

 

If not, what other alternatives are there for getting the cache pages to a Palm OS PDA?

Link to comment
I'm also having problems with pocket queries in mobipocket format turning up in a bizarre, random order. So the first cache listed in my query (#80889) is 10 miles S, then the next is 8mi E, then the next is 12 mi W. I get to the closest unfournd cache to my home on page 127 of the mobipocket doc. Is there a fix planned for this anytime soon?

 

If not, what other alternatives are there for getting the cache pages to a Palm OS PDA?

I'd quit with the mobipocket and go with Cachemate and GSAK. There are others out there that are being used, but I find this combo great.

Link to comment

Thanks for the suggestions. So you sort the gpx file with GSAK and convert them to cachemate format, and then use cachemate on the PDA? What does GSAK do for you that cachemate doesn't? This is sort of mildly annoying - the eBook format was drag-n-drop simple, and I've already purchased the mobipocket reader... (Not that cachemate + GSAK is very expensive - $22, it's mostly just having to learn something new, and converting the files before I transfer them.) Thanks anyway. I hope they fix the mobipocket docs.

Link to comment
OK, I purchased cachemate - looks like a nice utility! Thanks again for the suggestion. I'll just remove the mobipocket doc from my queries I guess.

I think you'll be quite satisfied with cachemate. That's all I used for the longest time. I downloaded GSAK about a month or so ago, and now use it to sort and filter caches for potential hunts, and then download the caches to the GPS from there.

 

As you said, with GSAK you can sort the gpx file and convert them to cachemate format, and then sync them to your PDA.

 

If you decide to try GSAK, I think it's still free, you just have the option of paying. A lot of people have.

Link to comment
I have found that PQ number 41984 is giving me random Caches from various geographical regions. since this is a file I don't use alot I don't know how long it's been acting up. But Last week's PQ for this file gave me 300 caches from near TitusVille Fl. This week's file gave me 500 caches just southeast of Great Salt Lake in Utah! it'll be interesting to see what it's going to give me next....

 

BTW this file is to give me all the caches I found., which is less than 100 right now, all in PA

I have this same problem on th main query I use. Usually I get the right PQ for my area. But 3 times that I can remember now I got PQs for random areas around the country that seemed to be other people's PQs. I live in OH, on querey I got was from CO and although I'd like to hit those caches it's a bit of a drive. Another PQ I got appread to be a list of someone's found caches from California. The PQ always arrived with the correct file name though. It would seem that sometimes there is confusion about which PQ numbers results are actually being returned.

Link to comment

I'm not the least worried about sort order (GSAK does that, and A LOT more for me), and I "spin" cachemate AND HTML files for my Palm.

 

However - I guess no one else is having the problem of caches MISSING from the query? Might be hard to detect when searching for caches you haven't found - but my "CA_found" query continues to fail to return the "full" (most recent 500) set of finds.

 

I can find no logic (distance, cache type, status, etc) to explain this behavior. No one else is seeing this, huh? Guess it's just a personal problem...

 

Have a great day!

Billy

(aka SnoWake)

Link to comment

I've been experiencing the problem of unsorted data in my e-book queries. I'm also using Mobipocket. My lastest query Thursday (6/17/2004) has the problem. The file name is 5279.prc (490 caches within 200 mi radius)

 

The caches that show up first in the e-book are 17 miles away, then 59, then 50 miles away. On my first page on the geocaching site, I have a cache that is 3.3 miles away that I haven't found.

 

I would appreciate any help that could be provided.

Link to comment

I've been having the problem for a few weeks now. Thought it was when I upgraded Mobipocket. I like mobipocket. Sure don't want to have to do more conversions with multiple programs.

I'll have to try it until gc can straighten out the problem.

Link to comment

Ditto Haygood. I've developed a routine around mobipocket that works for me, and I'd rather not switch to something that seems less user-friendly.

 

What seems strange is that the same PQ will generate the same list in different orders, depending on when the PQ runs

Link to comment

Hi - I'll throw my hat into the ring; just signed up, and mobipocket seemed like the most straightforward way to get cache pages onto my palm to take along, but it's a lot harder to find the right one, one handed, carrying two kids, with the random order. I guess the enticement/annoyance is that just above the scrambled output, is the promise of order in our lives, where there is usually so little...

 

At least I know I'm not the only one who can't figure out the order.

 

Philip

 

ps I don't mind the typo (use->us) nearly so much

Edited by baby jogger
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...