Jump to content

PQs & archived caches


wwind

Recommended Posts

Is there a way to get a pocket query to show archived caches?

 

Over the past year I've run PQs to find all the caches in my state, and have loaded them into GSAK. As I'm going to go caching in an area, I'll run a PQ for that area to refresh the data. Yesterday I spent 3 hours solving a puzzle, and when I went to the page for that cache it showed that it had been archived months before. Once I saw that, I created and ran (or previewed) numerous PQs designed to pick up that cache and it showed in none of them. I see that caches marked as temporarily unavailable get picked up in PQs and hence get updated in GSAK, but the archived caches slip thru.

Link to comment

No. PQs will not return archived caches. Theory is, I believe, is that if they are gone, then the coordinates will do you no good. And active cachers want to find active caches.

 

If you know the GC# of the cache you can always access the page though. If you want GSAK to be updated, just download the GPX from the cache page and import it into GSAK as a single. Might want to keep a separate database in GSAK just for archived files. This won't cost you a PQ either.

 

You can also set up a Bookmark list of archived caches and add them to the list as you find the pages.

Link to comment

Actually archived caches don't "slip" through. If you check the last gpx date in GSAK you will see they did not get changed to the date the PQ has. To identify possible archived caches you filter for last gpx dates that occur before your PQ date. You can then do Waypoint>status check to see if they are archived or just unavailable and were not updated for some reason.

 

Jim

Link to comment

No. PQs will not return archived caches. Theory is, I believe, is that if they are gone, then the coordinates will do you no good.

 

I was afraid of that. The theory is true, unless you've got a bunch of caches in GSAK and need to know that they are no longer available.

 

I tried the "update, set filter, status check" and it works, kind of. I've got 10,000 waypoints for my state and I don't always know where I'll be travelling to. To update the whole state, I'll have to run 36 PQs, set the filter, and check about 1,000 statuses. (I went thru the process on the 500 caches closest to me, and found that 53 of them were archived. About 10%).

 

I guess I'll have to rethink my philosophy on keeping an offline database and cachine "on the way"

 

Thanks for the help.

Link to comment

In the past I've proposed two different solutions to this.

 

1 - Disable caches for more than a week before archiving. At the very minimum this will flag the cache as disabled for people that only pull weekly PQ's. If people are either checking "is not active" OR aren't checking either active/not active caches in their PQ, then they are already expecting disabled caches in their results, there is no downside to this.

 

2 - Include archived caches for a week (again, only if users are selecting not active or aren't selecting either, because they should still be expecting disabled caches).

 

The first solution is a policy change only and wouldn't even require any site reprogramming (except to check to see if a cache is already disabled and check the disable date). The 2nd would require a slight modification, but should still be a very easy change.

Link to comment

2 - Include archived caches for a week (again, only if users are selecting not active or aren't selecting either, because they should still be expecting disabled caches).

 

But if I go more than a week between PQ's I'll miss the cache was archived. Oh, wait, a whole new thing to whine about. :angry:

 

You know, your really need to accept certain limitations on an off line database. I don't care how you slice it or dice it, it will never be up to date. never. ever. won't happen. You can run a PQ, update your gizmo, and go out caching. Can't find one, come home and find out it was archived while you were out. IF you really need real time caching info, buy an iphone and use that.

 

Jim

Edited by jholly
Link to comment

But if I go more than a week between PQ's I'll miss the cache was archived.

If your caching with data thats more than a week old, you are asking for problems.

 

I do check to make sure I don't have stale data (more than a week), as do most cachers once they learn how, but by disabling for a week (maybe it should be 10 days or two weeks, this point could be looked at) then the site is at least flagging my database for me.

Link to comment

No. PQs will not return archived caches. Theory is, I believe, is that if they are gone, then the coordinates will do you no good.

 

I was afraid of that. The theory is true, unless you've got a bunch of caches in GSAK and need to know that they are no longer available.

 

I tried the "update, set filter, status check" and it works, kind of. I've got 10,000 waypoints for my state and I don't always know where I'll be travelling to. To update the whole state, I'll have to run 36 PQs, set the filter, and check about 1,000 statuses. (I went thru the process on the 500 caches closest to me, and found that 53 of them were archived. About 10%).

 

I guess I'll have to rethink my philosophy on keeping an offline database and cachine "on the way"

 

Thanks for the help.

 

Can't change the number of PQs required, but I'm not sure what your extra steps are on the verification. My immediate area (around 2800 caches) is simply a matter of filtering on the last GPX date and anything that was before my updated PQ gets tossed to the archive pile. Takes about 30 seconds to pull out any archived caches.

Link to comment

But if I go more than a week between PQ's I'll miss the cache was archived.

If your caching with data thats more than a week old, you are asking for problems.

 

I do check to make sure I don't have stale data (more than a week), as do most cachers once they learn how, but by disabling for a week (maybe it should be 10 days or two weeks, this point could be looked at) then the site is at least flagging my database for me.

 

The point is I have several db for several areas. I might not cache in a given area for several weeks. I don't pull PQ's for those on a regular basis. When I want to head to that area I pull a PQ, update the db and off I go. In the intervening weeks I would miss and archived cache with your plan. It also keeps the number of caches to a more manageable level.

 

Jim

Link to comment

Folks, this has nothing to do with the danger of stale data or the load on Groundspeak's servers or any of the other irrelevant things people keep bringing up.

 

Giving users tools to maintain offline databases is not Groundspeak's business model. GSAK is a third-party application, not written by the folks at Groundspeak. Just because it can maintain an offline database does not mean that is what Groundspeak intends for you to do so.

 

In my opinion, Groundspeak's long-range goal is to build a site where geocaching information is accessed real-time using wireless devices. Thus the interest they have expressed in the iPhone app. Their long-term plan does not include any plans to assist users in building individual mirrors of their database.

 

Now, I personally wish that Groundspeak had other priorities. But they don't, and they own the data and the site and they set the TOU. So accept it, already!

 

You're never going to get archived caches included in PQs.

You're never going to get state-wide PQs.

You're never going to get more than 5 logs in a PQ.

 

Once again, these things are not Groundspeak's business model. So they are not going to happen.

Link to comment

Folks, this has nothing to do with the danger of stale data or the load on Groundspeak's servers or any of the other irrelevant things people keep bringing up.

 

Giving users tools to maintain offline databases is not Groundspeak's business model. GSAK is a third-party application, not written by the folks at Groundspeak. Just because it can maintain an offline database does not mean that is what Groundspeak intends for you to do so.

 

In my opinion, Groundspeak's long-range goal is to build a site where geocaching information is accessed real-time using wireless devices. Thus the interest they have expressed in the iPhone app. Their long-term plan does not include any plans to assist users in building individual mirrors of their database.

 

Now, I personally wish that Groundspeak had other priorities. But they don't, and they own the data and the site and they set the TOU. So accept it, already!

 

You're never going to get archived caches included in PQs.

You're never going to get state-wide PQs.

You're never going to get more than 5 logs in a PQ.

 

Once again, these things are not Groundspeak's business model. So they are not going to happen.

 

I agree with everything except they own the data. On my fifteen caches they don't. I have given them a license to use my data, but I own it. This point is covered in the TOU.

 

Jim

Link to comment

Now, I personally wish that Groundspeak had other priorities. But they don't, and they own the data and the site and they set the TOU. So accept it, already!

 

You're never going to get archived caches included in PQs.

You're never going to get state-wide PQs.

You're never going to get more than 5 logs in a PQ.

 

Once again, these things are not Groundspeak's business model. So they are not going to happen.

 

If enough of the customers want a change, it is possible to change a product offer.

A great example of this is a Norwegian frozen pizza producer who now removes the paprika from their most sold pizza because of some groups at facebook etc. who wanted it removed.

 

Please: Don't stop suggesting changes because some ignorants tells you it will never happend!

Edited by bjorges
Link to comment
If enough of the customers want a change, it is possible to change a product offer.

Want to bet? I would guess that this is at least the 30th thread on archived caches in the last couple of years.

 

Please: Don't stop suggesting changes because some ignorants tells you it will never happend!

There is a difference between suggesting changes and beating your head against a wall. I know. I have been beating my head against the wall trying to get bookmark lists fixed for a while now. They finally made one small change to fix the most egregious bug, but I see no indication that they are willing to put even minimal resources into improving the usability.

 

My point is not to tell people to stop complaining; I am just tired of the flawed arguments people make again and again about why Groundspeak should want to make those changes. By all means, keep on asking. Don't let me stop you. Just quit being amazed when you are ignored.

Link to comment
Please: Don't stop suggesting changes because some ignorants tells you it will never happend!

"Ignorants" is not proper on the discussion boards.

 

http://forums.Groundspeak.com/GC/index.php?act=boardrules

The forum guidelines for posting are important and should be read and accepted before you choose to participate. Groundspeak and the global geocaching community encourage contributors who are courteous, polite and respectful. We discourage those who choose to behave in a disrespectful and/or irresponsible manner. Groundspeak, its staff and volunteer moderators will take appropriate steps to ensure discussions adhere to these guidelines.

 

In general, we will leave it to you, the community, to manage your own conduct. We ask that you treat other forum participants with respect. Please remember that this is a public venue read by many people of all ages, from around the world, spanning all walks of life.

 

Here are some things to keep in mind when posting:

 

1. Forum courtesy: Please treat Groundspeak, its employees, volunteers, fellow community members, and guests on these boards with courtesy and respect. Whether a community member has one post or 5,000 posts, they should be treated fairly.

 

3. Personal attacks and inflammatory behavior will not be tolerated. If you want to praise or criticize, give examples as to why it is good or bad. General attacks on a person or idea will not be tolerated.

Link to comment
Please: Don't stop suggesting changes because some ignorants tells you it will never happend!

"Ignorants" is not proper on the discussion boards.

Thanks for the support, mtn-man, but as you know I have been called a lot worse. Besides which, I kinda like being an "ignorant." ;)

 

Anyway, I was thinking about this topic a little more. It ocurred to me that, even though Groundspeak has no obligation to do so, it might be nice to give the customers some insight into its strategic plan. Is mobile ubiquitous access of the Groundspeak data the main direction, as I believe? Or I am wrong. I think they could do this without giving away too much valuable information to the competition, and it would be very helpful to all of us.

Link to comment
Thanks for the support, mtn-man, but as you know I have been called a lot worse.

Yeah, by me. ;):o

 

Is mobile ubiquitous access of the Groundspeak data the main direction, as I believe?

You know, I've never thought about it until you said that, but it sure seems like a cool direction to turn. I think there would be the old school type geocacher for quite some time, but technology is most surely getting smaller, faster and more efficient. Cell phones 10 years ago were clunky at best. Where will they be 10 years in the future? It won't be a "cell phone" anymore -- it will be a mobile device with a yet un-coined name. The iPhone with the GC.com application has eliminated the need for any off-line database since as it improves you have the entire web site right in the palm of your hand. You know immediately if a cache is archived because it isn't on your live search list. Search live, go find cache with the device, log with the same device. At our last event cache, the person next to me logged his attended note while we were sitting there watching the presentation. Its here now and only getting better.

 

Fizzy, just by natural progression, I think you are spot on.

Link to comment

I've gone caching with people who only send caches to their GPS every few weeks and end up caching with old info.

 

If it's a cache I already found, I wouldn't have sent it to my regular GPS, so I'll fire up my BlackBerry and Trimble, only to discover that there's no active cache anywhere around...because it was disabled or archived.

 

If I hadn't done that, they would have spent time searching for a non-existent cache.

Link to comment

Yesterday I spent 3 hours solving a puzzle, and when I went to the page for that cache it showed that it had been archived months before.

 

A prime example why offline-databases are a bad idea.

 

I doubt there are many cachers who goes to the effort of maintaining an offline database and then don't keep it more up to date than "months before".

Link to comment

The older the data the more likely you'll run into these problems. I've run PQs in the evening, updated the GPS and headed out in the morning, only to find things change overnight. Just part of the game.

 

But heading out with data that's several weeks/months old is just asking for DNFs in an active area.

 

It's like trying to wage a war with last month's troop deployment info.... Good luck.

Link to comment

I doubt there are many cachers who goes to the effort of maintaining an offline database and then don't keep it more up to date than "months before".

 

But this is exactly my point. I travel all over the state, but not on a scheduled basis. I got all the info for my state over a period of months as I went into that area. I did run a weekly PQ giving me caches "Updated in the last 7 days," expecting that being archived would be considered an "update." It wasn't until recently that I got burned on that. Now I know better

 

In regards to realtime caching via cell technology, one of the major drawbacks I see is that I've noticed a lot of the rural caches I go to have little or no cell reception in the area. There have been many times I've gone to make a call and got no signal whatsoever. Realtime databases are no good if you can't connect to them.

Link to comment

Back to the point of maintaining offline databases. I know, that's not the point. But if all one has access to is their database they can prevent themselves from spending time working on a puzzle that had been archived many months ago.

 

GSAK is very nice in having several columns related to when an entry was last uploaded into its database, and so on. It has the nice ability to filter on such things. It has the nice ability to allow one to send such information to a PDA, or even a GPS if you are smart. One can even go as far as to remove such no longer existing (perhaps) caches from their database. :P

 

Personally I have found many caches that were archived, but not yet physically removed from the world.

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