Jump to content

Changes to logging, specifically stopping double logs


duncanhoyle
Followers 18

Recommended Posts

A post on the GSAK forum today (http://gsak.net/board/index.php?showtopic=32259) suggests that there will soon be changes to the way that caches are logged. This will make it impossible to log more than one "Find", “Webcam Photo Taken”, "Attended", or "Will Attend" on a cache.

According to the post this will be in the API from May and on the website from mid Arpil (wasn't sure which sub forum to post in so I posted here).

 

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

Link to comment

A post on the GSAK forum today (http://gsak.net/board/index.php?showtopic=32259) suggests that there will soon be changes to the way that caches are logged. This will make it impossible to log more than one "Find", “Webcam Photo Taken”, "Attended", or "Will Attend" on a cache.

According to the post this will be in the API from May and on the website from mid Arpil (wasn't sure which sub forum to post in so I posted here).

 

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

As Duncan has said the GC45CC cache is very popular in the UK, with over 20,000 finds many of which are multiple logs for different locations. You just need to see the stats at http://www.yosm.org.uk/cacher_list.php to confirm this.

 

Mark Hughes

aka Orlando's Rat

Link to comment

I think this will put a stop to some issues that tend to generate a lot of whining, so that's probably good.

 

Just to be clear, we can log more than one different type of log on a cache, right? So I can't log "Will Attend" twice, but I can log "Will Attend" followed by "Attended" after the event?

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

So those appear to be similar to USGS benchmarks, which are not counted under the find count anyway. Perhaps someone can make their own method of logging finds on those survey markers and leave the cache finds for real geocaches.

  • Upvote 1
Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

So those appear to be similar to USGS benchmarks, which are not counted under the find count anyway. Perhaps someone can make their own method of logging finds on those survey markers and leave the cache finds for real geocaches.

 

They are similar but they do count towards the find count. However, they are virtual caches and MAY not be covered by this rule.

Link to comment

Finally!

 

Really pleased about this. The issue of accidental multiple-logging has got massively worse over the past few years, presumably from greater phone use and live-logging with poor signal. I'm quite tired of keeping my caches maintained by deleting multiple logs, so this is very welcome. (Also tired of some of the reactions of other cachers when I do so, even if I warn them first!)

 

YOSM is the exception. Maybe there's a way to allow it for specific caches, but even if not, this is a very good decision and one that should have been in from the start.

  • Upvote 1
Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

That won't be the case after April or May. One GC#, one find.

 

But I hope it will be implemented in a reasonable manner not as the handling of FPs. The system needs to allow a second find log if the first one got deleted.

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

That won't be the case after April or May. One GC#, one find.

 

But I hope it will be implemented in a reasonable manner not as the handling of FPs. The system needs to allow a second find log if the first one got deleted.

 

If your log is deleted I assume that counts as "you don't have one" and thus you can post one.

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

So those appear to be similar to USGS benchmarks, which are not counted under the find count anyway. Perhaps someone can make their own method of logging finds on those survey markers and leave the cache finds for real geocaches.

 

They are similar but they do count towards the find count. However, they are virtual caches and MAY not be covered by this rule.

 

That's my point. USGS benchmarks don't count (although I've seen a few virtuals placed at these locations). Perhaps they should have placed virtuals at these locations instead of trying to create one "catch-all" virtual for hundreds of different points.

 

If they aren't already, perhaps just set them all up on the Waymarking site if it's so important to log them.

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

So those appear to be similar to USGS benchmarks, which are not counted under the find count anyway. Perhaps someone can make their own method of logging finds on those survey markers and leave the cache finds for real geocaches.

 

They are similar but they do count towards the find count. However, they are virtual caches and MAY not be covered by this rule.

 

That's my point. USGS benchmarks don't count (although I've seen a few virtuals placed at these locations). Perhaps they should have placed virtuals at these locations instead of trying to create one "catch-all" virtual for hundreds of different points.

 

If they aren't already, perhaps just set them all up on the Waymarking site if it's so important to log them.

 

I totally agree with that reasoning. Just 15 years too late. Especially as virtuals are no longer allowed.

Link to comment

Totally agree with this for trad caches as there are a lot of duplicate entries out there and/or cachers finding their own caches but with the YOSM, a very popular cache that has been around for now over 15 years I do hope they make an exception as never do you visit and log the same monument twice, even though it is the same cache we have to visit a different location every time from Shetland to Cornwall so how can it possibly be put into the same category as duplicate log for same hide?

Link to comment

This (if implemented) would be a disaster for me and many others who rather enjoy collecting the different locations. Indeed, the top 5 YOSM hunters (GC45CC) have found over 400 of them which involves travelling the length and breadth of Britain and in many cases yomping up significant hills! I've got 116 which represents over 7% of my total finds!!! 640 Favourite points from 2500 cachers shows how popular they are; I'm sure the Canadian version is equally well loved!

 

Whilst I understand the idea of preventing multiple logging of a single cache, clearly these are all different, they just happen to be under a single cache code. It must surely be possible to exclude these two special ones!

Link to comment

First, I think it's a mistake to remove the ability for COs to log NM on their own caches. I use that to keep track of problems reported to me in various ways that aren't NM logs (mail, messages, on events, etc). In practice, if the cache doesn't have an NM log I *will* forget about the problem. Thus, it's useful to be able to write them for my own caches.

 

What I'd like to know is whether this change will also affect how the find count is done for people that have multiple logs on the same cache. In keeping with this change (and with how trackables work), I hope that only one find per cache will be counted from now on.

 

Also, the message talks about changes to the partner API. I assume the same limitations will apply to logs via the web interface on geocaching.com as well?

 

Apart from the NM bit this is a good change, long overdue.

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

So those appear to be similar to USGS benchmarks, which are not counted under the find count anyway. Perhaps someone can make their own method of logging finds on those survey markers and leave the cache finds for real geocaches.

+1

These coupla caches always seem to come up whenever an idea to stop numerous finds on one cache is formed.

The claim has always been, "it gives us (those not in the US) a means to log benchmarks".

Since they've never been counted as a find here in the US anyway, I find that reasoning arguable.

IIRC, most of those countries already have benchmark categories in Waymarking. :)

 

Curious how the moving caches are gonna fit in though...

Link to comment

 

The claim has always been, "it gives us (those not in the US) a means to log benchmarks".

Since they've never been counted as a find here in the US anyway, I find that reasoning arguable.

IIRC, most of those countries already have benchmark categories in Waymarking. :)

 

 

Not that I care about these caches. However logging does not mean that something counts as a cache find on gc.com.

The benchmarks can be logged via gc.com (no need to go elsewhere) and the number of logged benchmarks also is displayed on the

gc.com profile and not somewhere else. Moreover, the users can make use of a preexisting list of benchmarks while for waymarks if a location is not

yet on Waymarking someone would need to register it (and would need to comply with the rules of the waymark category). I never regarded Waymarking as replacement

for those who are attached to how things work here.

Edited by cezanne
Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

That won't be the case after April or May. One GC#, one find.

 

You have answered this very positively and very quickly.

May I ask as a Moderator of a forum how much of the decision making you are privy to, or what other roles you carry?

 

One would think on the two caches quoted that the Grandfathered rights associated with those caches would persist with all of the conditions with which they currently operate.

 

Can you answer will grandfathered types continue to operate with conditions unchanged.

Link to comment

First, I think it's a mistake to remove the ability for COs to log NM on their own caches. I use that to keep track of problems reported to me in various ways that aren't NM logs (mail, messages, on events, etc). In practice, if the cache doesn't have an NM log I *will* forget about the problem. Thus, it's useful to be able to write them for my own caches.

 

 

I agree, it seems odd to stop a CO logging a NM on their cache. I can't understand the logic why Groundspeak would want to stop that. I was about to do that today (and I still can, for now). Someone reported a cache of mine is a bit damp. They didn't see it serious enough to log a NM, but I will log one myself to remind me to check it.

 

I can understand the logic behind only one found it log per cache. I have logged more than one find on the UK "YOSM" cache and will be sad to see that end, but I understand the logic.

Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

That won't be the case after April or May. One GC#, one find.

 

Will this search for and destroy previous duplicates, or just prevent new ones? I know if one case.. a reoccurring monthly event that used the same GC# for a few years that should be exempted from deletion. ..and the old traveling caches that could be found again at a new location.

Link to comment

Curious how the moving caches are gonna fit in though...

I can't see this affecting moving caches. It affects logging the same cache multiple times, moving or not.

You can't?

If it affects logging the same cache multiple times, I'd think it has to.

- But with watches on most, there are very few that still abide by their agreed gameplan with Groundspeak anyway. :)

Link to comment

I have never really understood the logic behind the brass cap virtuals.

 

I think they really should have been locationless caches in the first place -- and therefore archived with the rest of them back in 2006. In which case, brass cap hunters from the UK and Canada should really view the last 11 years as a gift, rather than looking at this (arguably overdue) policy change as punishment.

 

But then, I've not found any brass caps in either country and have no plans to do so before May. Nor have I ever attended an event in those parts of the world where 40 event attendees leave 8 billion "attended" logs to account for temporary event caches. Nor intentionally logged multiple finds on any geocache. So I don't really care about the policy change, except to note that as a cache owner it will save me from having to ask those who accidentally double log our caches to pick which one they want to keep, and as a cache finder it saves me from accidentally leaving multiple finds.

Edited by hzoi
Link to comment

If you implement this please remember that some cache can be logged more than once, including the much loved http://coord.info/GC45CC in the UK and http://coord.info/GC43F3 in Canada.

 

That won't be the case after April or May. One GC#, one find.

 

You have answered this very positively and very quickly.

May I ask as a Moderator of a forum how much of the decision making you are privy to, or what other roles you carry?

 

One would think on the two caches quoted that the Grandfathered rights associated with those caches would persist with all of the conditions with which they currently operate.

 

Can you answer will grandfathered types continue to operate with conditions unchanged.

 

I'm not privy to any decision making as a moderator.

 

I haven't seen any mention of allowing "grandfathered" caches that have been logged multiple times to continue to be logged multiple times. I'd be surprised if this was allowed on any cache after that date, but I'm not involved in those decisions.

Link to comment

If it ain't broke don't fix it

But this was broke, and now they're fixing it :)

 

+1

 

I do not agree that disallowing NM and DNF logs for cache owners is fixing something which was broken.

Why shouldn't a CO log a DNF followed by some other log type if they could not find the cache?

Or log a NM if they realized that a cache needs maintenance to be done later?

 

Next time they disallow DNF logs once one has previously logged a find. (I have done that several times.)

 

It seems that more and more Find is seen as a way to increase a score counter.

 

If a newer community member cannot be expected to read logs and understand that it can happen that a CO logs a NM or a DNF, they rather should invest some time to read about geocaching than the COs should be forced to change their logging style.

Edited by cezanne
Link to comment

I have never really understood the logic behind the brass cap virtuals.

 

I think they really should have been locationless caches in the first place -- and therefore archived with the rest of them back in 2006. In which case, brass cap hunters from the UK and Canada should really view the last 11 years as a gift.

 

But then, I've not found any brass caps in either country and have no plans to do so before May. Nor have I ever attended an event in those parts of the world where 40 event attendees leave 8 billion "attended" logs to account for temporary event caches. Nor intentionally logged multiple finds on any geocache. So I don't really care about the policy change, except to note that as a cache owner it will save me from having to ask those who accidentally double log our caches to pick which one they want to keep, and as a cache finder it saves me from accidentally leaving multiple finds.

 

Ditto everything hzoi wrote. I think overall it's a positive. I doubt it will remove duplicate logs...seems like that would take more effort than they want to make.

Link to comment

GC43F3-Brass Cap Cache was created March 21 2002 at present has 20,202 finds

GC45CC-Ye Ole Survey Monuments was created March 25 2002 at present has 22,630 finds

GCA0D6-Stash n' Dash was created November 15 2002 at present has 1558 finds

GC4411 -LEAP FROG was created March 2 2002 at present has 384 finds

 

I have four caches that can be logged more than one time. How are the new changes going to affect these caches? All four were created early on in geocaching history to help promote geocaching. In the early days of geocaching in Alberta and the UK there was vast areas with very few caches to find.I started the The Brass Cap in Alberta and Ye Ole Survey Monuments in the UK and gave cachers in all areas something to find and a way to check the accuracy of their gps as well as taking them to locations they normally would not have seen. Stash n' Dash and Leap Frog caches were created to help promote caching in the City of Calgary.

I have maintained these caches for 15 years. All logs have been checked and if they are not logged as per cache log requirements they have been deleted or the cacher has adjusted them to conform with what was required.

The reason I have maintained these caches so many years is the logs and pictures I get on the pages. You will not find many "Found it" logs. Most are entertaining and amusing.

There has always been concerns with multiple logging Brass Cap and Ye Ole Survey Monuments caches which I have never understood as each location is separate.I have tried to add some history, a view a hike in most locations to add to the hunts.I have also been asked numerous times for a cap or YOSM to be placed near events.I am not sure if my caches are going to be affected by the new changes but will be watching with interest

Edited by outforthehunt
Link to comment

...and if the COs would have policed their caches and deleted duplicate logs this would not be a necessary step.

Preventing the problem from ever happening, is a lot better than having all the cache owners be responsible for cleaning up the mess afterwards. A lot of cache owners are hesitant to delete logs, due to the fact that a lot of finders don't understand what's happening, and get upset and angry at the cache owner. That is no fun for either party. Having the ability to write an explanation when deleting (which I think's been requested several times already), would help a bit. But for this particular issue, this definitely is the easiest and best solution.

 

I do not agree that disallowing NM and DNF logs for cache owners is fixing something which was broken.

Why shouldn't a CO log a DNF followed by some other log type if they could not find the cache?

Because if the CO can't find the cache, maintenance is needed. The "Temporarily Disable Listing" log type is approprierte when this happens. If the CO doesn't want to disable, you still have the option to leave a note.

 

Or log a NM if they realized that a cache needs maintenance to be done later?

As I see it, NM logs are a message from the finder, to the cache owner. If the cache owner realize that the cache need maintenance, you have "Temporarily Disable Listing" and "Write note" to use. For keeping track of which caches that need maintenance, a bookmark list is much better anyway.

 

Next time they disallow DNF logs once one has previously logged a find. (I have done that several times.)

I don't see any reason for them to do this. Just like you can write several notes, you can probably write as many DNF as you want.

 

It seems that more and more Find is seen as a way to increase a score counter.

This change is helping to keep the find count correct, I don't see how that can be bad...

Link to comment

http://gsak.net/board/index.php?showtopic=32259

 

We're emailing to inform you that we are making two important changes to the Partner API, both of which go into effect on May 8th, 2017.

 

Log Types:

 

The first area of change regards the log types supported by Geocaching. They include:

 

1. Cache owners will no longer be able to log a "Find", "DNF", "Webcam Photo Taken", "Needs Archived", or "Needs Maintenance" on their own caches.

 

2. Players will no longer be able to log more than 1 (one) "Find", “Webcam Photo Taken”, "Attended", or "Will Attend" per cache.

 

We believe that enforcing these will streamline the core logging structure of the game, resolve long-standing requests for these changes from our community, and reduce confusion for our newer community members.

 

I'm hoping that next week's Groundspeak newsletter lets GS members know about these changes.

 

Expecting to see an official notice in the Release Notes forum soon.

 

B.

Link to comment

First, I think it's a mistake to remove the ability for COs to log NM on their own caches. I use that to keep track of problems reported to me in various ways that aren't NM logs (mail, messages, on events, etc). In practice, if the cache doesn't have an NM log I *will* forget about the problem. Thus, it's useful to be able to write them for my own caches.

 

If a problem is reported to you, you could still disable the cache until you have a chance to fix the issue or confirm that the cache *does* have a problem. Using the search page you can easily select caches that you own and are disabled. It's not quite so easy to show all caches you have with a NM log.

 

 

Link to comment

http://gsak.net/boar...showtopic=32259

 

We're emailing to inform you that we are making two important changes to the Partner API, both of which go into effect on May 8th, 2017.

 

Log Types:

 

The first area of change regards the log types supported by Geocaching. They include:

 

1. Cache owners will no longer be able to log a "Find", "DNF", "Webcam Photo Taken", "Needs Archived", or "Needs Maintenance" on their own caches.

 

2. Players will no longer be able to log more than 1 (one) "Find", "Webcam Photo Taken", "Attended", or "Will Attend" per cache.

 

We believe that enforcing these will streamline the core logging structure of the game, resolve long-standing requests for these changes from our community, and reduce confusion for our newer community members.

 

I'm hoping that next week's Groundspeak newsletter lets GS members know about these changes.

 

Expecting to see an official notice in the Release Notes forum soon.

 

B.

 

I hope so too. I was a bit surprised to hear about this because the OP was able to cut-n-paste a post made in a separate, non-Groundspeak, forum.

Link to comment

It seems as though not much thought has gone into this. As you can see just from the posts on this thread, there are all sorts of exceptions for caches set up during the early days of caching that were approved of at that time. Perhaps Groundspeak should reconsider this.

 

Tear the bandage off, I say. Maybe painful at first, but the rare exceptions (which I still don't personally feel SHOULD be exceptions) don't really justify the frustrations that the multiple logging can cause.

Link to comment

It seems as though not much thought has gone into this. As you can see just from the posts on this thread, there are all sorts of exceptions for caches set up during the early days of caching that were approved of at that time. Perhaps Groundspeak should reconsider this.

 

Tear the bandage off, I say. Maybe painful at first, but the rare exceptions (which I still don't personally feel SHOULD be exceptions) don't really justify the frustrations that the multiple logging can cause.

 

To set a standard now and move foreword with it is good, but to go back and attempt to rewrite history will cause lots of problems.

Link to comment

It seems as though not much thought has gone into this. As you can see just from the posts on this thread, there are all sorts of exceptions for caches set up during the early days of caching that were approved of at that time. Perhaps Groundspeak should reconsider this.

 

Tear the bandage off, I say. Maybe painful at first, but the rare exceptions (which I still don't personally feel SHOULD be exceptions) don't really justify the frustrations that the multiple logging can cause.

 

To set a standard now and move foreword with it is good, but to go back and attempt to rewrite history will cause lots of problems.

 

Like I said before, I highly doubt they would delete existing duplicates. I don't see anything indicating they would do that. I'm certain they'll let existing duplicates stand and moving forward will just block new duplicates from happening.

Link to comment

GC43F3-Brass Cap Cache was created March 21 2002 at present has 20,202 finds

GC45CC-Ye Ole Survey Monuments was created March 25 2002 at present has 22,630 finds

GCA0D6-Stash n' Dash was created November 15 2002 at present has 1558 finds

GC4411 -LEAP FROG was created March 2 2002 at present has 384 finds

 

I have four caches that can be logged more than one time. How are the new changes going to affect these caches? All four were created early on in geocaching history to help promote geocaching. In the early days of geocaching in Alberta and the UK there was vast areas with very few caches to find.I started the The Brass Cap in Alberta and Ye Ole Survey Monuments in the UK and gave cachers in all areas something to find and a way to check the accuracy of their gps as well as taking them to locations they normally would not have seen. Stash n' Dash and Leap Frog caches were created to help promote caching in the City of Calgary.

I have maintained these caches for 15 years. All logs have been checked and if they are not logged as per cache log requirements they have been deleted or the cacher has adjusted them to conform with what was required.

The reason I have maintained these caches so many years is the logs and pictures I get on the pages. You will not find many "Found it" logs. Most are entertaining and amusing.

There has always been concerns with multiple logging Brass Cap and Ye Ole Survey Monuments caches which I have never understood as each location is separate.I have tried to add some history, a view a hike in most locations to add to the hunts.I have also been asked numerous times for a cap or YOSM to be placed near events.I am not sure if my caches are going to be affected by the new changes but will be watching interest

You have four caches that I'd argue should have been published as locationless and archived or modified back in 2006. You were allowed to keep them going 11 years longer than any other locationless caches. I'd say view that time as a gift. But, as above, I don't have a dog in this fight.

 

As far as how they will be affected, it appears that only one find would be allowed per geocacher, but I'll let Groundspeak answer that.

Edited by hzoi
Link to comment

I do not agree that disallowing NM and DNF logs for cache owners is fixing something which was broken.

Why shouldn't a CO log a DNF followed by some other log type if they could not find the cache?

Because if the CO can't find the cache, maintenance is needed. The "Temporarily Disable Listing" log type is approprierte when this happens. If the CO doesn't want to disable, you still have the option to leave a note.

 

There can be a sequence of logs and often there is (for example reenable and performed maintenance). For example, I could first log a DNF or a find and then a NM. With the same logic a CO can first log a DNF if he/she wants to.

There is no reason to forbid that

 

Or log a NM if they realized that a cache needs maintenance to be done later?

As I see it, NM logs are a message from the finder, to the cache owner. If the cache owner realize that the cache need maintenance, you have "Temporarily Disable Listing" and "Write note" to use. For keeping track of which caches that need maintenance, a bookmark list is much better anyway.

 

A bookmark might be the better way for you. For others it is not (apart from the fact that basic members cannot use bookmarks). Why should COs be kept from using NM in the same manner than others? Temporarily disable only handles major cases and not minor ones like the log book only has 6 free entries. Some cachers argue how important NM logs are as they also alert other cachers and are that notes do not serve the same purpose. If a cache owner takes over what cache visitors are not doing, why should they be forced to use a second account? (Which is the obvious way out.)

 

Next time they disallow DNF logs once one has previously logged a find. (I have done that several times.)

I don't see any reason for them to do this. Just like you can write several notes, you can probably write as many DNF as you want.

 

If they do not allow a cache owner to write a DNF, they might argue that if I have previously found a cache (say in May 2015) I cannot write a DNF log for it in March 2017.

It is this what I meant with regarding finds as "score counters". Then one might argue that once you received the award (the +1) why should you come up with a DNF log afterwards.

 

It seems that more and more Find is seen as a way to increase a score counter.

This change is helping to keep the find count correct, I don't see how that can be bad...

 

I do not care whether the find count of others is correct,.

Apart from that what I regard as bad is the big role of finds as a score counter and not as the message that someone has successfully completed a cache.

Link to comment

I do hope the old caches that can be logged in multiple locations are grandfathered in and an exception to the block on multiple logs is allowed. If they are destroyed then it would be a huge pity to lose such well loved caches. In fact in the case of the YOSM cache I know that there are many Cachers who primarily Geocache to find them and that finding other Geocaches are just a bonus to them.

 

Hill walkers have always been very fond of trig points as they are often on the highest points in an area with great views. Reaching a trig often signals the end of a great walk. Stopping at the top of a mountain or hill and taking your photo with the trig is almost obligatory in the UK.

 

I fully support the ban on multiple logs for most Geocaches, even though a lot of the problems could have been prevented by requiring loggers to answer a "Are you sure?" prompt and denying logs where the log text is an exact duplicate.

 

Let YOSM etc. be the exceptions that prove the new rule is a good one.

Link to comment

The way I see it, there are four reasons why a cache would get duplicate logs.

 

1. The finder doesn't know any better. Some newbie caches just don't yet understand the difference between a found it, note, or other logs.

 

2. A duplicate log was "accidentally" posted. This often due to a system glitch where the logger doesn't know if the Found It/Attended log took, so they post another one. Sometimes what happens is that user submits the log, the database is updated, but something goes wrong in constructing and returning the response that the log was posted.

 

3. The very few exceptions (Brass Cap, YOSM, or recurring events which re-use a GC code) where posting multiple found it/attended logs are legitimate.

 

4. The finder intentionally posts multiple found it/attended logs knowing full well that it's not considered to be an acceptable practice.

 

This topic has come up quite frequently in the past and my suggestion has been to just create a pop-up alert when the system detects that a previous Found It/Attended log has been posted. It would have some text something like: You have already submitted a "Found It" log for this cache. Submitting another Found It log may impact your geocaching statistics and is not generally an accepted practice [Link to Help Center Page].

Are you sure you want to submit another "Found It" log? [Accept] [Cancel]

 

That would likely eliminate almost all of the duplicate logs in the first two scenarios, would allow duplicates in the third scenario, and become an annoyance to finders in scenario #4.

 

 

Link to comment

First, I think it's a mistake to remove the ability for COs to log NM on their own caches. I use that to keep track of problems reported to me in various ways that aren't NM logs (mail, messages, on events, etc). In practice, if the cache doesn't have an NM log I *will* forget about the problem. Thus, it's useful to be able to write them for my own caches.

 

If a problem is reported to you, you could still disable the cache until you have a chance to fix the issue or confirm that the cache *does* have a problem. Using the search page you can easily select caches that you own and are disabled. It's not quite so easy to show all caches you have with a NM log.

 

When I disable a cache it's because it can't currently be logged. Typically, the box is missing, someone built a construction fence around the cache site or something like that.

 

An NM log is much wider than that. The log is wet, the camouflage is broken but the box is still there, etc. It's common that the cache is perfectly loggable even with a valid NM log, so I don't necessarily want to disable it, but I also don't want to forget about the problem.

 

It's pretty simple to scroll through the list of my hidden caches and check the ones with the NM icon. It's even simpler to use http://project-gc.com/Profile/NeedsMaintenance which will not only show me all my caches that have NM logs or are disabled, it also lists caches that have DNFs as their last log.

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...
Followers 18
×
×
  • Create New...