Jump to content

Pocket Query Of Archived Caches


H2"O"
Followers 3

Recommended Posts

If I run a pocket Querry and check "not active" that includes temporarily disabled also. I want to use the querry to remove caches from GSAK that are archived, not temporarily disabled. Any way to accomplish this?

Thanks!!

Link to comment

If I run a pocket Querry and check "not active" that includes temporarily disabled also. I want to use the querry to remove caches from GSAK that are archived, not temporarily disabled. Any way to accomplish this?

Thanks!!

 

Run a PQ and add it to your GSAK, anything that did not update with a "Last GPX" is no longer listed, just filter them out. I usually make a GPX file and load it in, then get my PQ for the next day, anything that states "Last GPX" from the day before is usually an archived cache. This is the easiest way I found to remove the archived caches from my GSAK database.

Link to comment

No. You don't get a list of archived caches in Pocket Queries because they are archived. The only exception is when you request your "My Finds" Pocket Query to keep a record of your travels.

It would be useful for archived caches to be included in PQs during the seven-day window after they've been archived. That way people people who run weekly queries can automatically keep their GSAK databases up-to-date.

 

Or have a special PQ that returns a list of caches that have been archived in (geographical area) within the past seven days. It could even be generated as a .LOC file, which would make it a cheap query to run.

 

dave

Link to comment

From having requested this myself and from reading threads over time where others have requested it, I can tell you that there is a lot of resistance by Groundspeak for this. We view the stuff in the gpx files as data and they view it as a list of geocaches. As a geocache, they figure that "when its gone, its gone". As data you and I figure that for the data be be most up-to-date in our databases "when its gone, mark record as "it's gone"". If you can convince them that this is important, then I will be happy.

 

I would add that ideally the choice of receiving fresh data for archived caches should be an explicit checkbox to prevent it from going to those who don't want it. And the data can be even less than you suggest. For instance, all it really needs to be is the GCcode the status and any logs generated by the archiving; perhaps like this:

  <wpt lat="" lon="">
<name>GCN0ZD</name>
<Groundspeak:cache id="215434" available="False" archived="True" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">
  <Groundspeak:logs>
	<Groundspeak:log id="8711711">
	  <Groundspeak:date>2005-06-26T04:47:39</Groundspeak:date>
	  <Groundspeak:type>Archive (show)</Groundspeak:type>
	  <Groundspeak:finder id="174706">Hynr</Groundspeak:finder>
	  <Groundspeak:text encoded="False">It's gone forever and it's not coming back.</Groundspeak:text>
	</Groundspeak:log>
  </Groundspeak:logs>
  <Groundspeak:travelbugs />
</Groundspeak:cache>
 </wpt>

Having data about remaining TBs show would probably also be valuable to those who track TBs

Link to comment

I think Hynr's statement above sums it up pretty well:

 

We view the stuff in the gpx files as data and they view it as a list of geocaches. As a geocache, they figure that "when its gone, its gone".

I'm trying to learn to do the "Last .gpx" date filter in GSAK to get rid of recently-disabled or Archived caches, but I don't always remember to do that. One time not doing that filter worked out to our group's benefit. I had the cache in my GPSr, they didn't, but the cache was still in place. :)

 

We found it and the cache owner was able to reactivate the cache.

Link to comment

No. You don't get a list of archived caches in Pocket Queries because they are archived. The only exception is when you request your "My Finds" Pocket Query to keep a record of your travels.

 

I received a PQ based on a bookmark list I'm preparing for a trip that included archived caches (they weren't archived when I originally bookmarked them). I then removed them from the bookmark list, since for my purposes I don't need a history of them. Don't know if that was another known 'exception' or a bug.

 

That leads me to a suggestion: Could we have the option of excluding archived/disabled caches from bookmark list PQs? Once the list is converted to a PQ, the filtering options are non-existent. I can see the logic, since the list is presumed to be hand selected in the first place, but when planning for a trip, the disabled/archived caches that appear can be annoying.

Link to comment

Can somebody tell me why the website is opposed to this? I like having the data for archived caches for a variety of reasons. I'm sure that this question has probably been asked and answered before but I can't find it. A markwell would be good. Thanks.

 

One previous answer was that if the cache were removed because of a land management issue (someone at a park got upset because it violated some unknown regulation), then all trace should be gone.

 

The other reason is that GC.com has long looked at themselves as the first and only place to have the database of caches. The database is constantly live and updating. If you want to know what caches are active on GC.com, you should look on GC.com, not in a GSAK database that is a snapshot of the data, and stale the minute it goes out the door.

 

Not making any judgement call - just providing historical references.

Link to comment

That's it? I was hoping for a better reason than that.

 

I'd also like to be able to get a list of archived caches for the reason stated by the OP but I also have other reasons to want this data. We all know it's available in the database and I've been told that the reviewers have access to it. Why can't the rest of us? Caches have a history and a legacy even after they're gone. I'd like to see that preserved better than it is. One of the reasons I keep a database of caches is because it contains this information that I can't readily get from the website. I don't think that I'm doing anything underhanded or shady but maybe I'm wrong about that. Now that I think about it, I have noticed that the website is very reluctant to let us have this information. I remember having to download the waypoints for archived caches one at a time from the cache pages because you can't download from the search pages. I realize that there's probably a few skeletons in the closet but is that the real problem?

Link to comment

I have started a Bookmark List of local Archived caches. It is not very inclusive because, with my slow Internet connection, it is time-consuming to use the Identify feature on the GC.com maps.

 

However, that is one thing you could do on a rainy day . . . or on a day when it is too hot to cache . . .

Link to comment

This questions comes up so many times you'd think gc.com might offer it as a paid service!

 

Luckily, GSAK has enough features to handle this - simply add a criteria to every filter in GSAK - updated in last day. Run your PQs every day so you'll never have stale data, and turn on notifies of archivings.

 

Personally, I use a two week window in GSAK, get my PQs at a rate which doesn't strain the system (only updated last 7 days), and review notifies in case it's a cache on my watchlist.

 

So many reasons have been given by gc.com and simply aren't easily defensible, and given the known workarounds using GSAK, it almost feels like a waste of breath:

 

One previous answer was that if the cache were removed because of a land management issue (someone at a park got upset because it violated some unknown regulation), then all trace should be gone.

 

Except that all trace is not gone, in your printed listings, nor in your GPS, nor on the website. Being able to get at least waypoint IDs and status of archived caches (not coordinates or even as much data as is in the my finds PQ) would facilitate people cleaning their other databases which don't have the date load filtering features of GSAK.

 

The other reason is that GC.com has long looked at themselves as the first and only place to have the database of caches. The database is constantly live and updating. If you want to know what caches are active on GC.com, you should look on GC.com, not in a GSAK database that is a snapshot of the data, and stale the minute it goes out the door.

 

As is the data in your GPS which you may be paranoid about losing or your printouts which you don't feel like checking through to remove each archive entry. As soon as you walk out the door it's stale. One could ask why they offer the site at all besides over mobile devices?

Link to comment

[it would be useful for archived caches to be included in PQs during the seven-day window after they've been archived. That way people people who run weekly queries can automatically keep their GSAK databases up-to-date.

 

Not necessary. WHen they get the PQ's working again, you have weekly downloads. Set up a filter in GSAK to show caches with no GPX in the last 7 days. Then delete everything in the filter.

 

If you do your PQ's weekly and keep them below the 500 limit, you are safe in assuming anything without a GPX in the last 7 days is archived.

Link to comment

Can somebody tell me why the website is opposed to this? I like having the data for archived caches for a variety of reasons. I'm sure that this question has probably been asked and answered before but I can't find it. A markwell would be good. Thanks.

 

If you like the idea of keeping archived caches, I would use GSAK.

 

As far as GC, if it is archived there is no reason to burden the system any further making them available. Actually, I am surprised they don't go thru and purge them from the system after a given amount of time (i.e. 18 to 24 months.)

Link to comment
It would be useful for archived caches to be included in PQs during the seven-day window after they've been archived. That way people people who run weekly queries can automatically keep their GSAK databases up-to-date.

Not necessary. WHen they get the PQ's working again, you have weekly downloads. Set up a filter in GSAK to show caches with no GPX in the last 7 days. Then delete everything in the filter.

 

If you do your PQ's weekly and keep them below the 500 limit, you are safe in assuming anything without a GPX in the last 7 days is archived.

Or it's in a region where I run the PQs on an as-needed basis.

 

I understand that there are various ways that I can change my behaviour in order to convince PQ + GSAK to produce the data that I want. But the computer is so much better at doing repetetive manual work, so that's why I'm asking for a way to offload the work onto it.

 

dave

Link to comment

[it would be useful for archived caches to be included in PQs during the seven-day window after they've been archived. That way people people who run weekly queries can automatically keep their GSAK databases up-to-date.

 

Not necessary. WHen they get the PQ's working again, you have weekly downloads. Set up a filter in GSAK to show caches with no GPX in the last 7 days. Then delete everything in the filter.

 

If you do your PQ's weekly and keep them below the 500 limit, you are safe in assuming anything without a GPX in the last 7 days is archived.

Unless the coordinates change and push it just outside your "x miles away" filter. (It's happened, and it took me forever to figure out why an active cache wasn't updating. :laughing:)

 

The only problem with the last .gpx date is that it doesn't work if you check "[X] updated in the last 7 days" to eliminate redundant data.

Link to comment
Guest
This topic is now closed to further replies.
Followers 3
×
×
  • Create New...