Geocaching Australia

http://gsak.net/board/index.php?showtopic=19095

2. V8 final *will* be a chargable upgrade from V7.

OOOOHHHHH, I think I'm in love!

Hmmm. If ver 7 keeps working for me not sure why I would upgrade. Unless 7 becomes not supported so it stops working if GC change their GPX formats in the future.

V8 uses the API to get stuff straight from GC.
I think I like that.
Haven't tried it though.

Richary wrote:Hmmm. If ver 7 keeps working for me not sure why I would upgrade. Unless 7 becomes not supported so it stops working if GC change their GPX formats in the future.

Sorry Richary, I should have explained my joy. Have a look at this here

A full FAB list is here

I downloaded it last night but decided the queue was more important so didn't get a chance to play.

phwoar.... I'd pay for that API stuff - managing the increasing list of pocket queries to cover all caches in Victoria is annoying enough that I'd pay to stop doing it. Although it looks like you might still need a pocket query for new caches if you want the whole state/country (since the get geocaches feature will only do 50km radius, unless you can somehow configure that to cover an entire state/area) but then the old ones could be maintained through the API (that's my understanding so far)...

Either way I do like that feature

I've used my lunchtime to download it and play - ok, i'll probably use the whole afternoon. It's Friday, so heck...

So far so good. Hit the 'get geocaches' button and got a cheap little thrill when it brought up the GC window asking for my details. Upload is slow so I abandoned after a hundred or so caches to have a peek.

New interface is nice, and the caches and logs come in very nicely. Much improved layout with nice map structure, etc. Then ran the 'refresh cache data' on it (not that I expected much change in 2 minutes) and it ran smoothly. All looking really good so far! The system's now churning in the background bringing down as many caches as it will let me...

*an hour or so later* (Yep, no 'real' work getting done)
Did a little write up: http://cachechism.blogspot.com/2011/08/ ... eased.html

Hmmm I'll have to rethink my whole strategy now.
I keep a GSAK database of all active caches in the country, because...because ... because I can.
I currently run 33 PQs each week to do this,
plus another 2 PQs looking at inactive caches which allows me to detect and eliminate archived caches which I haven't found, and keep temporarily archived caches in order.

I was just about to go through and rebalance the dates to allow this scheme to keep going a little going a little longer since I'm currently running the max number of PQs per week.

I might now just fall back to a state based system, but I hate giving up data.
I love running filters just for the fun of it to see how many mystery caches were placed in WA on Ned Kelly's birthday, or that
there are precisely 29,983 active caches in Australia, and another 1,040 temp unavailable caches, accurate to within the few days.

I can't wait to have a look at it, so off I go now ......

gmj3191 wrote:Hmmm I'll have to rethink my whole strategy now.
I keep a GSAK database of all active caches in the country, because...because ... because I can.
I currently run 33 PQs each week to do this,
plus another 2 PQs looking at inactive caches which allows me to detect and eliminate archived caches which I haven't found, and keep temporarily archived caches in order.

I was just about to go through and rebalance the dates to allow this scheme to keep going a little going a little longer since I'm currently running the max number of PQs per week.

I might now just fall back to a state based system, but I hate giving up data.
I love running filters just for the fun of it to see how many mystery caches were placed in WA on Ned Kelly's birthday, or that
there are precisely 29,983 active caches in Australia, and another 1,040 temp unavailable caches, accurate to within the few days.

I can't wait to have a look at it, so off I go now ......

If you've got that database already established (sounds awesome! I have enough trouble keeping Vic in check!) then I reckon it shouldn't be too hard, especially once the macro experts start getting creative.

It all depends on whether the 'status check' and 'refresh cache data' features are radius limited like the 'get geocaches' feature. If not then it shouldn't be too hard to break them up into small enough sections and get them updated regularly (assuming a 2000 cache update limit, which I'm not even sure about). And then one pocket query to find all the new caches that might have appeared weekly.

WOW
The status check will go away and check the status of all caches in a filter.
This will need to be used wisely, or could create problems I suspect.
I ran it on all temporarily unavailable caches within 35 km and it ran in a flash, and updated the statuses.
Fantastic.

I have discovered that the status check will pause for one minute if the API limit is exceeded, and then starts up again.
This seems to be the way that long API calls can be processed without degrading the system.
Very good. It looks like you can run a status check, say, on a state, go have a coffee, and let it run with regular pauses until it finishes.
Nice solution.

um...I think this means we can get our PQs quicker and easier into GSAK? I hope there are some very easy instructions eventually

Oh, it's easy alright.

Geocaching.com access tab
Download Pocket Queries.
Select the ones you want.
Hit go.
Downloads and done.

Just grabbed the entire state using the API. Nice.
It runs about 1.2 caches a second (that's what I'm getting) or about 80 caches a minute.
PQ's are faster as they are canned on the server, but it's still a nice touch.

Just curious - if it uses the API to get the data direct from the server to update caches you already have in GSAK - does that mean you can now automatically get the data for archived caches that don't appear in PQs?

On the downside, I am guessing that a call per cache is going to have an impact on your data usage, with more upload for the request and then the download (especially if it isn't compressed). Just something you may need to consider if you have a data plan with a not very big data limit. That's speculation though, someone with a bit more programming knowledge could probably comment.

I think the answer to 1 is yes, but not evidence.
Text is pretty small with up to 30 logs, so might be a challenge.
Probably 10MB or so to get a states worth (maybe, I dunno, I made that up).