Pocket Query problem re: archived caches

[+GoBlue!]

I'm using GSAK, and have just noticed that when I drop in my latest pocket query results, caches that have been archived (NOT temporarily inactive) don't get changed to an archived status.

 

It doesn't seem to be a GSAK problem -- I just created a PQ 20 mi from my home coordinates with only the "is not active" filter on. It only generated 8 results, all of which were temporarily disabled. Some of the caches that have been archived did NOT show up.

 

So, I think that when a cache goes from active to archived, it just disappears from my PQ list and GSAK doesn't see that it's "status" has changed.

 

How can I get around this?

 

Thanks,

Jim

[+Prime Suspect]

I'm using GSAK, and have just noticed that when I drop in my latest pocket query results, caches that have been archived (NOT temporarily inactive) don't get changed to an archived status.

 

It doesn't seem to be a GSAK problem -- I just created a PQ 20 mi from my home coordinates with only the "is not active" filter on. It only generated 8 results, all of which were temporarily disabled. Some of the caches that have been archived did NOT show up.

 

So, I think that when a cache goes from active to archived, it just disappears from my PQ list and GSAK doesn't see that it's "status" has changed.

 

How can I get around this?

 

Thanks,

Jim

The PQ gave you what you asked for. "Is not active" means Disabled, not Archived. PQs are for generating caches to look for, so why would it include archived caches?

 

And it if did include archived caches, it would either have to send ALL archived caches that fit the other criteria, EVERY TIME, or there would have to be some sort of mechanism where the system would have to track every archived cache, and who it had been out to. I don't see PQs being changed in order to accommodate one piece of software that chooses to use PQs in a manner they were never designed for.

[+Stunod]

I'm using GSAK, and have just noticed that when I drop in my latest pocket query results, caches that have been archived (NOT temporarily inactive) don't get changed to an archived status.

 

It doesn't seem to be a GSAK problem -- I just created a PQ 20 mi from my home coordinates with only the "is not active" filter on. It only generated 8 results, all of which were temporarily disabled. Some of the caches that have been archived did NOT show up.

 

So, I think that when a cache goes from active to archived, it just disappears from my PQ list and GSAK doesn't see that it's "status" has changed.

 

How can I get around this?

 

Thanks,

Jim

 

You can run a filter on the LAST GPX field in GSAK to find those caches that were not updated on your last set of PQ's....these caches have been archived (or are now outside the 500 closest caches).

Edited February 3, 2007 by Stunod

[+wsgaskins]

You can run a filter on the LAST GPX field in GSAK to find those caches that were not updated on your last set of PQ's....these caches have been archived (or are now outside the 500 closest caches).

 

Yep, this is the only way around this in GSAK.

 

I just recently setup my PQs to give me caches by a certain 'date placed' range, all with the same center and radius. Since new caches will never appear in some PQs (because they cannot be "placed" in the past), so if I load the PQ and there are caches that do not get updated in the database that should fall in the PQ's date placed range, then they *must* be archived. This avoids the problem of having caches just fall out of your radius or max # of caches and get stale without having been archived.

 

The trick with this system of PQs is that it takes a bunch of PQs to get a good radius and still pickup all the caches in my area. Plus I had to tweak the date ranges on them to get close to the max # (500) of caches that a PQ will deliver.

[+GoBlue!]

Thanks for the tips. I'll give it a try.

 

Jim

[+TheAprilFools]

One of my great wishes is for a PQ option that would include all caches that have been modified in the last week, this would include changes in the description and changes of the status from available to archived.

[Mushtang]

It would be great if the site would include the GC numbers of caches archived in the last week (if you make that selection while building the query), but leave out EVERYTHING else. No description, no coordinates, etc. That way, third party programs could eliminate them from offline databases while still updating everything else.

 

I'm sure this won't happen though, because I've read a few times where TPTB say that offline databases isn't something they want to support. They'd prefer you dump all old data when you get the new PQ.

 

But they won't allow more than 5 logs in PQs and sometimes that's not enough.

[+globalgirl]

You can run a filter on the LAST GPX field in GSAK to find those caches that were not updated on your last set of PQ's....these caches have been archived (or are now outside the 500 closest caches).

Yep, this is the only way around this in GSAK.

 

I just recently setup my PQs to give me caches by a certain 'date placed' range, all with the same center and radius. Since new caches will never appear in some PQs (because they cannot be "placed" in the past), so if I load the PQ and there are caches that do not get updated in the database that should fall in the PQ's date placed range, then they *must* be archived. This avoids the problem of having caches just fall out of your radius or max # of caches and get stale without having been archived.

 

The trick with this system of PQs is that it takes a bunch of PQs to get a good radius and still pickup all the caches in my area. Plus I had to tweak the date ranges on them to get close to the max # (500) of caches that a PQ will deliver.

O.k. let me get this straight. I too have my weekly PQ's set up for all w/in a set radius by date placed (in the case of the dense Emerald City, that makes 6 PQ's for a mere 20 mile radius!) but...

 

I presume you mean to filter them via the "Date" tab in GSAK, setting the "Last update GPX" for any before the last PQ update, yes? But... that doesn't seem to work (it leaves me w/ nearly 300 caches - out of nearly 2000 - none of which are the least bit archived). I'm guessing it doesn't work 'cuz that filter also catches those caches that for whatever reason, haven't had a new log or nuthin' since the last weekly PQ, no? Maybe I should use a 1 week "between" dates for the filter? Naw, then too, caches that hadn't had a new log (but aren't necessarily archived) would be caught in the filter.

 

Probably missing something really ("well, duhhh!") obvious here, but just trying to get this straight 'cuz I too would love a reasonably easy, yet foolproof method of ensuring that I nix archived caches from my GSAK database. I might also add... that gc.com doesn't supply a simple PQ mechanism for such is most disappointing.

[Keystone]

Is there a GC.com feature request somewhere in this thread? From reading the posts, it seems more like a GSAK "how to" issue that has been addressed previously in the support forums at gsak.net. Perhaps the conversation is best carried on over there.

[+GoBlue!]

Is there a GC.com feature request somewhere in this thread? From reading the posts, it seems more like a GSAK "how to" issue that has been addressed previously in the support forums at gsak.net. Perhaps the conversation is best carried on over there.

 

I count two feature requests:

 

1.

One of my great wishes is for a PQ option that would include all caches that have been modified in the last week, this would include changes in the description and changes of the status from available to archived.

 

2.

It would be great if the site would include the GC numbers of caches archived in the last week (if you make that selection while building the query), but leave out EVERYTHING else. No description, no coordinates, etc. That way, third party programs could eliminate them from offline databases while still updating everything else.

 

My original post happened to include that I am using GSAK, but it was more of a confusion about how the PQ worked.

 

Jim

[+Lil Devil]

I count two feature requests:

 

1.

One of my great wishes is for a PQ option that would include all caches that have been modified in the last week, this would include changes in the description and changes of the status from available to archived.

Jeremy has previously stated that archived caches will never be included.

 

2.

It would be great if the site would include the GC numbers of caches archived in the last week (if you make that selection while building the query), but leave out EVERYTHING else. No description, no coordinates, etc. That way, third party programs could eliminate them from offline databases while still updating everything else.

Not including that information would yield an invalid GPX file and GSAK and other programs wouldn't be able to read it anyways.

 

As others have already pointed out, there are existing methods to get the info you want. Adding it to the PQ would be 1) a hack, 2) superfluous, and 3) not needed by the majority of GPX users.

Edited February 4, 2007 by Lil Devil

[Mushtang]

I count two feature requests:

 

1.

One of my great wishes is for a PQ option that would include all caches that have been modified in the last week, this would include changes in the description and changes of the status from available to archived.

Jeremy has previously stated that archived caches will never be included.

True. I even said as much in the portion of my post that didn't get quoted below. But it's still okay to ask from time to time isn't it? People do sometimes reconsider, or maybe their reasons for not wanting to do something change, and then later they allow it.

 

2.

It would be great if the site would include the GC numbers of caches archived in the last week (if you make that selection while building the query), but leave out EVERYTHING else. No description, no coordinates, etc. That way, third party programs could eliminate them from offline databases while still updating everything else.

Not including that information would yield an invalid GPX file and GSAK and other programs wouldn't be able to read it anyways.

I think if this were the solution that bypassed the reasons TPTB were saying no (they didn't want to send out coords for caches that weren't there), they could figure out how to make it work. For instance, for my PQ the site could strip out all the info for archived caches, except the GC number, and then fill it back in with specific info to indicate it's archived. The coords could be filled in with all zeros, and the description could be replace with a string of 13 zeros. Third party programs would know to look for this and treat them as archived caches, removing them from databases. Just because the coords 00 00.000 00 00.000 aren't close to my house, doesn't mean the information wouldn't be useful as a flag in my PQ.

 

Unfortunately, I think there are probably other reasons the site wouldn't want to do this, since the guy that runs it is a lot smarter than I am, and surely would have done this by now if that's what the issue was.

 

As others have already pointed out, there are existing methods to get the info you want. Adding it to the PQ would be 1) a hack,

Not exactly sure what you mean. If the site sets up the PQs to have the option to include this information, I'd think it would be completely smooth.

 

2) superfluous

Not excessive or unnecessary at all. It would allow offline databases to prune out bad data, while keeping a history of logs longer than the 5 that are sent with PQs.

 

, and 3) not needed by the majority of GPX users.

What does that matter? The majority of GPX users needn't check the box that sends archived cache info. Do you really think the majority of GPX users receive PQs that contain APE caches? The box is there to check for that one. Do the majority of GPX users request a MyFinds PQ every week? That option exists too. What leads you to believe that majority rules on this website?

[+GoBlue!]

My intentions starting this thread were purely innocent. Not sure why it struck a nerve with some (nor do you need to explain). I'm fine letting it rest...there is clearly far more history here than I'm aware of.

 

Have a good day,

Jim

[+welch]

My intentions starting this thread were purely innocent. Not sure why it struck a nerve with some (nor do you need to explain). I'm fine letting it rest...there is clearly far more history here than I'm aware of.

 

Have a good day,

Jim

 

The *history* is just that requests for 'archived caches PQ'(or similar) come up often. It is a discussion that repeats itself often, sometimes with the exact same people.

I wouldn't worry about it, this won't be last time its asked

[+wsgaskins]

You can run a filter on the LAST GPX field in GSAK to find those caches that were not updated on your last set of PQ's....these caches have been archived (or are now outside the 500 closest caches).

Yep, this is the only way around this in GSAK.

 

I just recently setup my PQs to give me caches by a certain 'date placed' range, all with the same center and radius. Since new caches will never appear in some PQs (because they cannot be "placed" in the past), so if I load the PQ and there are caches that do not get updated in the database that should fall in the PQ's date placed range, then they *must* be archived. This avoids the problem of having caches just fall out of your radius or max # of caches and get stale without having been archived.

 

The trick with this system of PQs is that it takes a bunch of PQs to get a good radius and still pickup all the caches in my area. Plus I had to tweak the date ranges on them to get close to the max # (500) of caches that a PQ will deliver.

O.k. let me get this straight. I too have my weekly PQ's set up for all w/in a set radius by date placed (in the case of the dense Emerald City, that makes 6 PQ's for a mere 20 mile radius!) but...

 

I presume you mean to filter them via the "Date" tab in GSAK, setting the "Last update GPX" for any before the last PQ update, yes? But... that doesn't seem to work (it leaves me w/ nearly 300 caches - out of nearly 2000 - none of which are the least bit archived). I'm guessing it doesn't work 'cuz that filter also catches those caches that for whatever reason, haven't had a new log or nuthin' since the last weekly PQ, no? Maybe I should use a 1 week "between" dates for the filter? Naw, then too, caches that hadn't had a new log (but aren't necessarily archived) would be caught in the filter.

 

Probably missing something really ("well, duhhh!") obvious here, but just trying to get this straight 'cuz I too would love a reasonably easy, yet foolproof method of ensuring that I nix archived caches from my GSAK database. I might also add... that gc.com doesn't supply a simple PQ mechanism for such is most disappointing.

 

On the Pocket Query setup page, scroll all the way down to find (just below "radius" and just above "attribute icons"):

Placed during (o) None Selected

(o) the last week [v]

(o) between <month/day/year> and <month/day/year>

 

If you select the last option there 'between' and fill in 2 dates, then you can get your PQ to only return caches that were placed in that date range.

I've got a set of PQs with the date ranges all setup to be consecutive and all of them return close to the 500 cache max limit. So, now when I load one of these PQs into GSAK, if a cache that showed up *last time* I loaded it and it doesn't show up this time, then it must be archived.

I get all of these PQs only once a week, so by sorting my GSAK for 'Last GPX' I can see if a cache listing is more than 1 week old after I load that day's PQ.

 

Clearer now?

[+GoBlue!]

On the Pocket Query setup page, scroll all the way down to find (just below "radius" and just above "attribute icons"):

Placed during (o) None Selected

(o) the last week [v]

(o) between <month/day/year> and <month/day/year>

 

If you select the last option there 'between' and fill in 2 dates, then you can get your PQ to only return caches that were placed in that date range.

I've got a set of PQs with the date ranges all setup to be consecutive and all of them return close to the 500 cache max limit. So, now when I load one of these PQs into GSAK, if a cache that showed up *last time* I loaded it and it doesn't show up this time, then it must be archived.

I get all of these PQs only once a week, so by sorting my GSAK for 'Last GPX' I can see if a cache listing is more than 1 week old after I load that day's PQ.

 

So are you updating your "most recent" PQ each week to include the previous week's caches? This is an interesting approach I hadn't considered before (but a quick search shows me that this is a fairly common way to use PQs....)

 

Jim

[+Markwell]

Yep - you stack previous logs then as well. The archived ones will show up in the GSAK database, but have an older GPX date. Heck, you could keep an offline GSAK database of archived caches by just letting it contstantly add to the database, and when you're looking for non-archived caches, choose "with a GPX date >= x date".

[+wsgaskins]

My "Most Recent" PQ has a date placed range that ends in the future (Dec 31 2007 currently). But when that particular PQ hits 500 caches, then I can just go and set that one to end "yesterday" and start another one for current caches. I don't expect to have to do that too often, since I figure it takes a long time to get 500 caches placed within 100 miles of my house!

[+GoBlue!]

My "Most Recent" PQ has a date placed range that ends in the future (Dec 31 2007 currently). But when that particular PQ hits 500 caches, then I can just go and set that one to end "yesterday" and start another one for current caches. I don't expect to have to do that too often, since I figure it takes a long time to get 500 caches placed within 100 miles of my house!

 

Ah! nice. That's a great idea. Appreciate it.

 

Jim