PQ - Finding Caches Along a Route

[+Falach-fead]

Using the PQ for routes very infrequently, I found that I had filtered for "I own" instead of "I don't own" on two Route PQs. The "I own" is on the second line first column for Route PQ filter...on a normal PQ, the "I don't own" is in that location. I suggest that those filter layouts should be the same for both a regular PQ and a route PQ.

 

The two route PQs generated no caches due to the error in picking the correct filter. Instructions said to look for an error and fix it, which I did. The e-mail link I received now opens to indicate there are several hundred caches along the route, but only displays them 20 at a time. Nothing showed up the in the PQ download list to download the entire ZIP file. It would seem that the queries ran, but if you don't change the name of the PQ then it will not create a ZIP file even if the PQ was corrected and it contains hundreds of caches.

 

To add to the frustration, the PQs that generated no caches due to errors count as 2 PQs towards the 5 PQs per day. The two corrected PQs also counted as 2 PQs for the day but created nothing in the download list. Since I had already ran 2 normal PQs earlier in the day, I still expected the first corrected route PQ to run and create a download file. Ideally, a PQ that creates no caches should not count against the five per day; maybe asking too much. A fifth PQ for the day that generates caches but does not provide a download file should definitely not be counted against the five per day. There is a bug in the creation of the PQ download file if you don't change the name. The only workaround that I have used is to change the name during corrections (usually simply adding an extra letter or number at the end) and resubmitting. The instructions to look for errors regarding PQs should include a note to change the PQ name before resubmitting.

[+Gitchee-Gummee]

Little trick (explained also in the Help Center Creating Your First Pocket Query - Steps in step #6)...

 

Leave the day-of-the-week to run unchecked.

Immediately upon submitting that query, you are provided with a link to PREVIEW the query.

It is only a preview -- the query has not been run. You can check the list provided and/or click on the map to see each and every cache it selected.

 

If you are happy with the results, return to the PQ page, check the day-of-the-week to run and resubmit.

 

If you are not happy with the results, return to the PQ page and adjust the parameters to meet your needs. Submit it again (unchecked as before), repeat with the preview, etc., etc., etc.

 

Because the query never ran (remember -- it is only a PREVIEW)... it does not count against your 5/day limit. You can do this as many times as you want with no effect on the limits.

 

 

Changing the name... yes, this is in regards to repeat running of an identical PQ. I don't think it is a bug, it is intentional. Some folks have a habit of "forgetting" and leaving it run again, and again, and again. It *shouldn't* happen, but it would if repeats were possible.

 

If it weren't done that way... none of use would ever be able to use those servers because the repeated runs would clog the system.

So save the angst... check the preview first, then submit it for real.

Edited February 8, 2014 by Gitchee-Gummee

[jholly]

I find it much easier to not select a day, submit the PQ definition and then check the list or the map to verify the results. If the results are not what I want I change the PQ definition and re-submit and the check again. Only when I am happy with the results do I check the day to run and then submit. That way I don't use up my daily allotment or have problems trying to copy the definition to rerun the fixed definition. As long as you do not pick a day there is no limit to the number of times you can tweak the definition.

 

If you don't select a day you don't get the zip file for download or in an email.