Pocket Queries

[bshwckr]

Hope this is not an old question....Has anyone a system that allows the downloading via pocket query of every cache in Australia over the shortest period of time?
My new job covers all of Australia so I should be getting around a bit. I like to go prepared. Trimble has been working well so far on the 6110 but it relies too much on a network connection.
It may be better to sort via state to give the PDA a breather but sometimes I will travel across 2 or 3 states in one trip.
Cheers
bshwckr

[CraigRat]

You need to set up a HEAP of pq's, given they all have a 500 cache limit.
You may even need to get a second Premium membership to achieve this.

Use the date ranges found here: http://geocaching.com.au/stats/range/ to optimise how many you get.

There is no way to grab all the caches in one go that doesn't involve methods that go outside of Groundspeaks Terms and Conditions of use.

[gmj3191]

Use these date ranges for your PQs.

Period 01 Prior 12/08/2002
Period 02 13/8/2002 to 21/4/2003
Period 03 22/04/2003 to 1/11/2003
Period 04 2/11/2003 to 15/5/2004
Period 05 16/5/2004 to 27/9/2004
Period 06 28/9/2004 to 7/1/2005
Period 07 8/1/2005 to 26/3/2005
Period 08 27/3/2005 to 13/6/2005
Period 09 14/6/2005 to 21/8/2005
Period 10 22/8/2005 to 20/10/2005
Period 11 21/10/2005 to 3/1/2006
Period 12 4/1/2006 to 13/2/2006
Period 13 14/2/2006 to 26/4/2006
Period 14 27/4/2006 to 18/6/2006
Period 15 19/6/2006 to 10/8/2006
Period 16 11/8/2006 to 24/9/2006
Period 17 25/9/2006 to 14/11/2006
Period 18 15/11/2006 to 4/1/2007
Period 19 5/1/2007 to 10/2/2007
Period 20 11/2/2007 to 24/3/2007
Period 21 25/3/2007 to 30/4/2007
Period 22 1/5/2007 to 11/6/2007
Period 23 12/6/2007 to 21/7/2007
Period 24 22/7/2007 to 1/9/2007
Period 25 2/9/2007 to 12/10/2007
Period 26 13/9/2007 to 9/12/2007
Period 27 10/12/2007 to 23/1/2008
Period 28 24/1/2008 to 24/2/2008
Period 29 25/2/2008 to 3/4/2008
Period 30 4/4/2008 to 7/5/2008
Period 31 8/5/2008 to 19/6/2008
Period 32 20/6/2008 to 19/7/2008
Period 33 20/7/2008 to 19/8/2008
Period 34 20/8/2008 to 31/12/2008

[gmj3191]

Using these Pocket Queries will get the job done in a week if you don't wait too long. In a few weeks P34 will reach 500 and will need to be terminated earlier, and you'll need to add a P35.

The early ones are much less than 500. I may recalculate these soon to be closer to 500 once I know how many archived caches are not included now. This will allow fewer PQs to be used and extend the life of this method to download them all in a week for a bit longer.

[bshwckr]

Cheers everyone. A lot of thought has gone into that.
bshwckr

[gmj3191]

Here is my optimised set of PQs.
Pocket .Query .#...Start .Date.................... .End .Date.......... .No .Of .Caches


1...................... 18/05/2000.................... .28/09/2002.................... .497

2.................... .29/09/2002.................... .10/07/2003.................... .500

3.................... .11/07/2003.................... .5/03/2004.................... .495

4.................... .6/03/2004.................... .28/08/2004.................... .498

5.................... .29/08/2004.................... .6/01/2005.................... .499

6.................... .7/01/2005.................... .3/04/2005.................... .498

7.................... .4/04/2005.................... .16/07/2005.................... .490

8.................... .17/07/2005.................... .24/09/2005.................... .489

9.................... .25/09/2005.................... .18/12/2005.................... .497

10.................... .19/12/2005.................... .17/02/2006.................... .494

11.................... .18/02/2006.................... .3/05/2006.................... .498

12.................... .4/05/2006.................... .2/07/2006.................... .496

13.................... .3/07/2006.................... .25/08/2006.................... .498

14.................... .26/08/2006.................... .11/10/2006.................... .495

15.................... .12/10/2006.................... .3/12/2006.................... .495

16.................... .4/12/2006.................... .14/01/2007.................... .496

17.................... .15/01/2007.................... .23/02/2007.................... .499

18.................... .24/02/2007.................... .8/04/2007.................... .486

19.................... .9/04/2007.................... .19/05/2007.................... .480

20.................... .20/05/2007.................... .30/06/2007.................... .469

21.................... .1/07/2007.................... .4/08/2007.................... .482

22.................... .5/08/2007.................... .16/09/2007.................... .500

23.................... .17/09/2007.................... .4/11/2007.................... .492

24.................... .5/11/2007.................... .28/12/2007.................... .484

25.................... .29/12/2007.................... .2/02/2008.................... .492

26.................... .3/02/2008.................... .8/03/2008.................... .489

27.................... .9/03/2008.................... .14/04/2008.................... .491

28.................... .15/04/2008.................... .20/05/2008.................... .492

29.................... .21/05/2008.................... .1/07/2008.................... .496

30.................... .2/07/2008.................... .31/07/2008.................... .492

31.................... .1/08/2008.................... .31/08/2008.................... .495

.32.................... .1/09/2008.................... .31/12/2008.................... .218 .on .17/9/2008

For my next trick I need to learn how to improve my formatting skills in HTML this processor recognises !! My apologies.

[If]

I've done a few mystery caching tours of Oz meself
I used the cache ranges as described previously to set up the files for my GPS and PDA before I left home.
Once on the road I set up the PQ's to send me only new caches. One PQ for each state. I didn't recieve any updates on caches hidden before my holiday, but when I got on line occasionally I did recieve all the new caches hidden in the last week or so
Don't forget, you can use dates in the future

[gmj3191]

After rebuilding your database using the above PQs, you have two more steps to do if you want to use the stats macro to update your GC profile correctly.

1. You need to run the My Finds PQ to get all your found caches and your logs, including any archived caches you've found. The other PQs will only return 20 logs so your lfind ogs might not have been retrieved.

2. You need to run the AddLogs macro to get all the logs for each of your own caches. This gets you the finds by other people of your caches.

Once you've done this, you can run the stats upload macro to produce your report and upload it to your GC profile.

[gmj3191]

The reason the numbers in these PQs vary is because on the last day there will be a number of caches placed, and the ones on the following day will blow the 500 limit, so we need to go with a last day giving 500 or fewer.

A couple finish exactly on 500.

You might find a few less than the quoted number of caches in some periods because my file included a few archived caches which needed to be loaded because I had found them while they were active. They will be missing from your PQ runs.

[gmj3191]

Things have moved on a bit since the last posts in this thread.
With PQs being enhanced to deliver up to 1,000 caches per PQ, that enabled us to get
5,000 per day, or 35,000 per week. (Actually a little less because you usually had to settle for 970 or so per PQ because the next day in the range made the PQ blow the 1,000 cache limit.)
The GC.com API made it easy for GSAK to download these PQs each day.
I had been doing this and had 5 PQs running every day, but we exceeded 35,000 caches in Australia recently and so exceeded the capacity of this method to download every cache each week.
I then started deleting the PQs for the oldest caches and creating new ones to get the most recent caches.
This meant the older caches were no longer being updated by the PQ method.

I got around that by using GSAK to filter out unarchived caches that had a last GPX date older than a week, then using the API Refresh Cache Data option to get these caches updated. The limit on this is 6,000 per day.
Soon I'll have to change my PQs to report caches in placed date ranges which were updated in the last week only, rather than all caches, but this could mean archived caches slip through my net.
I think at some point, I will have to just specialise in Victorian caches and perhaps other cachers who are anal about their database could do their own states and we could swap GPX files occasionally.

Another option would be to continue with PQs based on placed dates for the current year to catch all new caches, and then manually update 6,000 per day for the oldest 42,000 caches.

Interesting problem isn't it.

[crew 153]

I run my PQ's to only select caches which have been updated in the last 7 day. For most states this requires 3-4 PQs set to date ranges to give me approx 700 caches in each to allow for variations and holidays.

I then import these into GSAK using a macro which checks for caches which have added 5 new logs. These are filtered and then I use the API to get recent logs set to the last 60 logs.

This seems to be working for me. I also import these PQ into GCA to take some load off the fairies.

[roundcircle]

... I had been doing this and had 5 PQs running every day, but we exceeded 35,000 caches in Australia recently and so exceeded the capacity of this method to download every cache each week.
.

You could just put up the $ for a second account.

[CraigRat]

This seems to be working for me. I also import these PQ into GCA to take some load off the fairies.

Thanks, seroiusly, it is appreciated/
If more people did this it would help us tremendously!

The faeries are going poor at this rate.
Even better, hide more GCA caches and help us save money!!

[Richary]

Thanks, seroiusly, it is appreciated/
If more people did this it would help us tremendously!

The faeries are going poor at this rate.
Even better, hide more GCA caches and help us save money!!

CraigRat, it's always been a bit of a mystery to the great unwashed like myself how GCA gets the feed as the method has always been reasonably secretive. I assume it is by people uploading PQs.

Like many others I would be happy to assist if I was told how I could. Most weeks I get all NSW & ACT in my PQs for personal use (work can require me to travel with little notice between Newcastle, Canberra, Nowra) so it's useful to have the data ready to go. These normally come down Wednesday and Thursday nights for me, but the other days of the week are free of queries unless I have an interstate/overseas work trip coming up. If I can assist let me know.

I am guessing you don't want everyone uploading the same PQs every day though!

[CraigRat]

The ways of the feed are indeed mysterious, but whenever someone uploads logs, no matter how frequent or infrequent, helps us immensely

It's almost impossible for us to have a 100% accurate set of logs, there's always holes here and there.

Anything you do helps us and helps your site.