Need quick wway to delete "Took it to" trackable logs

[+Harry Dolphin]

I do not want my trackables to 'visit' every cache. I want them logged into caches where they are left. And then 'retrieved'.

Groundspeak talks about clutter, and yet permits this???

I need an easy way to delete every "Took it to" log for my trackables. It can take up to six steps to delete each 'took it to' log. This is time consuming to delete the meaningless drivel. Some 'took it to' logs are .06 from the previous 'took it to'???

This is meaningless clutter. There should, and must, be an easy step to delete the 45 'took it to' logs every .12 miles (or less).

Yes, I am posting "Do Not Visit this trackable" to my trackables. (Though why should I have to waste my time?!?)

I would also like to be able to delete multitudinal "Took it to" logs from my geocaches. But that would affect the cachers who track their personal TBs through every cache.

So, I am asking for an easy way to delete "Took it to" logs for my trackables. These logs are meaningless drivel that clog up pages. I must be at fifty 'delete' logs so far on one of my trackables. With no end in sight.

Perhaps a button on my trackable that says "This trackable cannot 'visit' caches'"

[+wmpastor]

Each person has an agenda for their TB's, & they should indicate it. Then finders should attempt to follow the owner's wishes.

 

In contrast to the above comments, I'm happy if a finder has my TB "visit" caches, & then places it after a while. To me, that's not "clutter." What's the difference if one person takes it to six caches, or six people do? I've had nice communications with two people who took my TB's on journeys before placing them.

 

Unfortunately, when TB's sit in caches (sometimes for months), muggles or n00bs can take them and lose them.

[+kunarion]

What's the difference if one person takes it to six caches, or six people do?

The six people had to put some thought into placement, each choose a cache safe enough for another cacher to pick up the TB (which worked great 6 times -- good job, people!), decent sized for a TB, and they actually placed the TB (so we know the TB definitely was at the same place as the caches). The one person made 6 logs.

Edited August 31, 2013 by kunarion

[+niraD]

So rather than:

 

2013-07-31 niraD took it to This Cache

 

2013-07-31 niraD took it to That Cache

 

2013-07-31 niraD took it to The Other Cache

 

You would rather see:

 

2013-07-31 niraD retrieved it from This Cache

 

2013-07-31 niraD placed it in This Cache

 

2013-07-31 niraD retrieved it from That Cache

 

2013-07-31 niraD placed it in That Cache

 

2013-07-31 niraD retrieved it from The Other Cache

 

2013-07-31 niraD placed it in The Other Cache

 

Is that correct?

[team tisri]

What's the difference if one person takes it to six caches, or six people do?

The six people had to put some thought into placement, each choose a cache safe enough for another cacher to pick up the TB (which worked great 6 times -- good job, people!), decent sized for a TB, and they actually placed the TB (so we know the TB definitely was at the same place as the caches). The one person made 6 logs.

 

I often think an occasional "took it to" lets the CO know that the bug is still alive and the holder hasn't forgotten it. I don't see the point in "visiting" every single cache you find - all that does is create a huge trail of logs that serve little purpose. Personally I've used "visit" logs if I'm holding onto a bug for a while so I can transport it internationally, especially if the bug is in a race to rack up miles and the owner is happy with "visited" logs.

 

I don't really think there's a whole lot of thought going into dropping off a TB. In an urban area it's far from rare for me to drop a TB into the first cache I find that's big enough to take a TB and looks like it might still be there next month. With so many micros and nanos it can be hard to move trackables on, especially if I've brought a few back from a trip and don't want to just dump them all in one place.

[+kunarion]

What's the difference if one person takes it to six caches, or six people do?

The six people had to put some thought into placement, each choose a cache safe enough for another cacher to pick up the TB (which worked great 6 times -- good job, people!), decent sized for a TB, and they actually placed the TB (so we know the TB definitely was at the same place as the caches). The one person made 6 logs.

 

I don't really think there's a whole lot of thought going into dropping off a TB. In an urban area it's far from rare for me to drop a TB into the first cache I find that's big enough to take a TB and looks like it might still be there next month.

You're right, but I was simply going with the story of 6 perfectly good TB transfers.

[+kunarion]

I often think an occasional "took it to" lets the CO know that the bug is still alive and the holder hasn't forgotten it.

There's no notification sent when a "took it to" happens. So the TB Owner still thinks the holder has forgotten it, til one day when the CO looks through the TB logs. By that point, the holder thinks the TB Owner has forgotten about it.

 

But at about "took it to" number 500, the bug was lost long ago, and all you're seeing is auto-logs from the holder's rogue App.

Edited August 31, 2013 by kunarion

[team tisri]

I often think an occasional "took it to" lets the CO know that the bug is still alive and the holder hasn't forgotten it.

There's no notification sent when a "took it to" happens. So the TB Owner still thinks the holder has forgotten it, til one day when the CO looks through the TB logs. By that point, the holder thinks the TB Owner has forgotten about it.

 

Ah, I'd assumed the owner would get a notification of it. It's been a while since I released a TB...

 

But at about "took it to" number 500, the bug was lost long ago, and all you're seeing is auto-logs from the holder's rogue App.

 

Possibly, but nothing would change if the cacher who lost a TB just checked it in and out the old way (as long as they wrote down the tracking codes so they could grab it back).

[+#Tenzin]

I would like Groundspeak to add a function that a TB owner can chose if he/she wants the "visited" option to be used or not.

 

I also had some TB visiting caches while it was already dropped somewhere. And I also have found a TB that was still visiting caches while I found that thing 3 days ago. My feeling is that some (not all!) just click a "took it to" automatic. I would rather disable the "visited" option.

 

Also there is no way for quickly deleating those logs, you need to do it manualy for every log.

[7rxc]

In my thinking the best suggestion was made way back when... to allow the owner to display what log types they want to see or not. In general, cache or TB logs belong to the person who filed them. I know that cache logs can be restored if deleted for spurious reasons, and have no doubt that if offended, a cacher could have legitimate 'visits' restored. That, since 'visits' are allowed by GS (they are provided on the list).

 

If you don't want to see them, then having the option to not see them is the better route.

 

Doug 7rxc

[+kunarion]

But at about "took it to" number 500, the bug was lost long ago, and all you're seeing is auto-logs from the holder's rogue App.

 

Possibly, but nothing would change if the cacher who lost a TB just checked it in and out the old way (as long as they wrote down the tracking codes so they could grab it back).

True. Refer to the six cachers story above. Six different cachers, six different caches, all documenting it correctly, that's a huge difference from one TB hijacker and his six blank logs. And now that the comparison is between 500 different cachers logging the TB through 500 caches vs. one guy and 500 logs, I'd be confident it is still in play.

Edited September 1, 2013 by kunarion

[+kunarion]

If you don't want to see them, then having the option to not see them is the better route.

I agree. Hide the view. Continue to allow cachers to fill the servers with thousands upon thousands of App-generated logs, don't delete the logs. Someday, Groundspeak will realize how huge a problem it is, and the issue will clear up like magic.

[+wmpastor]

If you don't want to see them, then having the option to not see them is the better route.

I agree. Hide the view. Continue to allow cachers to fill the servers with thousands upon thousands of App-generated logs, don't delete the logs. Someday, Groundspeak will realize how huge a problem it is, and the issue will clear up like magic.

Okay, let's agree to disagree. You see a problem, and I don't see a problem.

[+Kacher82]

I also had some TB visiting caches while it was already dropped somewhere. And I also have found a TB that was still visiting caches while I found that thing 3 days ago. My feeling is that some (not all!) just click a "took it to" automatic. I would rather disable the "visited" option.

I'm a little confused. If a TB is in your inventory, how is someone else posting "visit" logs?

[+kunarion]

If a TB is in your inventory, how is someone else posting "visit" logs?

The site doesn't always check if a log makes sense.

[+#Tenzin]

I also had some TB visiting caches while it was already dropped somewhere. And I also have found a TB that was still visiting caches while I found that thing 3 days ago. My feeling is that some (not all!) just click a "took it to" automatic. I would rather disable the "visited" option.

I'm a little confused. If a TB is in your inventory, how is someone else posting "visit" logs?

Like: Cacher A has a TB from another Cacher. And he "visited" a cache. Now he dropped it in that cache, but didn't click on "dropped" but "visited". Then I found that TB in that cache and I took it. Now Cacher A goes caching the next day again, and automaticly clicks every TB a "visited".

 

In the example I told I already found the TB and I was waiting until it got "dropped".

But it never was "dropped" online, only in real life.

In the mean while Cacher A says he "visited" another cache with the TB, but he doesn't have it anymore.

So the TB itself never realy "visited" that cache in real life.

Edited September 2, 2013 by #Tenzin

[+Thoric67]

Like: Cacher A has a TB from another Cacher. And he "visited" a cache. Now he dropped it in that cache, but didn't click on "dropped" but "visited". Then I found that TB in that cache and I took it. Now Cacher A goes caching the next day again, and automaticly clicks every TB a "visited".

 

In the example I told I already found the TB and I was waiting until it got "dropped".

But it never was "dropped" online, only in real life.

In the mean while Cacher A says he "visited" another cache with the TB, but he doesn't have it anymore.

So the TB itself never realy "visited" that cache in real life.

For these circumstances, GS provided the 'grabbed it (from somewhere else)' Option. So the new finder can heal the mistake of the dropper.

[+Walts Hunting]

So rather than:

 

2013-07-31 niraD took it to This Cache

 

2013-07-31 niraD took it to That Cache

 

2013-07-31 niraD took it to The Other Cache

 

You would rather see:

 

2013-07-31 niraD retrieved it from This Cache

 

2013-07-31 niraD placed it in This Cache

 

2013-07-31 niraD retrieved it from That Cache

 

2013-07-31 niraD placed it in That Cache

 

2013-07-31 niraD retrieved it from The Other Cache

 

2013-07-31 niraD placed it in The Other Cache

 

Is that correct?

 

I don't think so. The person with the traveler is not going to,do all those steps,for the caches he finds He might do,it once a day. That is what the op and I would rather see.

[+niraD]

The person with the traveler is not going to,do all those steps,for the caches he finds

As the saying goes, there's an app for that.

 

Before the "took it to" log type was created, people were already dropping TBs into caches and then retrieving them again. If the "took it to" log type is no longer available, then they'll go back to dropping TBs into caches and then retrieving them again. Except this time, they'll have smartphone apps or GSAK macros that allow them to do it more automatically. And trackable owners will get more email notifications.

[7rxc]

If you don't want to see them, then having the option to not see them is the better route.

I agree. Hide the view. Continue to allow cachers to fill the servers with thousands upon thousands of App-generated logs, don't delete the logs. Someday, Groundspeak will realize how huge a problem it is, and the issue will clear up like magic.

 

Well, I understand that you have identified a problem with the auto loggers gone awry. And that does need to be addressed. Still as long as GS provides visiting (and dipping) as legitimate logs when done properly, then for now the visiting will continue and should. However, perhaps something can be done to recognize the auto logs that you are concerned with. Even if it is as simple as tagging logs from devices that do autologging as such [AUTO] or something. It has been said that visiting was for Geocoins and their collectors at events. Perhaps as I've said before it is time to split trackables into TB's and TC's.. that being Trackable Bug and Trackable Coin. This would only be done at the reference number level... and used to limit the visit to those that wanted it in the first place, the high volume loggers. I'm not sure if it could be a retrofit to coins easily, but there should be no problem with new coins. Have an option on the trackable page to id which it is. Since they already know who purchase and use the Tracking numbers for coins, that might help select the right choice automatically. TB's wouldn't have it set to allow visits, or perhaps not to allow autologging but allow manually created visit logs. Anyway it's not a simple problem but could be done.

 

Doug 7rxc