Jump to content

Being nosy


Recommended Posts

You can't view the page if it's been "unpublished"

 

As you are being the nosey one I'll leave it to you to explain which cache it is :huh:

 

oh yeah - durh! I was thinking the name would be visible! dunno why... :unsure:

Anyway, it was called "Have a nice day" nearish junction 14 of the M1 motorway...

 

Was simply surprised to see an older cache unpublished! hardly teething problems... :)

Link to comment

Just a guess...... but when this has happened before it is down to a landowner complaint.

 

Sometimes landowners who weren't approached for permission just ask for the cache to be removed. But on some occasions I guess they insist that no one else is able to come looking for the cache again, which is when a retraction takes place.

 

From threads on retractions in other parts of the forums, I seem to recollect that it shouldn't affect anyone's find count.

 

No doubt a friendly reviewer will correct me on that in a moment.

Link to comment

Found the cache in question deep within my gsak database, here's some highlights.

 

"Situated in the parking area of a large International

Retail Company."

"SMILE as you are on a Security camera !!!"

 

and from one of the last logs..........

"Despite trying our level best to look inconspicuous, we were accosted THREE times by security whilst searching for this one."

 

I think that re-inforces the "upset landowner" theory (apologies to the cache owner if that isn't the case).

Link to comment
Just a guess...... but when this has happened before it is down to a landowner complaint.

 

Sometimes landowners who weren't approached for permission just ask for the cache to be removed.

Bingo! That's the reason and as the police were involved as well it was "unpublished" as well as being archived.

 

If anyone has this cache in their offline database I would urge you NOT to try and find it. Not only will you fail (it has been physically removed) you will bring Geocaching into disrepute with the local plod.

Link to comment
Bingo! That's the reason and as the police were involved as well it was "unpublished" as well as being archived.

 

If anyone has this cache in their offline database I would urge you NOT to try and find it. Not only will you fail (it has been physically removed) you will bring Geocaching into disrepute with the local plod.

 

It was still showing as active in my database. This is a problem with archiving (to say nothing of unpublishing) without going through suspending for a period first, since PQ's don't show archived (or unpublished) caches, it is impossible to know there is a problem unless you look at the cache page on Gc.com.

 

While it wouldn't help with unpublishing, couldn't archived caches continue to be shown on PQ's for a period of, say, a month so that they get marked as archived on peoples GSAK databases?

Link to comment

While it wouldn't help with unpublishing, couldn't archived caches continue to be shown on PQ's for a period of, say, a month so that they get marked as archived on peoples GSAK databases?

I can understand what you are saying but this is an inherent problem with keeping a duplicate, offline, database. That's not to say I don't sympathise, my own GSAK database is also always out of date.

 

If you want to float the idea past TPTB you're better off posting it in the general forum - Geocaching.com Web Site.

Link to comment
Bingo! That's the reason and as the police were involved as well it was "unpublished" as well as being archived.

 

If anyone has this cache in their offline database I would urge you NOT to try and find it. Not only will you fail (it has been physically removed) you will bring Geocaching into disrepute with the local plod.

 

It was still showing as active in my database. This is a problem with archiving (to say nothing of unpublishing) without going through suspending for a period first, since PQ's don't show archived (or unpublished) caches, it is impossible to know there is a problem unless you look at the cache page on Gc.com.

 

While it wouldn't help with unpublishing, couldn't archived caches continue to be shown on PQ's for a period of, say, a month so that they get marked as archived on peoples GSAK databases?

Fairly easily resolved - Create a filter in GSAK to show all records that have not been updated in the last day (excluding Archived) - After doing a full update of your database run the filter and it will list all caches that were not updated and therefore archived - Use "Global replace to change the status of these caches to archived - All sorted :unsure:.

 

It is advisable to have a quickly scan through the filtered caches just to check that it looks sensible ie there are not a rather large amount of caches suddenly archived, although this may be the case the first time.

Link to comment

It was still showing as active in my database. This is a problem with archiving (to say nothing of unpublishing) without going through suspending for a period first, since PQ's don't show archived (or unpublished) caches, it is impossible to know there is a problem unless you look at the cache page on Gc.com.

 

While it wouldn't help with unpublishing, couldn't archived caches continue to be shown on PQ's for a period of, say, a month so that they get marked as archived on peoples GSAK databases?

 

This is one of the reasons why Groundspeak does not encourage offline databases. You'll probably have noticed that the only time you can get archived caches in a PQ is in the "My Finds" PQ. This may not be entirely coincidental.

 

GSAK is an add-on, and while there may be marketing reasons for Groundspeak to support people who use it (and/or any other add-on program, or not, on a case-by-case basis), there is certainly no moral obligation of any kind. Groundspeak provides a real-time snapshot of the geocaches in their database and that's it. Anything else you choose to do with that data is at your own risk, and it's not always trivial to spot the potential pitfalls.

 

The (relatively) safe way to manage an offline database in GSAK is:

- Set centre point to centre point of PQ

- Filter for the radius of your PQ

- Delete everything (except any additional WPs you may have added)

- Import the PQ

 

Alternatively, just import the PQ, but then look carefully at the "Last GPX" field and check all the ones which did not just update; they may not be archived but there's some reason why they weren't in the PQ.

 

FWIW, the problem of chasing up data which has been "deleted" - in a fairly wide sense of the term - is one of the tougher ones in real-world database design. (Another is the general problem of what to do with data as it changes over time...)

Link to comment
Bingo! That's the reason and as the police were involved as well it was "unpublished" as well as being archived.

 

If anyone has this cache in their offline database I would urge you NOT to try and find it. Not only will you fail (it has been physically removed) you will bring Geocaching into disrepute with the local plod.

 

It was still showing as active in my database. This is a problem with archiving (to say nothing of unpublishing) without going through suspending for a period first, since PQ's don't show archived (or unpublished) caches, it is impossible to know there is a problem unless you look at the cache page on Gc.com.

 

While it wouldn't help with unpublishing, couldn't archived caches continue to be shown on PQ's for a period of, say, a month so that they get marked as archived on peoples GSAK databases?

Fairly easily resolved - Create a filter in GSAK to show all records that have not been updated in the last day (excluding Archived) - After doing a full update of your database run the filter and it will list all caches that were not updated and therefore archived - Use "Global replace to change the status of these caches to archived - All sorted :unsure:.

 

It is advisable to have a quickly scan through the filtered caches just to check that it looks sensible ie there are not a rather large amount of caches suddenly archived, although this may be the case the first time.

I have this done and it works very well. As I import a number of PQs it's also a good test to make sure that they have all come across ok. I've saved them wrongly on a couple of occasions and this has spotted the mistake.

 

I like to go and download the gpx manually from the cache page then to get the archived log also and keep the full history of the cache :lol:

Link to comment

I hear the problem about caches being on your offline (GSAK) database. Which is why I run this cleanup macro every few weeks or so.

 

Its configurable to do a few things. I've configured my cleanup macro to delete caches that have not received a new GPX file (the file you receive from geocaching.com containing your queries) in over 3 weeks. NOTE: This does not mean caches that have been logged in 3 weeks or maintained in 3 weeks. Just caches that have not been refreshed from the main geocaching.com database in over 3 weeks.

 

As I've configured my PQ to only show active caches that I have not found, if after 3 weeks a cache has not been refreshed with the GPX file, it just gets deleted by the cleanup macro. This means I don't get annoying little cache pages going "Find me, find me" :lol::unsure:

Link to comment

From threads on retractions in other parts of the forums, I seem to recollect that it shouldn't affect anyone's find count.

 

No doubt a friendly reviewer will correct me on that in a moment.

There seems to be some doubt about what happens in this situation. The most recent official information I've seen is here.

 

Clearly, unpublishing a listing shouldn't cause the previous, perfectly valid, finds to be lost. Nor should any finds logged after the retraction (you don't want to come home from finding your 1000th cache only to see that your 999th was retracted. I'd really like to see a definitive statement from TPTB about this, but I won't hold my breath.

 

Another problem with retractions is that, even though it's an option for notifications, the logs are never mailed. This has also been pointed out to TPTB.

Link to comment

I agree with the above comments and do in fact do a periodic (once a month or so) clean up based on last GPX date. My point was that if the object of unpublishing a cache is to stop people going to look for it, it would be more effective if people knew it had been unpublished.

 

Whatever TPTB might wish happened, off-line databases are a fact of life, so why not accept the fact and do something to make the unpublishing of a cache more effective in achieving its object.

 

Another gap in the system is that I did get a notification that this cache had been archived (it's within my 20 mile radius for PQ's and notifications) but, presumably because it had been archived, I did not get a notification that it had been unpublished.

 

In summary if you want something to have an effect on people, it helps if you make sure people know of it.

Edited by Just Roger
Link to comment

Fairly easily resolved - Create a filter in GSAK to show all records that have not been updated in the last day (excluding Archived) - After doing a full update of your database run the filter and it will list all caches that were not updated and therefore archived - Use "Global replace to change the status of these caches to archived - All sorted :D .

I'm not certain but I suspect there may be a big-ish problem with this method. If your PQ has an unlimited radius and/or currently returns 500 caches (the upper limit) then whenever a new cache is published inside the PQ's area, another cache will 'drop off' the outer edge and won't be included in the GPX file - the new cache will take precedence over it because it's nearer the centre point. GSAK will then show the dropped cache as not having been updated and it could be mistakenly marked as archived.

 

Equally, as you find caches in that that area, dropped caches near the outer edge could re-appear in the PQ again, so you'd need an opposite filter to remove the archived status from those as they come back into range.

 

Dunno if I explained my thinking clearly or not :):D

Link to comment

I agree with the above comments and do in fact do a periodic (once a month or so) clean up based on last GPX date. My point was that if the object of unpublishing a cache is to stop people going to look for it, it would be more effective if people knew it had been unpublished.

 

Whatever TPTB might wish happened, off-line databases are a fact of life, so why not accept the fact and do something to make the unpublishing of a cache more effective in achieving its object.

 

Another gap in the system is that I did get a notification that this cache had been archived (it's within my 20 mile radius for PQ's and notifications) but, presumably because it had been archived, I did not get a notification that it had been unpublished.

 

In summary if you want something to have an effect on people, it helps if you make sure people know of it.

 

It seems that this cache was "retracted" (the Groundspeak word for "unpublished") so that it could be demonstrated to the police that it was no longer on display on the site. Even if people got notification of the archiving, there's no reason to believe that they would all act on that. So retracting is the best that could be done.

 

Retraction happens very, very rarely. Generally the reviewers do it quickly when they make a mistake in publishing a cache ("oops"). (One advantage of retraction over archiving is that the cache owner can edit their cache, for example to fix whatever problem the reviewer noticed just after pressing the "Publish" button.) So, since it's usually a reviewer mistake, I don't think that it's important to publicise it with instant notification. :unsure:

Link to comment

I'd half guessed the reason in view of the last log...

 

Does anyone know what happens to the find count of those that have done it? I'm almost certain it goes down, as the cache effectively doesn't exist anymore... Surely someone on here must have found it?! :laughing:

 

I appreciate that there isn't really much that can be done if the find count does drop - and it happens so rarely that its not really too much of an issue - unless you're one of the finders who's milestones have all gone wonky!

Link to comment

As soon as I read the comment about security guards, I knew which cache this would be. I am glad that it does not appear that my finds will go down by one, but not dismayed that this cache has now gone. I think I was a PAF for the cachers being chased about by the security guards on that day.

Link to comment

I can confirm after a few tests :P that a Retraction does not affect your stats, your just unable to see it unless your a Reviewer :P

Thanks for doing that, Dave :). That's good to know.

 

Now, if you could just find out why the notification system doesn't mail retractions even though it's an option, that would be even better :D.

Link to comment

As soon as I read the comment about security guards, I knew which cache this would be. I am glad that it does not appear that my finds will go down by one, but not dismayed that this cache has now gone. I think I was a PAF for the cachers being chased about by the security guards on that day.

Not guilty gov, although we were one of the last logs (if not THE last), it was a during a search a few weeks later by A.N. Other :ph34r: , that the real problem arose. Will say no more on the matter, it is clearly sensitive.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...