Weekly Email, Showing Archived Caches?

June 2, 2005

This has probobly been talked about before, but why doesn't the weekly email notification show you caches that have been archived. There have been a couple of times that I have been looking for caches that have been archived, that I haven't noticed.

24.7k · June 2, 2005

The Gist of the argument as to why not is that you should not be caching with stale data. That way you don't look for a cache that turns out it has a killer bee nest next to it.

However it's a good idea. I like knowing when a cache goes missing or is archived. Every now and then I get a cache I'm keeping tabs on for the day I have time to go find it. Then when that day comes it's gone and worse I can't figure out how to look it up to see why it's gone because I don't recall the name exactly. Then there is the general state of affairs in my neck of the woods. How busy has the local cache maggot been? I don't really know because caches come and go before I can ever hunt them.

9.4k · June 2, 2005

It is a new cache notification emailer.

June 5, 2005

Andrew,

If you checked "SHOW ME -- CACHES OF SELECTED TYPES" insteed of ANY TYPE you must have IS NOT ACTIVE under "THAT" checked to get archived caches.

June 8, 2005

Actually checking the not active only shows caches that are disabled. Once they are archived they do not show up in a PQ.

June 8, 2005

I asked pretty much the same question a few weeks ago but was told just as stated above, they don't want us using "stale" data.

Of course the only problem is I have no choice but to continue on using "stale" data even though having archived information would help to keep my information more "fresh". ::shrugs::

Thread

9.4k · June 8, 2005

Of course the only problem is I have no choice but to continue on using "stale" data even though having archived information would help to keep my information more "fresh".

Why? The geocaching.com site is quite current. In fact it is as current as it can get.

8k · June 8, 2005

Of course the only problem is I have no choice but to continue on using "stale" data even though having archived information would help to keep my information more "fresh".

Why? The geocaching.com site is quite current. In fact it is as current as it can get.

You know very well that the problem is not GC.COM. People are getting PQs with the latest data from GC.COM and loading this information into GSAK (or some other software) where they can slice and dice the data in various ways. When a cache is archived there is no notice other than it stops showing up in the PQ. Various people have asked for the ability to get archived caches in a PQ so that GSAK could tell which caches have been archived. The are several alternatives right now:

1. Delete all existing caches from GSAK before loading PQ. -> Not a very good alternative as you may lose notes/corrected coordinates/user data that you have stored in GSAK.

2. After loading your PQ in to GSAK, filter on date of last GPX update to see which caches didn't get updated. These are likely archived caches. -> problem if you have several different PQs that you run on different days of the week or if you have PQs that return the maximum 500 caches or a specific number of caches as new caches in the area may push some existing caches off the query.

3. Carefully create a series of PQs that each returns less than 500 caches (by setting the distance and the dates hidden). Load all PQs for the area. Filter on the same area as in your pocket query and sort on date of last GPX update to find the caches that didn't get update. -> This is what I do and I have a GSAK macro to do the load, filter, and sort. I still have to manually mark the caches as archived or delete them. And when I cache outside my normal area I create separate GSAK database and use 1) above.

4. This idea just came to me and I haven't thought all the way through yet: Load the GPX file with a GSAK macro that clears all user flags and sets the user flag for the cache updated. Filter on caches with User flag set. Do global replace to set the user data for the caches in the filter to name of the PQ. Filter for user data equal to the name of the PQ but with user flag not set. These are the caches that were last updated the last time the PQ was loaded into GSAK but not updated this time. If the PQ is not max'ed (e.g 500) out these are the archived caches.

24.7k · June 8, 2005

I asked pretty much the same question a few weeks ago but was told just as stated above, they don't want us using "stale" data.
Of course the only problem is I have no choice but to continue on using "stale" data even though having archived information would help to keep my information more "fresh". ::shrugs::

Thread

I think some people are on different wavelengths in this theread.

Loading your GPS and PDA with current data is easy. That keeps you from looking for archived caches. Most advice on why you don't need to see archived caches in your weekly cache notification email cover how to stay current.

However that's entirly different from seeing what all has changed in your area. What's new, what's disabled, what's been archived. That lets you keep tabs on your territory and what's going on. It's also different from keeping your PDA and GPS up to date.

June 8, 2005

Of course the only problem is I have no choice but to continue on using "stale" data even though having archived information would help to keep my information more "fresh".

Why? The geocaching.com site is quite current. In fact it is as current as it can get.

It may be quite current, but not when your using the paper method. I know its not the best way, but its pretty much my only way currently. I have a binder full of cache pages...I update it as often as I can but its all done while at work. I have dial-up access at home with no printer. So, on the weekends I don't log in very often...

Someday when I have the luxury of a pda, gsak, a premium membership and a great home system with high speed net....I probably won't give a rats arse about the archived notification. I still think it would be a great addition but thats just my two cents.

9.4k · June 8, 2005

Ok. I can understand your situation better now.

I have a few more cache finds (but not a whole lot), and I rarely have a use for Pocket Queries. I do not print out cache listings until I leave because I do have a high speed connection, but this should help.

Before you go on a cache hunt I assume you pick out the listings you want to find. from there, dial-in to the geocaching.com site and enter in the GC code for each listing you plan to find. You're not a power cacher so I doubt you'll go find more that a few caches in a day (like me). Check the status at that time and note any strange logs that may indicate that the cache is missing. Toss the ones that are archived.

For speed sake you can bookmark http://www.geocaching.com/seek so you really only need to go to that page and use the submit button to check on the caches you plan to find that day.

You really need to review the cache listings before you leave. Adding archived listings in the new cache notification will not help you avoid 90% of the issues that arise on cache listings.

HTH.

9.2k · June 8, 2005

Or, to check current information on a stale pocket query, the third party software includes a hyperlink to the actual GC.com cache page, just a mouseclick away. I may not do that for every park and grab along my route, but I sure do look at the cache page very shortly before hiking more than a mile or two to get to a "destination" type cache.

I've gotten along quite well finding caches by using nothing but fresh pocket queries. If someone wishes to assemble a vast offline database of stale information, well, there are risks associated with that, or a bit of extra work to flag the archived caches, using solutions that have been described in previous forum threads. But for me, personally, the only stale info. that I maintain is a master GPX file of all my finds, including archived caches.

June 8, 2005

As before I really do appreciate the help/tips/ideas. Unfortunately they really don't help me a whole lot. Again, I try to keep my pages as current as possible but whenever I leave the house my binder goes with me. A good portion of the time my caching is spontaneous. I'm never really sure where I'm going, it just happens. When I say I have a binder full of pages, I mean I have a binder FULL of pages. From my home coords I've got nearly every cache for roughly a 30 mile radius of home and a 2" binder that is packed full.

Running into the archived cache sites hasn't been a major issue. I've only had it happen maybe half a dozen times. So I spend a half hour or better looking for something that isn't there....there have been many other times where I've spent much more time looking for something that IS there and didn't find it. Yeah, I've got my share of DNF's. Just means I go back again. When I go to log my DNF and find its archived, I've been simply posting a note and then toss my cache page out. Just one that I don't have to make a second trip looking for.

Anyhow, that's why I see it would be beneficial...to me. But hey, its not critical either.

5.3k · June 8, 2005

I understand the recurring chant of not wanting folks to play with stale data. I won't argue that fresher isn't usually better. But I really think that not publishing a list of archived caches (and there are a couple of possibilities that would work) actually works to counter that.

Storage of knowledge about caches is hierarchical. There's the master copy on the RAID array in the Groundspeak Compound. Collectively, it's about as authoritative as it gets. Via a variety of schemes, it pushes notification of new caches out such as the weekly mailing and pages like http://www.geocaching.com/seek/nearest.aspx?state_id=43 . Information about those caches becomes known and stored externally. It might be in a user's GPS, in a three-ring binder that's in the car (yes, my first several hundred caches were done this way) or even just the memory that "there's a cache over there". By not making similar 'withdrawl' notifications, there's no opportunity to recognize that a cache has gone away and allow those entries lower on the heirarchy to be shot down. Thus this scheme that was meant to get people to use fresh data ironically encourages use of stale data since there isn't another reasonable way to keep that three-ring notebook in sync.

The data wouldn't need to be terribly realtime, but providing a list of GC's that have been sent to the great ammo box in the sky would help people quit hunting caches that aren't there.

It would also help local organizations clean up after our own. I'll bet that most of us have had placers that have left the game and archived caches without harvesting them. If I were able to publish a list of caches that needs reaping, we could get established cachers to go clean up any leftover containers.

As it stands, we couldn't do that without collecting PQs, noticing which ones quit showing up, publishing that list, and then hand-waving away the tidbit that doing so would be a TOS violation. If I had a "legal" way to do it that wasn't a pain, I'd promote cache harvest runs with my locals.

5.2k · June 8, 2005

OK, say that hell freezes over and Jeremy does decide to create a notification of archived caches. How should it work?

Say there are 20 archived caches near me. One was archived in the last week.

Now I want a weekly email showing archived caches. Will that email include 20 caches every week, and probably slowly grow? Or should this week's email only include the one that was actually archived last week?

If the latter, which would be kinda similar to the current "new cache notification," how would I start processing it the first time? My hypothetical db might contain all 20 caches that have been archived over the last few years. But the notification only tells me about the one archived last week. How do I know the other 19 are gone?

Then there's the real question of what data to include in the email. Cache Name, GC#, coords, description, hints, logs. In reality only the GC# is needed for a program to rid itself of archived caches. The Cache Name would be helpful if you're clearing out a binder full of printouts. All other data is obsolete fluff.

5.3k · June 9, 2005

I think the cache name and GC# would suffice. Maybe the GUID since this site is growing fond of them. The list could be provided by state/country and show the most recently archived caches much like the list of new caches used to work. Maybe you provide only caches archived in the last N weeks/months in the non-dynamic case. If you wanted to provide it as a special form of nearest.aspx, that would be cream but perhaps overkill for the problem at hand.

I wouldn't expect to rectify your hypothetical three-ring that already contains caches that were archived two years ago. I think it's reasonable to solve the problem going forward and not necessarily backward.

Can there ever be a log after an archive log these days? If not, that may very well be a reasonable select criteria.

In short, it's a solvable problem if it's seen to be worth solving.

1.1k · June 9, 2005

OK, say that hell freezes over and Jeremy does decide to create a notification of archived caches. How should it work?

I would like to use the PQs to get that information sent to me. For that, I would suggest that they be handled just like data for any other unavailable cache. When running a PQ that does not have this section specified, all archived ones should be sent. If the "is available"-box is checked, then they should not be sent. For a long time this is in fact how it worked.

I don't believe that anyone at Groundspeak has any interest in whether my data are stale or not. They are interested in their own things (e.g. eyeball contact with the ads). As Robert Lipe points out above, their policies in fact represent a hurdle to my data not being stale. I used to cache in exatly the way Jeremy suggests above and I always had stale data problems. Now that I use GSAK and Cachemate and pay close attention, I can minimize the amount of stale data. If I had a way to get the "Archived" flag set with GSAK as part of the normal PQ methods, then it would save me some time and effort.

Getting the last few logs and notes on an archived cache can also be very useful if I want to set a new cache in the area being vacated. Things like "Decided to archive this cache as nearby farmer pointed shotgun at me as I was trying to service the cache" or "Cache location is now being used by a snake as home"... could be very useful in my consideration as to what to do. I see no reason why such information should be hidden.

9.2k · June 9, 2005

Hynr, if you're gonna raise the same arguments you've raised in the past on this subject, I'm gonna raise mine, too.

I'm still waiting for you to answer my question here. (Yep, that's the thread where ClydeE linked you to solutions to this issue with your beloved GSAK.)

I said it best here:

Please, please don't change the current way in which archived caches are handled on the website.... with the sole exception of including one's own logs on archived caches in a PQ of all caches logged.

When a geocacher (or the listing service) promises to a land manager that a cache will be removed from the listing service, that ought to mean "removed", not "freely searchable."

Please don't put me in violation of the land manager permits that I worked so hard to obtain for four of my caches. Thank you.

I'm consistent in my argument.

Wow, I was saying the same thing in May 2003. That's more than two years ago!

1.1k · June 9, 2005

Hynr, if you're gonna raise the same arguments you've raised in the past on this subject, I'm gonna raise mine, too.

I'm stating my point of view; you are stating yours. I didn't start this thread; I merely add my 2-cents.

I'm still waiting for you to answer my question here. (Yep, that's the thread where ClydeE linked you to solutions to this issue with your beloved GSAK.)

Neither Clyde nor I posted in that thread. I see your post, and understand what you are are saying.

I said it best here:

In this thread I do see a question that you posed and thought that it was more of a rhetorical question since you are obvioulsy aware that I don't live in Pennsylvania and have no knowledge about your sensitive land manager issue.

Please, please don't change the current way in which archived caches are handled on the website.... with the sole exception of including one's own logs on archived caches in a PQ of all caches logged.

When a geocacher (or the listing service) promises to a land manager that a cache will be removed from the listing service, that ought to mean "removed", not "freely searchable."

Please don't put me in violation of the land manager permits that I worked so hard to obtain for four of my caches. Thank you.

I do agree that archived caches should not show up routinely in the nearest searches (i.e. the "Listing Service"). I also think that if such a cache page does somehow show up on someone's computer screen, that it should explicitly identify the salient issues to prevent future problems. This is how it is now; I am not suggesting any changes to that.

However, the "Listing Service" is not synonimous with the database. Even now archived cache listings are not removed from the database. PQs are database extracts, not the "Listing Service". I think that the way the Listing Service handles this situation is fine. My wish is for a very small modification to the database extraction tools.

While I would say that the vast number of archivings don't involve the issue you desribe, I do respect your point of view. If your situation requires that one of your archived caches never again be rendered on someone's computer screen, then you might be able to get someone at Grounspeak to arrange that, but it would probably be a lot of work. Don't kid yourself into thinking that that is the current status quo. If you really need to obliterate such a listing, your best bet would be to edit the cache page and remove all the text that appears there before archiving it. Since each cache listing is actually a historical archive of every action that occurred there, complete removal is impossible without affecting every person that ever visited the cache.

1.1k · June 9, 2005

I know I would find it really useful to get a weekly list of caches that have been archived in my province during the current week or even a notification when the cache is archived. Sure get I get an archived notification if the user/approver posts a log when they archive it and I have a watch on the cache. I do watch a few hundred caches in my area, but I certainly have no desire to place a watch on every single cache.

And why I would find some sort of notification useful is that most times I go caching with my girlfriend, and in many cases while hunting for a cache, we pass by an area which had a cache that I already found, but since we are passing by, we figure that she might as well try to find the cache...only problem is, we don't know if it is still there, since I only keep a list of caches I haven't found on my GPS and PDA. By getting a weekly list of caches that have been archived in my province, I would generally have a mental note of which ones are/aren't there.

Since yesterday I noticed the # of caches in Ontario decresed by 8, but I only know of 1 that was archived since I only had a watch on one of them...Of course I am curious what the other 7 were.

I think it's been brought up enough that a number of people would find this type of information useful, even if it is just for curiousity sake.

Further to this, I think it would also be useful to get some sort of weekly notification of any cache page descriptions that have been updated.

5.7k · June 9, 2005

I wouldn't mind a simplistic approach. How about something similar to regular cache watch lists? If a cache is archived within 100 miles of me, I get sent a watchlist notice (basically, the exact same thing as if I was already watching the cache). I can then manually do anything I need to do to remove stale data from where ever I have it (binder, GSAK, etc). The volume of caches that are archived in a particular area shouldn't ever be that great, so I don't see too big a problem with this solution.

--Marky

June 9, 2005

To reiterate what's been said here, I would have to agree that there should be an active method for distributing current activities on caches that are archived. The current passive means do not seem to be working for many users.

given the two options of a email notification or searchable pq's; I would prefer to see the archived caches as an option in pocket queries. An email notification would remind me to clear out the caches from my list, but I would still have to manually delete them/mark them/rip them out of my binder.

Pocket queries are power tools by design. It gives us a way to find current information quickly and efficiently about multiple related caches. The current information on an archived cache is that it is archived. Although it is technically correct to say that the absense of data has meaning, it is not usually a good method for distributing information.

In the examples above, there is not a clear, simple (automated or programmatical) way to determine if a borderline cache did not show up in a poket query because it got beat out by a new, closer cache, or if it did not show up because it was archived. To be able to run a pocket query that returns recently archived caches, gives me a way I can update my current information by sorting the list and getting a positive response on an archived cache. I can quickly flip to that page in my binder and just trash that one page. I'm done.

The alternative seems to be to match each cache to a page and trash what's left. (the same theory applies to binders as the gsak database as the gps)

One last thing, and I'm done - Hymr, it would seem to me that it would be better service to your land managers to make sure that when you archive a cache everyone is notified quickly to stop looking for it. If I have already loaded your cache in my GPSr, I may still be looking for it weeks from now if I forget to check the page.

June 9, 2005

When people ask for information or notification on archived caches, they do not do so because they want to go hunt for those caches. On the contrary, they want to avoid them. Therefore the entire "we do not provide information on archived caches because you shouldn't use stale data" argument is bogus.

9.4k · June 9, 2005

When people ask for information or notification on archived caches, they do not do so because they want to go hunt for those caches. On the contrary, they want to avoid them. Therefore the entire "we do not provide information on archived caches because you shouldn't use stale data" argument is bogus.

Wrong. The argument that receiving a list of archived listings will make your off-site data up to date is bogus. You're oversimplifying the issues to suit your own argument.

The real deal is that the most accurate data is on the web site, and anything removed from the web site becomes immediately stale data. Relying on this stale data by using archived info is a Bad Idea, and an equally Bad Idea foir us to create features to discourage returning to the site for the most accurate data. Pocket Queries do a good job of offering you the best "stale" data. The better step is accessing data via WAP.

June 9, 2005

The real deal is that the most accurate data is on the web site, and anything removed from the web site becomes immediately stale data.

Yes, but you cannot expect "paper-based cachers" to print out a new folder of cache pages every day before they go caching just because the folder they printed out the previous day may contain two caches (out of a hundred) that have been archived in the meantime.

9.4k · June 9, 2005

If you read farther up the thread I offered some suggestions. I never said that keeping a binder of printed cache pages was a Good Idea, but I did suggest ways to make sure the caches you seek that day are checked to be current.

June 9, 2005

If you read farther up the thread I offered some suggestions. I never said that keeping a binder of printed cache pages was a Good Idea, but I did suggest ways to make sure the caches you seek that day are checked to be current.

The practicality of which, however, turned out to be limited in the case of the OP according to his answer.

9.4k · June 9, 2005

Of which he stated "Running into the archived cache sites hasn't been a major issue." So making it a major issue for a minor one doesn't seem to make much sense. But now we're just going beyond your original argument that my reasoning was bogus, which you didn't seem to dispute my correction to the contrary.

June 9, 2005

Of which he stated "Running into the archived cache sites hasn't been a major issue." So making it a major issue for a minor one doesn't seem to make much sense.

So you think people hunting for archived caches is a minor issue and you are OK with that? If so, why are you always worrying about them using stale data?

So basically you are saying that the problem raised in this thread is a minor issue, therefore you are not interested in finding a solution. Is that right?

9.4k · June 9, 2005

So basically you are saying that the problem raised in this thread is a minor issue, therefore you are not interested in finding a solution. Is that right?

Not at all. I'm saying that this is poor solution for updating stale data and creates a crutch that doesn't solve the problem. I'm not a fan of developing poor solutions.

9.4k · June 9, 2005

If you're not a premium member, all you have to do is check the website before you go caching. Any page in your binder can be removed if a cache has been archived.

Too much work? Then pay $3 and become a premium member. Far cheaper than the reams of paper you use, not to mention the expensive bubblejet ink for your printer :huh:

24.7k · June 9, 2005

Heck and all I want to see is what changed in the past week. Archives, new caches, disabled caches. It has nothing to do with fresh data for hunting caches. That part is easy.

June 9, 2005

When people ask for information or notification on archived caches, they do not do so because they want to go hunt for those caches. On the contrary, they want to avoid them. Therefore the entire "we do not provide information on archived caches because you shouldn't use stale data" argument is bogus.

Wrong. The argument that receiving a list of archived listings will make your off-site data up to date is bogus. You're oversimplifying the issues to suit your own argument.

The real deal is that the most accurate data is on the web site, and anything removed from the web site becomes immediately stale data. Relying on this stale data by using archived info is a Bad Idea, and an equally Bad Idea foir us to create features to discourage returning to the site for the most accurate data. Pocket Queries do a good job of offering you the best "stale" data. The better step is accessing data via WAP.

The real deal is that the most accurate data is on the web site, and anything removed from the web site becomes immediately stale data. Relying on this stale data by using archived info is a Bad Idea, and an equally Bad Idea foir us to create features to discourage returning to the site for the most accurate data.

I may be a bit confused myself, but I think I am seeing a different side of the coin.

I use pocket queries to keep from using stale data.

An example: I have a pq set up to run each friday for the nearest 500 caches to me. These are the caches I am most likely to hunt on saturday so I am getting the most updated data. Each item returned by the query gets updated in my records (whatever form they may be).

An archived cache will not be updated, but, it also doesn't get removed. It is up to me to come up with a way to find and handle the caches that do not get updated. This is something that I want to do because it's no fun to hunt for caches that no longer exist; and it's something gc.com wants me to do because they don't want me annoying landowners who have asked us to stop hunting. It makes everyone happy.

To verify that a cache is archived, I will go to that cache page. Then I will make the change in my records. I am likely to forget this step or skip a cache.

I am not sure I understand the difference between returning to the site to read the cache page online and receiving an archive note for a cache in a pocket query.

If I understand the quote above, we should consider pocket queries and print-outs stale basically immediately. I actually agree, but until I get internet on my cell phone, my data will never be more recent than when I last read the pages. If I tried to read the nearest 500 pages it would take hours... I'd spend all friday reading them. Then I'd go out and hunt on saturday with that information. Carrying the data with me that I received/printed on Friday night is no more stale than that alternative.

The only difference I can see is that I may miss the update for an archived cache if I rely on a pocket query. It seems to me that adding updates for archived caches to fix this would be a good thing.

I do understand that allowing access to archived data is in itself a bad thing. Perhaps there is some way to have a middle ground. I would like to throw a kink in the works and offer that an alternative may be to find a way to include just the waypoint id (GCXXXX) and some single field that would flag it as archived.

June 10, 2005

Heck and all I want to see is what changed in the past week. Archives, new caches, disabled caches. It has nothing to do with fresh data for hunting caches. That part is easy.

Jimminy Cricket!!!!

I Spend quite a few hours a day lurking and I STILL find time to glance at GC.COM to make sure my data is fresh

I've spent a lot of time caching papered and alwas found the time to check my data.

If one is too lazy to take two minutes to determine if their data is stale that's their sorry fault.

24.7k · June 10, 2005

Heck and all I want to see is what changed in the past week. Archives, new caches, disabled caches. It has nothing to do with fresh data for hunting caches. That part is easy.

Jimminy Cricket!!!!

I Spend quite a few hours a day lurking and I STILL find time to glance at GC.COM to make sure my data is fresh

I've spent a lot of time caching papered and alwas found the time to check my data.

If one is too lazy to take two minutes to determine if their data is stale that's their sorry fault.

You miss the point entirly.

In a busy week 20 caches in my area can be archived. Some of which I enjoyed, and some of which were ones I would of liked to gotten before they were archied. It's easy to know what ones are there to look for. It's harder to know what went missing. Most of this debate is about "fresh" data. I'm not really concerned about that. It would be nice to see what changed over the week. It's as simple as that.

Quick, check your data. What were the last 5 caches to be archived in your area! (If you use paper you actually have an advantage answering the question)

Edited June 10, 2005 by Renegade Knight

June 10, 2005

I'm sorry I don't miss your point. Possibly I'm not in such a cache rich area as yourself.

A little out of order, but these are the latest five.

Edited June 10, 2005 by wvcoalcat

1.1k · June 11, 2005

I think it is important to recognize that we all do things a bit different and we all have different situations and needs. I love geocaching and will be heading for an event tomorrow. Between my home and that event I have several possible trajectories and which one I take will depend in part on my caching partner's mood. The total number of caches along the way that I would have to review between now and tomorrow morning would be around 200. That would take a few hours - I'd rather be caching! Then at the event she and I may well hook up with some geocaching friends for some afternoon or evening caching. I have no clue which way that would go and am grateful that I have a system that allows me to package the data into my PDA. I am also grateful to Jeremy, Clyde England and Brian Smith for their dedication to their craft which makes this possible for me.

I also understand Jeremy's point of view that this is not a big problem. I agree. It is a little problem. I have, in fact, found a solution and just have to remember to use it. But to have archived caches in PQs be considered "not avtive" would be much more convenient for me. It would also be the most logical and least confusing.

June 11, 2005

I wouldn't mind a simplistic approach. How about something similar to regular cache watch lists? If a cache is archived within 100 miles of me, I get sent a watchlist notice (basically, the exact same thing as if I was already watching the cache). I can then manually do anything I need to do to remove stale data from where ever I have it (binder, GSAK, etc). The volume of caches that are archived in a particular area shouldn't ever be that great, so I don't see too big a problem with this solution.

--Marky

Good idea

June 12, 2005

What is the purpose of allowing us to view archived caches but not allowing us to run a pocket query for them so we can update our offline database? If you maintain the data for viewing purposes and we happen to see an archived cache, we are not going to go out and look for it. We just want the ability to run a query that will let us mark the newly archived caches in our GSAK database. It is not a big issue if you are just going to go out locally and find a couple of caches. But when you are in an area for another purpose and want to do some caching in your spare time using data that was uploaded to a PDA from the GSAK database, it would be nice to know if a cache was archived recently. Having an archived option on the pocket queries would really simplify life for those of us who would like that option. Those who don't need it would not bother. Isn't that what OPTIONS are for?

June 16, 2005

In my situation, I run a series of ten PQ's over a two day period each week to build a GSAK database of all caches within a 60 mile radius of my home (yes, in the SF bay area there are that many). I then have a couple of other PQ's I run on a daily basis to try to capture new caches that are added during the week. From this data I will download a batch of caches into the PDA and GPSr for which ever area I plan on going that day. Using this method on occasion I do try to find caches that have been archived or disabled (its happened to me twice in the last week, once disabled the day before the other was archived the day before). I do have a PQ for detecting disabled caches but since it does not pick up archived caches I don't find it very useful. I would wish for either one of two things:

1) A PQ option that would show all caches who'se status has changed within the last week (new > active > disabled > archived).

2) When ever a cache is set to archived, it actually goes disabled for one week before it becomes truely archived, this way we have a chance to see them.

One idea I had for those who walk around with binders full of printed caches, when ever you print up a cache and add it to your binder, add it to your watch list as well, you will get an email notification when ever its updated.

June 17, 2005

Got me again last night... Only spent a few minutes looking as I was trying to ditch the swarm of mosquitos following me but when I got home and logged on I found it to be archived.

Perhaps I could convince my daughter to break open her piggy bank and get me a pda for Fathers Day? :lol:

June 17, 2005

One idea I had for those who walk around with binders full of printed caches, when ever you print up a cache and add it to your binder, add it to your watch list as well, you will get an email notification when ever its updated.

That's not terribly practical. You'll get hundreds of e-mails will all the logs, instead of just the archival events.

Weekly Email, Showing Archived Caches?

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment