Sunday, March 18, 2012

Creating Pocket Queries With GSAK



As regular readers will know, I’m a big fan of a piece of software called the Geocaching Swiss Army Knife (or GSAK) and recommend it to any serious geocacher.  At its most basic, it’s a database for geocaches which you can use to generate advanced find statistics.  But its flexibility means you can do a lot more with it, from speeding up your cache logging through the use of templates, to planning a day out.

One of the great things about GSAK is uncovering these really powerful, time-saving features that make geocaching less about administration and planning, and more about going out there and finding Tupperware. 

Recently, when trying to do a Pocket Query (also known as a PQ) for a day out geocaching, a friend highlighted that there is a simple way to do this in GSAK.  And since trying their advice, I doubt I’ll ever go back to the old way. Of downloading my PQ and then manually importing into GSAK

This quicker way of getting geocaches into GSAK is simple but requires a premium account as it utilises the Live API.  If you’ve not done it already you’ll need to set up an access token to allow GSAK to talk to and swap data.  If you followed my article from last year on logging geocaches with GSAK  then you should have already done this.  If not, that article tells you what to do.  It’s a quick one-time setup that will open up a number of GSAK features to you.

If I’m planning to go out caching for the day and am looking to run a Pocket Query, I’ll often spend a lot of time looking at the map view trying to find the geocache most central to the area I plan to go geocaching.  Once I’ve selected it, it’s then a case of finding out the GC reference code and using that in my Pocket Query – searching for everything for a set number of miles radiating out from this central geocache.  It’s not the most difficult process in the world but it can sometimes be frustrating if the browser plays up when trying to copy and paste the GC number or when selecting the geocache to view the details (and the GC reference code).

menuUsing GSAK, I don’t have to worry about this. From the menu I select ‘ Access’ and then ‘Get Geocaches’ to get a pop up window with a variety of search criteria.  By clicking on the button that says “Google Map” I get a second pop-up window which I use to drag my target across the map to my central location and get GSAK to return the co-ordinates.  I find this so much simpler.  Not only do I not need to spend time finding out and copy and pasting codes, but it means I can now centre my Pocket Query on a location that doesn’t necessarily have a geocache.

mapHow many times have you logged onto, created a Pocket Query and then waited for what seems like ages for your Pocket Query to be created?  If you’re impatient like me, you’ll probably not even wait for the email notification, instead constantly refreshing the page.  And it always seems those times when you’re especially in a hurry that the system seems to run particularly slow in creating your Pocket Query.

Even when your Pocket Query is sitting there waiting for you, you need to download it, open GSAK and then import it.  Using the API it does this all for you.  Once you click submit then the API will whirl into action.  It will connect to, run your query, bring back the geocaches and load them directly into GSAK.  And best of all, you can go off and do other things whilst it does it as it requires no user interaction.

3The standard Pocket Query will return up to 1000 geocaches at a time.  That’s more than enough for any geocacher.  My trouble is that if I plan to cache in a couple of separate locations, or along a route, I either need to spend time creating the Pocket Query on, or run a couple of Pocket Queries.  All too often my initial query comes in at slightly over the maximum.  There’s tricks I can do, such as ignoring certain cache types or difficulty ratings I’m unlikely to do, but there’s always a worry that I’ll somehow miss off a geocache I’ll be going past.  Experience has taught me that having too many geocaches on my GPSr is far better than too few.  In the past I’ve excluded puzzle caches only to find that the great big series I’ve just completed has a bonus geocache at the end which I have no details for.

1So for me, at least, the more geocaches a Pocket Query returns the better.  The API can return up to 2000 geocaches at a time.  And you can repeat the process to deliver up to 6000 geocaches daily.  That means populating your GPSr for a weekend away is a much simpler and much quicker process.

Like any new process it sometimes takes a few goes to get the hang of it, but try it next time you need to create a Pocket Query.  I find it a lot easier and I hope you will too.

About Adrian Faulkner

Adrian Faulkner is a writer of both fiction and non-fiction. He is an active geocacher with over 9000 finds to his name. You can find more by Adrian at and on his Google Plus page.


  1. Brian Lang says:

    I just tried this process and told it to gather 5000 geocaches. I selected the rectangle method, and asked for 5000 geocaches. It returned 4767 in the area I selected. If you’re interested, the coordinates for the rectangle were 49.412522,-123.294769 and 49.001426,-122.092094

    I found this to be very useful. It also excludes your finds by default, so you’re pulling down only unfound caches. You can of course override and pull down your finds if you so choose.

    There is one drawback that I found. If you want the FAV points for the caches you downloaded, you need to “Refresh cache data…” from the “ access” menu. This will use up more of your daily API budget, so keep that in mind if you want to pull caches for a large area. In my case, I cannot download the FAV points until tomorrow since my 6000 cache budget is down to around 1200 remaining. No big deal, but something to keep in mind if you want to filter your database by number of FAV points.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!


five × 8 =