PQ for archived Caches

[+Inder]

Is there any way to create a PQ with the archived caches of a region?

 

I update my database regularly with PQs "changed within the last 7 days". It works fine, besides the fact, that archived caches remain. How can I filter them out without reconstructing my database from the scratch?

 

It would help, if the archive information was included in the "changed within last 7 days" PQ. If it is to much hustle to create archived PQs.

Edited May 2, 2010 by Inder

[+dfx]

unfortunately there is no way to include archived caches in PQs. i have the same problem, and my only solution for that is to wipe the DB on the PDA and do a full fresh import.

[+dakboy]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

[+Budderbean]

unfortunately there is no way to include archived caches in PQs. i have the same problem, and my only solution for that is to wipe the DB on the PDA and do a full fresh import.

 

I, too, have the same problem. I maintain a GSAK database of all caches in my state which is updated totally every seven days. The problem is that once a cache is "archived" the cache is never included again in the appropriate pocket query. It would appear to be so simple to include as an option to select "archived caches". The user then could create a PQ that only pulled the archived caches and when this query was posted to the GSAK database the availability would then be changed such that it could be filtered out.

[+Budderbean]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

 

Dakboy's solution will work; however, I would prefer that the cache not be "deleted" from the GSAK database. I use the GSAK database for multiple reasons one which is to identify my "found" caches. If you deleted an archived cache that you had found then the information derived from the filter would be incomplete.

[+Allanon]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

 

Dakboy's solution will work; however, I would prefer that the cache not be "deleted" from the GSAK database. I use the GSAK database for multiple reasons one which is to identify my "found" caches. If you deleted an archived cache that you had found then the information derived from the filter would be incomplete.

Use a more complex filter prior to the delete...

 

Last GPX date on or before the last update PQ, and

That I haven't found.

 

Will show you only caches you haven't found that were not updated.

[+pppingme]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

 

Dakboy's solution will work; however, I would prefer that the cache not be "deleted" from the GSAK database. I use the GSAK database for multiple reasons one which is to identify my "found" caches. If you deleted an archived cache that you had found then the information derived from the filter would be incomplete.

Then mark them as archived or disabled. Once you have a filter set for "last update gpx", then choose database | global replace then choose available status and set it to your choice of archived or disabled.

[+dakboy]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

 

Dakboy's solution will work; however, I would prefer that the cache not be "deleted" from the GSAK database. I use the GSAK database for multiple reasons one which is to identify my "found" caches. If you deleted an archived cache that you had found then the information derived from the filter would be incomplete.

Then mark them as archived or disabled. Once you have a filter set for "last update gpx", then choose database | global replace then choose available status and set it to your choice of archived or disabled.

Or move to an "archived caches" database.

[+Budderbean]

That works.

[+dfx]

unfortunately not everybody uses GSAK.

[+Chrysalides]

unfortunately not everybody uses GSAK.

For GSAK, I use "Review for Archive" macro. It requires manual intervention and does not screen scrape.

 

Any of my other offline DBs (Palm when I was using it, Oregon, Nuvi custom POI) I wipe them out and regenerate (from GSAK, but you can do it straight off the PQs as well).

[ao318]

I keep all of my finds in a separate data base within GSAK and it gets updated weekly with the my finds pq. It will update them and change them to the appropriate status of disabled, archived, etc.

 

I delete all non found caches that weren't updated in my regular database which usally is all of the recently archived caches.

[jholly]

If you're using GSAK, sort by Last GPX. Delete anything not in the most recent GPX for that PQ.

 

Dakboy's solution will work; however, I would prefer that the cache not be "deleted" from the GSAK database. I use the GSAK database for multiple reasons one which is to identify my "found" caches. If you deleted an archived cache that you had found then the information derived from the filter would be incomplete.

 

If your worried about found caches then use the MyFinds PQ. It does include the archived caches you found and there is no limit on the distance for the finds nor is there a limit on how many can be in the PQ. And to make life simple and good consider a found database that only contains your found caches.

[+Markwell]

http://markwell.us/archivedcaches.htm

[+dfx]

http://markwell.us/archivedcaches.htm

i find the first statement somewhat contradictory. PQs aren't meant to be used for maintaining offline databases, but instead to be uploaded to GPS devices. well, by uploading it to my GPS, i do exactly that: i create an offline database.

 

of course we all know it ain't gonna happen, but we can still wish for it something like a checkbox in the PQs "caches archived in the last 7 days", where an archived cache could only return the GC number and its status (archived) in the GPX and nothing else. ah, dreams...

 

then again, one could use an instant notification for "archived" and process those emails to update the offline DB. now there's an idea

[+Markwell]

i find the first statement somewhat contradictory. PQs aren't meant to be used for maintaining offline databases, but instead to be uploaded to GPS devices. well, by uploading it to my GPS, i do exactly that: i create an offline database.

It's not contradictory at all. A GSAK database of 10,000 caches that holds massive amounts of logs is not the same as the list of 356 caches that you'll be loading one entry per cache into your database.

 

Sure the list of caches in your GPS *is* a database, but now we're getting off the subject. Can you tell me WHY anyone would load archived caches into their GPS?

 

So my statement and how it relates to archived caches and pocket queries is indeed correct. From Groundspeak's standpoint, they don't want you loading an archived cache into your GPS. So why send it out? The only reason you would need archived cache data is to somehow update your offline database to weed out caches that were previously stored there. If you clear your database every time and put in fresh data, there's no need to know about archived caches.

 

PQs aren't meant to be used for maintaining offline databases, but instead to be uploaded to GPS devices

[+Vater_Araignee]

It's not contradictory at all. A GSAK database of 10,000 caches that holds massive amounts of logs is not the same as the list of 356 caches that you'll be loading one entry per cache into your database.

 

Sure the list of caches in your GPS *is* a database, but now we're getting off the subject. Can you tell me WHY anyone would load archived caches into their GPS?

 

So my statement and how it relates to archived caches and pocket queries is indeed correct. From Groundspeak's standpoint, they don't want you loading an archived cache into your GPS. So why send it out? The only reason you would need archived cache data is to somehow update your offline database to weed out caches that were previously stored there. If you clear your database every time and put in fresh data, there's no need to know about archived caches.

 

PQs aren't meant to be used for maintaining offline databases, but instead to be uploaded to GPS devices

I'm in no way arguing but to answer that "For potential retrieval of geolitter".

Lets face it, if a CO has not removed something within a month of archival they likely aren't going to do so.

[+Avernar]

If you clear your database every time and put in fresh data, there's no need to know about archived caches.

That only works well if one days worth of PQs covers your entire caching area.

[+Markwell]

I'm in no way arguing but to answer that "For potential retrieval of geolitter".

Lets face it, if a CO has not removed something within a month of archival they likely aren't going to do so.

Provided it's not listed on ANOTHER site than Geocaching.com

[+Markwell]

If you clear your database every time and put in fresh data, there's no need to know about archived caches.

That only works well if one days worth of PQs covers your entire caching area.

You just have to load all of the PQs at the same time. Download your PQs to one folder. Load them all at the same time. It can be PQs of 14 days worth, but a fresh load will update them - and delete whatever you have in GSAK at the beginning.

[+Avernar]

You just have to load all of the PQs at the same time. Download your PQs to one folder. Load them all at the same time. It can be PQs of 14 days worth, but a fresh load will update them - and delete whatever you have in GSAK at the beginning.

That's pretty much the same result of auto archiving anything with a last GPX date of more than 14 days which I currently do. I still could end up going to archived caches by accident. To minimize this I have a notify set up for archivals so I can at least keep this from happening close to home.

 

I don't use the delete first method as that would wipe out my corrected coordinates and multi stages.

Edited May 4, 2010 by Avernar

[+Markwell]

Excellent solution. Works just fine.

 

But again, it brings us back to the axioms on my page:

1. GC.com didn't create PQs for users to maintain offline databases. They were created as a means for querying against the database and downloading sets of caches for quick upload to your GPS.
   
2. Any offline database created by a user is - by definition - instantly out of date with the most current version, which resides on Groundspeak's server.
   
3. GC.com takes a hard-line stance that while caches are in the database for archival purposes, they do not send out data on archived caches. As far as the PQs are concerned, they do not exist expect in the "All My Finds."
   
4. Since offline databases are stored and maintained in third party software, the onus is on third party software to weed out archived caches.
   

I think it falls under #4...

Edited May 3, 2010 by Markwell

[+dfx]

Can you tell me WHY anyone would load archived caches into their GPS?

simply to save time. importing a GPX takes time, and the more caches you import the longer it takes. it's faster to just import whatever has changed since the last import than to wipe the DB and import everything again (which is especially true with certain software where importing a single PQ with 500 caches can take up to 5 minutes - do the math for larger numbers of caches). the lack of the ability to include archived caches in PQs is the only thing that keeps this method from being reliable.

 

i don't think anyone actually wants to load archived caches on their GPS devices, but instead rather delete them off the GPS or mark them as archived if they're already loaded, which is why it would be sufficient to include archived caches as stub entries.

[+gse1986]

Excellent solution. Works just fine.

 

But again, it brings us back to the axioms on my page:

1. GC.com didn't create PQs for users to maintain offline databases. They were created as a means for querying against the database and downloading sets of caches for quick upload to your GPS.
   
2. Any offline database created by a user is - by definition - instantly out of date with the most current version, which resides on Groundspeak's server.
   
3. GC.com takes a hard-line stance that while caches are in the database for archival purposes, they do not send out data on archived caches. As far as the PQs are concerned, they do not exist expect in the "All My Finds."
   
4. Since offline databases are stored and maintained in third party software, the onus is on third party software to weed out archived caches.
   

I think it falls under #4...

 

What about the option to simply download a PQ which contains the GC number and the archived flag? The data is then useless to anyone wanting to search for archived caches (as there's no coords) but would help those wanting to remove archived caches from their database?

[+Vater_Araignee]

I'm in no way arguing but to answer that "For potential retrieval of geolitter".

Lets face it, if a CO has not removed something within a month of archival they likely aren't going to do so.

Provided it's not listed on ANOTHER site than Geocaching.com

Too true.

[ao318]

Can you tell me WHY anyone would load archived caches into their GPS?

simply to save time. importing a GPX takes time, and the more caches you import the longer it takes. it's faster to just import whatever has changed since the last import than to wipe the DB and import everything again (which is especially true with certain software where importing a single PQ with 500 caches can take up to 5 minutes - do the math for larger numbers of caches). the lack of the ability to include archived caches in PQs is the only thing that keeps this method from being reliable.

 

i don't think anyone actually wants to load archived caches on their GPS devices, but instead rather delete them off the GPS or mark them as archived if they're already loaded, which is why it would be sufficient to include archived caches as stub entries.

But wouldn't you also want caches that have updated coordinates, that are disabled, needs maintenance logs, SBA logs, etc? The easiest and most efficient thing to do is remove the old information and install the most current information.

 

I do this every time I go out, whether it's for 10 caches or 1000. I think it is worth my time to update my GPS with the most current information so I do not end up looking for something that might have been moved 100', removed for maintenance, or is just no longer there but has not yet been archived.

 

The only purpose I see for knowing or retrieving archived caches is to see the history of why a cache was removed from a spot to help me determine whether or not to hide a new one in it's spot.

[+dfx]

But wouldn't you also want caches that have updated coordinates, that are disabled, needs maintenance logs, SBA logs, etc? The easiest and most efficient thing to do is remove the old information and install the most current information.

yes i do want that information, but i don't need to wipe my DB to get that. new information overwrites old information, so importing a new PQ gets me all that instantly. only archived caches will be left sitting there and not getting updated (or deleted rather).

Edited May 4, 2010 by dfx

[+Inder]

yes i do want that information, but i don't need to wipe my DB to get that. new information overwrites old information, so importing a new PQ gets me all that instantly. only archived caches will be left sitting there and not getting updated (or deleted rather).

 

That's exactly, what I mean. It would help a lot and save a big amount of time feeding the gps-devices.

[+Markwell]

But there's already a way to do that in GSAK. You just sort by Last GPX Update.

[ao318]

yes i do want that information, but i don't need to wipe my DB to get that. new information overwrites old information, so importing a new PQ gets me all that instantly. only archived caches will be left sitting there and not getting updated (or deleted rather).

 

That's exactly, what I mean. It would help a lot and save a big amount of time feeding the gps-devices.

 

In GSAK, if you use it and after running most recent PQ update, select filter>check not found>leave Archived, Temporarily Unavailable, and Available checked>select the "Date" Tab>Choose a date for "Last updated GPX">select go.

 

This will list every cache that did not get updated within your last set of PQ's. These generally are all of the most recently archived and temporarily disabled caches. Choose delete waypoints and select all. Now all those outdated caches are no longer in your database.

 

Send this new, updated, database to your GPS. This takes me 5-10 minutes max to do.

 

You do have the ability in GSAK to not alter waypoints with your notes, updated coordinates, and certain caches you have selected to not be updated so their information will not be altered. I do this for the puzzles I have solved and the caches I have made notes on. This process has been done over time so it does not interfere with my updating and reloading of databases to my GPS.

 

Edited to add a word and that Markwell beat me to it with a simpler answer.

Edited May 5, 2010 by ao318

[+Inder]

First of all, I don't use GSAK.

Second, I only generate "changed within last 7 days" PQs, not full ones.

So this does not work for me.

[+baloo&bd]

What about the option to simply download a PQ which contains the GC number and the archived flag? The data is then useless to anyone wanting to search for archived caches (as there's no coords) but would help those wanting to remove archived caches from their database?

 

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

 

If it were to really exist however is listed on another site, there is a reason. Possibly it is on private property, too close to RR tracks or some other reason where GC does not want to encourage seeking it. If your reason is because you want to find a place to hide a cache, if you follow the guidelines, the reason is irrelevant. Muggles? Maybe your a better hider. Private Property? You agree with the submission you have adequate permission. Nosy neighbors or complaints? The reviewer is aware and more than likely has noted the area as a problem if it were real. Picking up Geotrash? Really? What if it is listed on one of the other sites.

 

For those who keep responding you do not use GSAK, that's ok however it is a solution. That allows you to not only keep track of active caches but also set your found caches to archived when they are without deleting them, purge your database of caches that do not exist and update all the information on your caches even if you run all 35 PQs over 7, 14 or even 30 or more days. If GSAK is not for you, set up a Access DB thta can do the same however your reinventing the wheel needlessly. Come over to the dark side. We have donuts.

Edited May 5, 2010 by baloo&bd

[jholly]

First of all, I don't use GSAK.

Second, I only generate "changed within last 7 days" PQs, not full ones.

So this does not work for me.

 

Okay, but the subtitle was keeping up your database. What database do you use? Does it track the date the data was loaded?

[ao318]

First of all, I don't use GSAK.

Second, I only generate "changed within last 7 days" PQs, not full ones.

So this does not work for me.

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

[+dfx]

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

that's exactly the reason why we do want archived caches in PQs, at least as stub entries. we don't want them so we can keep information about them, we want them so we can delete those caches off the GPS. because without that, those cache entries would sit there on the GPS, effectively doing what you mentioned (maintaining information about something that's not there), they'd never get updated with the information that they've been archived, and we may end up going looking for them because we don't know any better. we want to know about archived caches so we don't go looking for them.

 

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

GSAK isn't the solution to everyone's problems. particularly, not everybody can use it as not everybody uses windows.

Edited May 5, 2010 by dfx

[+gse1986]

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

that's exactly the reason why we do want archived caches in PQs, at least as stub entries. we don't want them so we can keep information about them, we want them so we can delete those caches off the GPS. because without that, those cache entries would sit there on the GPS, effectively doing what you mentioned (maintaining information about something that's not there), they'd never get updated with the information that they've been archived, and we may end up going looking for them because we don't know any better. we want to know about archived caches so we don't go looking for them.

 

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

GSAK isn't the solution to everyone's problems. particularly, not everybody can use it as not everybody uses windows.

 

Exactly. That's why I suggested merely having, for an "Archived Caches PQ" to list a GC number and the archived flag. Thus to anyone wanting to search for the item it's relatively useless, and requires the user to find the cache by logging in and looking at archived data anyway, but for users of GSAK it would allow old caches to be archived in the database (and then deleted).

 

[+baloo&bd]

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

that's exactly the reason why we do want archived caches in PQs, at least as stub entries. we don't want them so we can keep information about them, we want them so we can delete those caches off the GPS. because without that, those cache entries would sit there on the GPS, effectively doing what you mentioned (maintaining information about something that's not there), they'd never get updated with the information that they've been archived, and we may end up going looking for them because we don't know any better. we want to know about archived caches so we don't go looking for them.

 

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

GSAK isn't the solution to everyone's problems. particularly, not everybody can use it as not everybody uses windows.

Exactly. That's why I suggested merely having, for an "Archived Caches PQ" to list a GC number and the archived flag. Thus to anyone wanting to search for the item it's relatively useless, and requires the user to find the cache by logging in and looking at archived data anyway, but for users of GSAK it would allow old caches to be archived in the database (and then deleted).

 

GSAK currently does have the ability to filter out, and subsequently delete, archived caches.

 

Since I do run GSAK on an Ubuntu desktop as well as my Windows laptop, not sure what you are using unless you are referring to Apple or Wii. In which case, you're right, it only runs on computers.

 

Whatever database you are using, if it does not show the last GPX date, then it is a shortcoming of the database you are using not the data being presented as all the information you need to accomplish this is included. Otherwise it is a simple matter of filtering out all records that were not updated during your last PQ cycle. i.e. Many people run a series of PQs over a week, so it is a simple matter of anything not updated in the last seven days and deleting the results.

 

You can keep pushing for or resisting the methods that have been suggested, however it will only result in frustration. Aside from being a very small segment of cachers that want or could/would use this, the issues it would create just make it not very desirable, probably not even feasible, for GC to offer it.

[+gse1986]

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

that's exactly the reason why we do want archived caches in PQs, at least as stub entries. we don't want them so we can keep information about them, we want them so we can delete those caches off the GPS. because without that, those cache entries would sit there on the GPS, effectively doing what you mentioned (maintaining information about something that's not there), they'd never get updated with the information that they've been archived, and we may end up going looking for them because we don't know any better. we want to know about archived caches so we don't go looking for them.

 

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

GSAK isn't the solution to everyone's problems. particularly, not everybody can use it as not everybody uses windows.

Exactly. That's why I suggested merely having, for an "Archived Caches PQ" to list a GC number and the archived flag. Thus to anyone wanting to search for the item it's relatively useless, and requires the user to find the cache by logging in and looking at archived data anyway, but for users of GSAK it would allow old caches to be archived in the database (and then deleted).

 

GSAK currently does have the ability to filter out, and subsequently delete, archived caches.

 

Since I do run GSAK on an Ubuntu desktop as well as my Windows laptop, not sure what you are using unless you are referring to Apple or Wii. In which case, you're right, it only runs on computers.

 

Whatever database you are using, if it does not show the last GPX date, then it is a shortcoming of the database you are using not the data being presented as all the information you need to accomplish this is included. Otherwise it is a simple matter of filtering out all records that were not updated during your last PQ cycle. i.e. Many people run a series of PQs over a week, so it is a simple matter of anything not updated in the last seven days and deleting the results.

 

You can keep pushing for or resisting the methods that have been suggested, however it will only result in frustration. Aside from being a very small segment of cachers that want or could/would use this, the issues it would create just make it not very desirable, probably not even feasible, for GC to offer it.

 

You're right it doesn't have the ability to do that automatically, however simply being able to apply a filter for archived caches(whose flag has been set by an "archived query" and then deleting the waypoints in that filter is only a very quick task.

 

I can see that you don't feel the archived query would be beneficial to how you use the pocket queries, however i believe that others would be able to benefit from it.

 

The alternative is to run the same query over and over again, and then delete any waypoints not updated in the most recent query. This can cause issues if for example a huge series appears nearby, thus the slightly further away caches would not appear in a nearest 1000 query, but would not be archived.

 

Edited May 5, 2010 by gse1986

[+baloo&bd]

I can see that you don't feel the archived query would be beneficial to how you use the pocket queries, however i believe that others would be able to benefit from it.

 

It is not that I do not see it as beneficial, which I don't, however that realistically the risk does not away way the benefits, especially since so few would need it.

[ao318]

Because in the world of databases and geocaching, there is no need to maintain information on or to go look for something that does not exist.

that's exactly the reason why we do want archived caches in PQs, at least as stub entries. we don't want them so we can keep information about them, we want them so we can delete those caches off the GPS. because without that, those cache entries would sit there on the GPS, effectively doing what you mentioned (maintaining information about something that's not there), they'd never get updated with the information that they've been archived, and we may end up going looking for them because we don't know any better. we want to know about archived caches so we don't go looking for them.

 

You may want to try GSAK out. It is free to download and after 21 days you will receive a nag message asking you to donate a one time $25.00 fee. It is well worth your time to at least try this product, it's free.

GSAK isn't the solution to everyone's problems. particularly, not everybody can use it as not everybody uses windows.

 

Exactly. That's why I suggested merely having, for an "Archived Caches PQ" to list a GC number and the archived flag. Thus to anyone wanting to search for the item it's relatively useless, and requires the user to find the cache by logging in and looking at archived data anyway, but for users of GSAK it would allow old caches to be archived in the database (and then deleted).

 

Have you tried Maccaching.com? Don't know much about it but it might be an option.

 

Just for information, I have 3 Apple computers and 1 PC.

Edited May 5, 2010 by ao318

[+dfx]

It is not that I do not see it as beneficial, which I don't, however that realistically the risk does not away way the benefits, especially since so few would need it.

risk? what risk? how does a PQ that tells me "GCXXXX = archived" without any further details pose a risk?

[+baloo&bd]

It is not that I do not see it as beneficial, which I don't, however that realistically the risk does not away way the benefits, especially since so few would need it.

risk? what risk? how does a PQ that tells me "GCXXXX = archived" without any further details pose a risk?

 

Please read thread for explanation.

[+dfx]

Since I do run GSAK on an Ubuntu desktop as well as my Windows laptop, not sure what you are using unless you are referring to Apple or Wii. In which case, you're right, it only runs on computers.

 

Whatever database you are using, if it does not show the last GPX date, then it is a shortcoming of the database you are using not the data being presented as all the information you need to accomplish this is included.

all that is beside the point. the actual question is, why do i even need to run the data through a 3rd party database to be able to delete off archived caches? PQs are supposed to be uploaded to GPS devices, right? and that's what should be possible: upload the GPXs to the GPS in order to keep the information on the GPS up-to-date. it's perfectly possible to do that, with the exception of having archived caches as leftovers.

 

yeah i also have a database and yeah i can also filter out caches not updated by the last PQ. but that's beside the point. it should be possible to get rid of the archived caches on the GPS without having to use a 3rd party application.

[+dfx]

It is not that I do not see it as beneficial, which I don't, however that realistically the risk does not away way the benefits, especially since so few would need it.

risk? what risk? how does a PQ that tells me "GCXXXX = archived" without any further details pose a risk?

 

Please read thread for explanation.

i did. i don't see it. please enlighten me.

[+baloo&bd]

yeah i also have a database and yeah i can also filter out caches not updated by the last PQ. but that's beside the point. it should be possible to get rid of the archived caches on the GPS without having to use a 3rd party application.

 

It is. Delete caches on your GPSr and load new PQ, but you already knew that.

 

This has become redundant. We're goin' caching.

[GOF and Bacall]

We used to be able to see archived caches on the maps. Then during an upgrade that went away. Nate had said it was going to return at some point and it was left at that for quite a while. Eventually people started asking when. Nate came back and explained that, unfortunately, it would not happen. The official reason seems to be that when dealing with landowner issues it has sometimes been necessary to make the promise that once archived the cache would not be available. It is my theory that GS lawyers have been involved. "It will help limit your liability if you do not make archived caches available in searches." But I have no evidence, just a feeling.

[+dfx]

It is. Delete caches on your GPSr and load new PQ, but you already knew that.

 

This has become redundant. We're goin' caching.

redundant indeed. please read thread to find out why that's not good enough.

 

[+Cache O'Plenty]

Please hold.... My 5 PQs just generated. Time to update and delete archived (not updated) caches. Be back in 10...

 

Sorry, it took 11..... 4835 caches in PQs, 4 new, 969 updated, 29 deleted (I delete disabled AND archived). Ready to download to GPS...

Edited May 7, 2010 by Cache O'Plenty

[BlueRajah]

"It will help limit your liability if you do not make archived caches available in searches." But I have no evidence, just a feeling.

 

Ding

In My Opinion.. we are close to a winner.

Think of you being the grumpy old man up the street with a vacant wooded lot. You collect all the baseballs and stuff from the neighborhood kids. You see people sneaking into your property. Well you never gave their permission. You stop them and find out they are geocaching. Well in a fit of rage you put up signs.

The cache is archived on the website. If it still shows on the website, or dbase, there are people who look at the listing and decide to continue to go after it because they still get the smiley, and the thrill of the hunt.

 

There is liability, I am sure, but also it is bad on community relations. As bad as it may be with the grumpy old guy. What about a Forest Service Manager that does not want cachers in a sensitive area, or a State Park Manager that has caches in an area without permission, historical sites, etc. People still hunting for caches or the fact that they can look at a map and still see caches where they wanted it to go away causes issues. Burning bridges with them makes it even harder for our game in the future.

 

It may help the dbase cleanups, but the other issues it causes is a larger problem.

[+dfx]

The cache is archived on the website. If it still shows on the website, or dbase, there are people who look at the listing and decide to continue to go after it because they still get the smiley, and the thrill of the hunt.

that's why several people have suggested to return archived caches in PQs as stub entries. just the GC code and the fact that it's archived, nothing more, no coordinates (or bogus coordinates), no description, no other details, and that only for a limited time (something like "caches archived in the last 7 days"). there's no harm done with that.

 

of course you could argue that people could use this information to then go to the website and manually get all the details from there. but if somebody wants to go for archived caches, they can always do that, they don't need a PQ for that.