Gsak And Archived/unavailable Caches

[+MaisOui & Avrohead]

I'm having some trouble with Gsak not listing some archived/unavailable caches as such. I found this out after spending an hour at a 4 terrain cache. When I got home, guess what? It's been archived for months! This prompted me to check other caches in Gsak. I found quite a few. Has anyone else experienced this? At first I thought maybe I was missing a setting. My wife (Maisoui) said it was an "RTFM" error.

 

Help! I want to trust my Gsak again!

 

Avrohead

[+fizzymagic]

I'm having some trouble with Gsak not listing some archived/unavailable caches as such. I found this out after spending an hour at a 4 terrain cache. When I got home, guess what? It's been archived for months! This prompted me to check other caches in Gsak. I found quite a few. Has anyone else experienced this?

This behavior is by design. GSAK is written in such a way that it encourages you to use stale data. That's because pocket queries don't contain archived caches. I don't think there is any easy way to fix it. There are a couple of algorithms that could be used to identify most of them, but the basic problem is in the design of GSAK.

 

Some people seem to think that Geocaching.com should change the way pocket queries are done to make up for the deficiencies of GSAK in this regard; I don't think that is likely to happen any time soon.

Edited March 9, 2006 by fizzymagic

[+cron]

Huh? Make a pocket query for the disabled caches in your area and load it into GSAK every week. That way, you're sure not to get out for nothing...

[+Olar]

Huh? Make a pocket query for the disabled caches in your area and load it into GSAK every week. That way, you're sure not to get out for nothing...

That's fine as long as the cache goes from "active" to "temporarily unavailable" before being archived. Gc.com PQ's will include the info to indicate temp unavailable but will not for archived. If a cache goes directly to archived then GSAK has no way of knowing about it. It thinks the cache is still active.

What you can do is occasionally sort your list of caches in GSAK by the "last GPX" date. Any that do not have a current date (as of your most recent PQ) very likely has been archiived. It means looking at each cache listing to verify but once you've done them all then it only takes a few minutes each week or two to keep your list up-to-date.

 

Olar

[+MaisOui & Avrohead]

What you can do is occasionally sort your list of caches in GSAK by the "last GPX" date. Any that do not have a current date (as of your most recent PQ) very likely has been archiived. It means looking at each cache listing to verify but once you've done them all then it only takes a few minutes each week or two to keep your list up-to-date.

 

Olar

I'll do that. Thanks for the tip!

 

Avrohead

[+ZackJones]

This behavior is by design. GSAK is written in such a way that it encourages you to use stale data. That's because pocket queries don't contain archived caches. I don't think there is any easy way to fix it. There are a couple of algorithms that could be used to identify most of them, but the basic problem is in the design of GSAK.

 

Would you care to elaborate on why GSAK encourages us to use stale data? I can see how data can get stale for archived caches only but it's quite easy to keep GSAK current with two PQ's per week. I would also be interested to find out more about the algorithms that could help us keep GSAK current.

[+The Jester]

 

This behavior is by design. GSAK is written in such a way that it encourages you to use stale data. That's because pocket queries don't contain archived caches. I don't think there is any easy way to fix it. There are a couple of algorithms that could be used to identify most of them, but the basic problem is in the design of GSAK.

 

Some people seem to think that Geocaching.com should change the way pocket queries are done to make up for the deficiencies of GSAK in this regard; I don't think that is likely to happen any time soon.

Your anti-GSAK stand is well known, but it should be noted that it is an OPTION ONLY! How a program is "Deficient" because it can not use data that it doesn't have is a very interesting thought. And seeing how you can check one little box on the Load GPX command that totally prevents "stale data" (clear DB before load) seems to have completely gone over your head - it also doesn't allow you to see any more than 5 logs which can limit the help of new co-ords posted and other help/hints.

 

I do agree with one of your statements - "This behavior is by design" - but that is GC.com's design, not GSAK's. I've had this problem (hunting caches that were archived) long before I used GSAK or went paperless. When I started caching, using print-outs, I also ran into caches archived between printing and hunting (a few times printed morning, hunt in afternoon, archived at noon). I just don't see how GSAK caused those problems...

[+baloo&bd]

I'm having some trouble with Gsak not listing some archived/unavailable caches as such. I found this out after spending an hour at a 4 terrain cache. When I got home, guess what? It's been archived for months! This prompted me to check other caches in Gsak. I found quite a few. Has anyone else experienced this? At first I thought maybe I was missing a setting. My wife (Maisoui) said it was an "RTFM" error.

 

Help! I want to trust my Gsak again!

 

Avrohead

 

The easiest way to handle this, assuming you have your PQ's scheduled on a regular, weekly basis, is to set up a filter in gsak to look for all caches unfound caches with a GPX older than 7 days.

 

When you recieve your pocket query or queries, load them then run this filter. Anything that comes up in the filter, delete. By doing it older than 7 days, if you have queries set to run every day, the filter won't give any false positives. This will also allow you to keep the ones that are just marked unavailable in your DB since they are included in the pocket queries.

 

This helps cover any deficiencies in the PQ's.

Edited March 9, 2006 by baloo&bd

[+Miragee]

Huh? Make a pocket query for the disabled caches in your area and load it into GSAK every week. That way, you're sure not to get out for nothing...

That's fine as long as the cache goes from "active" to "temporarily unavailable" before being archived. Gc.com PQ's will include the info to indicate temp unavailable but will not for archived. If a cache goes directly to archived then GSAK has no way of knowing about it. It thinks the cache is still active.

 

What you can do is occasionally sort your list of caches in GSAK by the "last GPX" date. Any that do not have a current date (as of your most recent PQ) very likely has been archiived. It means looking at each cache listing to verify but once you've done them all then it only takes a few minutes each week or two to keep your list up-to-date.

 

Olar

That is what I have finally learned to do. GSAK can't help it that Archived caches are not included in the PQs. It cannot do anything with data it doesn't receive.

 

Checking the date of the "last update .gpx" is the only way to identify caches that go from Active to Archived in one step.

 

Now, after doing the "Last 2 DNF" filter, I do the "last update .gpx" filter.

 

It has taken me a year to figure that out . . .

[+fizzymagic]

Your anti-GSAK stand is well known, but it should be noted that it is an OPTION ONLY! How a program is "Deficient" because it can not use data that it doesn't have is a very interesting thought.

I ordinarily wouldn't respond, but this calls for it. I am in no way anti-GSAK. I think it is a fantastic program when used properly, and I think Clyde has done a superb job with it. If I am anti-anything, I am anti-GSAK users who think the world should revolve around them.

 

That said, no software application is perfect, and, IMO, there is a problem with GSAK that it doesn't warn you when you are using stale data. It's true that geocaching.com doesn't make that easy, but (as others have pointed out) it is by no means impossible.

[+baloo&bd]

That said, no software application is perfect, and, IMO, there is a problem with GSAK that it doesn't warn you when you are using stale data. It's true that geocaching.com doesn't make that easy, but (as others have pointed out) it is by no means impossible.

 

This is not a true statement. GSAK does not autonatically alert if you mean that it says "hey, this data is out of date" however, that is subjective. Data being out of date in the rural areas of New Mexico is different from data being stale in downtown Chicago.

 

GSAK deals with this by monitoring when you last recieved a updated GPX file. Executing a simple filter or Macro allows you to see anything that has not been updated since a given date.

 

Other than having a live interface between GSAK and GeoCaching.com, which is against GC policies and expressly prohibited, how would you suggest the program be altered to "warn you when you are using stale data"?

[+fizzymagic]

Other than having a live interface between GSAK and GeoCaching.com, which is against GC policies and expressly prohibited, how would you suggest the program be altered to "warn you when you are using stale data"?

GSAK knows perfectly well when data is stale; for each cache in the database, it knows when it last downloaded information about it. (Note: this has nothing to do with when the cache was last found!) If your last PQ was yesterday and the last time it received information about a cache was a week ago, then its data on that cache is stale. Recall that the OP in this thread had absolutely no idea that GSAK could not magically delete archived caches from its database of active caches. Don't you think that is a problem?

 

There was a long thread several months ago in which I showed several algorithms that could be used to identify archived caches. I am not even close to being interested in going over it all again. The search function in the forums is working again, so I expect you can find it.

 

One almost completely trivial solution would be when GSAK exports the cache for use by Plucker or whatever, it adds a note to the top of any caches for which its data is stale. Something like this:

 

Warning: data has not been recceived for this cache in over 1 week. The cache could be disabled or archived.

 

There are also completely legal ways that people could work together to maintain a database of archived caches. Sharing the waypoint names of caches that have been archived in no way violates the GC TOS; in fact, given GC's intransigent stand on refusing to include such caches in PQs, I would say that they have forfeited any rights they have dissemination of data on the state of those caches.

 

It's abundantly obvious that GC is not interested in helping people maintain extensive offline databases of caches. While you and I may not like it, that is their business model and it's not going to change. In my opinion (and it's only an opinion), any software (or, more to the point, software user) that doesn't accommodate itself to that reality is flawed.

Edited March 9, 2006 by fizzymagic

[+ZackJones]

I have a solution. Create a pinned topic in each of the regional forums and everytime a cache is archived a new post is automagically added to that pinned topic showing the GCXXXX code and date the cache was archived.

 

There's no need to create a PQ of archived caches, which Groundspeak has made it clear they will not do and those of us that happen to maintian lists of caches offline can keep our lists current.

[+blindleader]

I'm not interested in a flame war about what GSAK should and shouldn't do, so I'll just offer the simple work-around.

 

Make a filter that matches the PQ.

When you update the database with the PQ, run the matching filter

Sort on the Last GPX field.

Now the stale caches will be at the top and you can either update or delete them. (I don't know why anyone would delete a record from a database, but that's another rant entirely.)

 

I maintain a database of all (Over 5,000 active) physical caches within a 100 mile radius, using a series of PQs that run throughout the week. Works like a charm and only takes a few minutes each day to update the far fewer than ten newly archived caches that pop up.

[+Intermountain Angler]

I'm not interested in a flame war about what GSAK should and shouldn't do, so I'll just offer the simple work-around.

 

Make a filter that matches the PQ.

When you update the database with the PQ, run the matching filter

Sort on the Last GPX field.

Now the stale caches will be at the top and you can either update or delete them. (I don't know why anyone would delete a record from a database, but that's another rant entirely.)

 

I maintain a database of all (Over 5,000 active) physical caches within a 100 mile radius, using a series of PQs that run throughout the week. Works like a charm and only takes a few minutes each day to update the far fewer than ten newly archived caches that pop up.

 

I like your idea on the get around, I am with you why delete parts of a data base, having never set up a filter i would appreciate some help in the way of some detailed instructions on how you did this

Thanks

[+The Jester]

The main PQ's I use are distance based from my house. So I use a macro that checks for un-updated caches within the range of the PQ:

FILTER Name="User Flag Set"
SORT By="Distance"
GOTO Position=bottom
SET $DistOut=$d_Distance
CANCELFILTER
MFILTER IF=($d_Distance<=$DistOut) .and. .not. ($d_TempDisabled .or. $d_Archived) .and. .not. ($d_UserFlag)

The only problem I have with it, is currently I have a puzzle cache with corrected co-ords well outside the PQ limit, so this macro shows caches out to that distance. It also doesn't track disabled caches that are then archived, but they are already marked unavailable so I never load them.