Moratorium update

[+ChileHead]

Classic case of computer problem where this is indeed very hard. For most humans this is easy to work out whether they have qualified. I would conjecture there is rarely a dispute since it is not an exam and folks are likely to qualify by a considerable margin. It is no problem for a reviewer since they do not have to know all the animals to say this is an ok challenge.

 

I don't think the computer removes doubts since we are now beholden to the developer.

 

For most challenges put out by decent cache owners, you are right - probably rarely a dispute. There are challenge cache owners whose sole purpose with their cache is to dispute finds and nit pick. I can't say how many of these there are as I don't see what appeals sees, but I know it happens.

 

I'd rather see requirement very clearly defined in code to remove all doubt, and to remove the controlling cache owners.

 

And speaking as a developer, I believe everybody should be beholden to us. All bow down to the mighty code jockeys. We don't get the chicks you know, so give us something.

[+lillfiluren]

 

Also my best challenges are not easily checked on Project GC and I am not sure if they can be.

 

http://nhl.elrojo14.com

http://coord.info/GC54PQB

 

Or my two unchallenges I hoped to make into challenges.

http://coord.info/GC61AYB

http://coord.info/GC5RFFX

 

All four of the above can be validated by a project-gc checker (if you define the term "near" in the first challenge). It will take some effort to get the coordinates for all of the landmarks and write the code (there is as far as I know no existing script that verifies "find a cache near all of these coordinates"). An alternative is to define (almost) circular polygons around the coordinates of the monuments with whatever radius you want. That would make it possible to reuse the generic map-based polygon checker.

[+noncentric]

Even simpler. Find 10 caches with an animal in the title. The PGC checkers I've seen for this do not do this well.

 

What's an animal? Just a mammal, or any of the tens of thousands of insects? Who decides? What language? Can I use qen/pas/gos/pas/pes/hund/hond/koira/chien/can/kutya/hundur/cane/etc ... as they are all dog in other languages?

 

Forcing the use of a checker removes all doubts.

Classic case of computer problem where this is indeed very hard. For most humans this is easy to work out whether they have qualified. I would conjecture there is rarely a dispute since it is not an exam and folks are likely to qualify by a considerable margin. It is no problem for a reviewer since they do not have to know all the animals to say this is an ok challenge.

 

I don't think the computer removes doubts since we are now beholden to the developer.

Any animal that the challenge 'finder' includes in their 'Found It' logs is generally okay, as the CO's for such challenge caches can use their judgment. I have seen several where the finder indicates the animal that's in the cache name, even if the cache name is from another language. For example, if a cacher from Germany goes to the US and logs an Animal Challenge Cache in the US, then they can use German cache names that include animals in the German language. Could some cache finders complain about their Finds being deleted because they included an animal that the CO didn't agree was an animal? Sure. If appeals on Challenge Caches were not allowed then the burden of appeals would not exist. It's pretty disappointing that some cachers caused so much hassle that the entire caching community had to be changed.

[+lillfiluren]

Another minor problem with PGC that could become an annoyance, is the amount of time it takes them to get up-to-date find stats on your own account. If they at least allowed you to force an update to your find stats that would be nice. Or, better, allow you to upload the MyFinds PQ for the site to parse instead of using their own API access to hammer the GC database with Finds requests.

 

Project-GC data is typically up to date with a latency of 24-36h, but it allows you to trigger refreshes of your data with a manual request to speed up the process (click the "support" button in the top right corner and select "Self support"

[cezanne]

like old logs, elevation data etc (how do you think all the stats about elevation, logs etc. are made?). Project-GC just have to find a way to make it available to the challenge checkers. I guess that's going to happen rather quickly now.

 

Elevation gain is not available to project-gc. They just compute an estimated elevation of the header coordinates.

As old logs is regarded: the statement that there cannot be a checker for lonesome caches unless the API is changed, came from project-gc.

[+lodgebarn]

Classic case of computer problem where this is indeed very hard. For most humans this is easy to work out whether they have qualified. I would conjecture there is rarely a dispute since it is not an exam and folks are likely to qualify by a considerable margin. It is no problem for a reviewer since they do not have to know all the animals to say this is an ok challenge.

 

I don't think the computer removes doubts since we are now beholden to the developer.

 

For most challenges put out by decent cache owners, you are right - probably rarely a dispute. There are challenge cache owners whose sole purpose with their cache is to dispute finds and nit pick. I can't say how many of these there are as I don't see what appeals sees, but I know it happens.

 

I'd rather see requirement very clearly defined in code to remove all doubt, and to remove the controlling cache owners.

 

And speaking as a developer, I believe everybody should be beholden to us. All bow down to the mighty code jockeys. We don't get the chicks you know, so give us something.

 

Yes indeed I totally agree and I might have written a bit of code myself over that past 40 years , LOL.

Edited April 23, 2016 by lodgebarn

[+lillfiluren]

Also, considering that PGC doesn't 'read' Lab Caches, then challenges based on 'Milestones' will not align between geocaching.com and PGC. So, it looks like challenge ideas that are now 'eliminated' will be: challenges based on Milestones, challenges based on text names (animal names, food names, etc), challenges based on distance or elevation gained (usually proven by noting start/end points in qualifying logs), challenges like the cemetary challenge, what else?

 

Project-GC has access to elevation data for all geocaches in the world, so if a challenge is based on "elevation gained between caches found the same day" it could be calculated, it could even be calculated for parking coordinates I guess, but that would require some extensions of the current API. There is of course no way to positively know that the cacher had actually hiked between the caches, he could just as well have driven between them.

[cezanne]

I love challenges, and have found many, with many that I look forward to. Sadly some will go away, thats ok if it cleans up the garbage that I see as a player, and more of what I see as a reviewer.

 

Would you (and Rock Chalk, Keystone and others who stated that they are happy about the change) still be happy if the new rules were such that no or almost no challenge cache that you like can survive? In my experience there are not too many cachers who purely address issues in geocaching from an altruistic point of view.

 

It is funny how many discount the work because of what they have seen. This is not one or two people coming up with an answer and solution, this is very much a story of many people, and many groups going through the data that people provided.

 

I never denied anything of the above. I very early wrote that once again the mass has won.

 

The same mass due to which powertrails exist meanwhile and many other changes happened that I consider to be unfortunate.

The same mass due to which challenge caches have been restricted considerably over the years. (For example, challenge caches like achieve a certain minimum average T-rating or average D-rating would belong to the most interesting geocaching achievement in my opinion - finding as many caches as possible is not an achievement in my opinion.)

It's this lowest common denominator policy that destroys a lot of enjoyment for me - the same was true also when the event rules were modified and made almost every type of geocaching event that I enjoyed impossible as official geocaching event.

Edited April 23, 2016 by cezanne

[+noncentric]

Also, considering that PGC doesn't 'read' Lab Caches, then challenges based on 'Milestones' will not align between geocaching.com and PGC. So, it looks like challenge ideas that are now 'eliminated' will be: challenges based on Milestones, challenges based on text names (animal names, food names, etc), challenges based on distance or elevation gained (usually proven by noting start/end points in qualifying logs), challenges like the cemetary challenge, what else?

 

Project-GC has access to elevation data for all geocaches in the world, so if a challenge is based on "elevation gained between caches found the same day" it could be calculated, it could even be calculated for parking coordinates I guess, but that would require some extensions of the current API. There is of course no way to positively know that the cacher had actually hiked between the caches, he could just as well have driven between them.

Regarding the comment about knowing whether the cacher actually hiked is correct. But this is an integrity issue that we face with most caches that require extra effort. Puzzle caches, we can't know that the cacher actually solved the puzzle themselves. Multi caches, we can't know that the cacher actually visited all the waypoints. Even with a challenge that says 'find 10 virtual caches' we can't know the cacher actually 'found' all those caches and didn't just armchair log them. Challenge checkers won't fix integrity issues.

 

The elevation gain challenge I'm thinking of requires listing the starting coords (which of course the cacher could lie about) and then the cache found (which of course the cacher could also log a fake find on). The CO of such challenge is very good about monitoring each log and making sure the elevation gain amount is accurate. Of course, the CO cannot confirm whether the cacher is being honest in their report. I don't think we should assume that cacher's are lying. If we happen to discover that something is untrue, then we should have the option to 'not count' an entry, but without some reason to doubt the cacher then we should take their claim at face value. Anyway, I'm glad this particular challenge already exists and the checker requirement won't apply to it.

Edited April 23, 2016 by noncentric

[+Gill & Tony]

My son owns three "Lonely Cache" challenges, 5 years, 15 years and 50 years based on a minimum of 6 months per cache. To help him with this I wrote two GSAK macros, one to calculate the "Unfound days" for a found cache and one to display the results. You can see the output on my profile under the "special" Tab.

 

Based on my experience, it is impossible to fully automate the unfound days calculation, even with full access to the API.

 

The problem occurs when a cache goes unfound for more than the qualifying time and then gets two or more found logs on the same day. Without human intervention it is impossible to know whether the logs were all from a group of cachers who found the cache together or whether one person found it before the others.

 

My programming solution allows the user to provide a list of people (User IDs) with whom they cache frequently and then assumes that if all logs are within that group the unfound time is calculated. If one or more logs are outside that group then the unfound time is set to zero. The user then has the option to manually override the zero in the database.

 

It is possible to automate a compromise - allow all finds on that day or to deny all finds on that day. The latter, I suspect, would seriously annoy someone who hiked a long way to get the unfound time, only to have it denied because someone else arrived later in the day.

 

It isn't a satisfactory solution to use the log ID because the order in which people log their finds isn't necessarily the order in which they the found the cache.

 

Another problem is that, in Australia, as elsewhere, the time on the web site is usually one day early, so if I log a find today using the web site it gets yesterday's date while someone logging via the API gets today's date. So, even if the other cacher found the cache before me his log is dated after mine.

[+thebruce0]

Allowing all caches that mention in the description that a cemetery is visited is not any more subjective than if one would allow all caches that carry a (hypothetical - as it does not yet exist) cemetery attribute. Trust will always be needed.

Wrong - unless Groundspeak lets the API search by description text. Then, again, the challenge would be "caches with 'cemetery' in the description", not "caches that are in cemeteries". Are you catching the difference? The latter is not objectively verifiable. The former is. Attributes are. Word of mouth and honour system are not.

 

As I mentioned earlier, it's the wording of the challenge that is important. "Dive for 10 scuba caches" is not verifiable or valid. "Find 10 caches with the scuba attribute" is, even if it means they didn't dive. "Find 10 caches requiring >20km hikes" is not verifiable or valid. "Find 20 caches with the >10km attribute" is, even if it means they didn't hike >10km for each cache.

Find 10 caches where the cache description mentions that a >20km hike is involved is verifiable, but not by project-gc.

Once again, in this hypothetical scenario, the challenge would then be "caches with a distance listed in the description over 20km", not "caches that require hiking 20km". Is it semantics? Yes and no. The former is an example of a challenge description that matches what is being objectively verified; the latter is not.

 

A human CO who approves the cache has made a subjective judgement call. Of course a script cannot do that. And that challenge wouldn't have (shouldn't have) been published, because it's not objectively verifiable.

If you insist on it you could fix this by choosing the formulation "Find at least 10 caches where the cache description mentions that a hike of length >20km is involved". That's exactly the same type of thing as find 10 caches with the scuba attribute. In both cases the information can be false.

False information is always a potential issue, on any listing, in any context. This isn't about false information, it's about objectively verifiable information.

 

What's wrong with a CO depending on the seeker's integrity? That bothers me about the checker requirement: it prevents a CO from having a challenge cache with a requirement that only the seeker can verify, and then trusting seekers when they say they have. When I point to a list of caches that could reasonably result in hiking 20km and then say I hiked 20km to get them, it seems almost offensive to me that you or GS would step in and demand that the CO not believe me.

Hey I'm right with you. It would be great if we lived in an ideal world where a lax system like that would give rise to no disputes and problems. GS has gone with objectivity over subjectivity precisely because the latter gives rise to disputes (even if someone never sees them in their local region). It's unfortunate. But it makes sense.

 

For reference, this is your original argument:

Ok, I'm trying to wrap my head around what you're trying to infer from my comments...

My original argument: Pre-moratorium, challenge caches required verifiable properties in order to be published (eg, "night cache" challenge would be invalid unless defined as requiring certain attributes to identify qualification). "So nothing there will change". For your lonely challenge cache, it wouldn't be publishable because (as it appears) PGC cannot retrieve recent logs of caches to determine time since the Find previous to your own. The point: post-moratorium, challenges that require properties PGC cannot read won't be publishable.

 

You then quote me as if my argument changed, merely because I said "if Groundspeak changes its API". But this is precisely what I was saying above - without that change, un-measurable challenge requirements would still be invalid. If GS allows PGC to read log histories, or provides some form of flag for challenge caches that can be read by a checker, then yes, the lonely cache challenge could be published, or a challenge-cache challenge cache could be published, because the checker can objectively measure the properties that indicate qualifying caches.

 

When I said "So nothing there will change", the context was regarding objectively verifiable properties. That seems to not be changing, as per the checker requirement.

 

Based on my experience, it is impossible to fully automate the unfound days calculation, even with full access to the API.

 

The problem occurs when a cache goes unfound for more than the qualifying time and then gets two or more found logs on the same day. Without human intervention it is impossible to know whether the logs were all from a group of cachers who found the cache together or whether one person found it before the others.

That's an interesting problem. It sounds familiar though, and if I recall a solution was to go by date, not merely 'previous logs' (and you continue to describe in your comment). So take the date the person found the cache, then continue back to the previous find Date. That skips all the same-day group (and potentially non-related) finds. But you're right, there's no way to guarantee that the immediately previous finder(s) were far enough back to qualify the cache as lonely. But I believe the challenge wording would have to make that clear; in this case, that qualification is based on days between your find and the previous find date, not based on log order.

And, if someone in the group dates their log incorrectly and messes the others' checkers up, well, someone will have to get a hold of them and tell them to fix the date to match everyone else (I see this happen quite often )

 

---

Regarding the animal-name type challenge... What if a checker includes the ability for a CO to provide a list of allowable words? eg, when publishing, the CO might list off 100 allowable animals. Finder comes along thinking he qualifies, but finds that 3 of his animals aren't counted by the checker. He asks the CO if he'll allow these 3 animals; yes? CO just adds them to the list, for everyone to now use.

The checker owner doesn't have to do anything new; qualification text isn't hard-coded. So it's still up to the CO to decide what is allowable for text-based challenges.

Is that a feasible scenario?

 

Is there a like button in these forums?

Is there a forum feature request forum?

 

Thanks also to ChileHead, Rock Chalk, Touchstone, Keystone, et al, for taking the time to respond. Much appreciated, from some of us

 

And speaking as a developer, I believe everybody should be beholden to us. All bow down to the mighty code jockeys. We don't get the chicks you know, so give us something.

*standingovation*

Edited April 23, 2016 by thebruce0

[+pinkunicorn]

I would think that the challenge cache CO would work with the scripter/tagger both upfront and to address post-publication bugs through edits.

If a checker is written and that checker writer becomes inactive, maybe they become busy with other things or are otherwise unable to continue as a checker writer, then can another checker writer 'take over' the checker?

 

Take a look at the "Activity Log" on the Project-GC challenge checker page and you will see a pattern of regular maintenance and improvements of the checkers.

Is there an Activity Log for each individual checker? Can you point out where to find that, as I'm having a hard time finding such a link? Not sure I'm looking in the right place.

 

All the code of all challenge checkers on Project-GC is available to all challenge checker developers. Thus, if some checker developer loses interest and someone later finds a bug in code left by that person, they can just copy the code to a new checker script, fix the problem, and make a new checker from that.

[+pinkunicorn]

Regarding the animal-name type challenge... What if a checker includes the ability for a CO to provide a list of allowable words? eg, when publishing, the CO might list off 100 allowable animals. Finder comes along thinking he qualifies, but finds that 3 of his animals aren't counted by the checker. He asks the CO if he'll allow these 3 animals; yes? CO just adds them to the list, for everyone to now use.

The checker owner doesn't have to do anything new; qualification text isn't hard-coded. So it's still up to the CO to decide what is allowable for text-based challenges.

Is that a feasible scenario?

 

That is, indeed, how the already existing checker for words in cache names already works.

[cezanne]

Allowing all caches that mention in the description that a cemetery is visited is not any more subjective than if one would allow all caches that carry a (hypothetical - as it does not yet exist) cemetery attribute. Trust will always be needed.

Wrong - unless Groundspeak lets the API search by description text. Then, again, the challenge would be "caches with 'cemetery' in the description", not "caches that are in cemeteries". Are you catching the difference? The latter is not objectively verifiable.

 

It's not a question of the API. A human user can scan for text statements and can do so in various languages.

I had in mind statements saying that the cache or a stage is on a cemetery (in the cache description, not as a statement of the finder!) and not just mentioning the word cemetery in the description.

You will never be able to automate such a check.

 

Once again, in this hypothetical scenario, the challenge would then be "caches with a distance listed in the description over 20km", not "caches that require hiking 20km". Is it semantics? Yes and no. The former is an example of a challenge description that matches what is being objectively verified; the latter is not.

 

Yes, but it does not change that it cannot be checked by a project gc checker and that will very likely never change while it is easy to check for a human and is objectively verifiable (to use your term).

 

When I said "So nothing there will change", the context was regarding objectively verifiable properties. That seems to not be changing, as per the checker requirement.

 

A key change comes however from what the checker can check and what it amounts to do so even if in those cases where it is possible.

You make your decisions what is objectively verifiable also without using a machine and you make them quickly.

Edited April 23, 2016 by cezanne

[+noncentric]

I would think that the challenge cache CO would work with the scripter/tagger both upfront and to address post-publication bugs through edits.

If a checker is written and that checker writer becomes inactive, maybe they become busy with other things or are otherwise unable to continue as a checker writer, then can another checker writer 'take over' the checker?

 

Take a look at the "Activity Log" on the Project-GC challenge checker page and you will see a pattern of regular maintenance and improvements of the checkers.

Is there an Activity Log for each individual checker? Can you point out where to find that, as I'm having a hard time finding such a link? Not sure I'm looking in the right place.

 

All the code of all challenge checkers on Project-GC is available to all challenge checker developers. Thus, if some checker developer loses interest and someone later finds a bug in code left by that person, they can just copy the code to a new checker script, fix the problem, and make a new checker from that.

Thanks for the information pinkunicorn. If the checker writer copies the code to a new checker, then can the previous checker be deleted from PGC or does it always remain? It would be good if the previous checker could be deleted, or if the CC tag can be removed, to avoid any confusion with multiple checkers for the same challenge.

[+pinkunicorn]

Thanks for the information pinkunicorn. If the checker writer copies the code to a new checker, then can the previous checker be deleted from PGC or does it always remain? It would be good if the previous checker could be deleted, or if the CC tag can be removed, to avoid any confusion with multiple checkers for the same challenge.

 

The previous checker may well have other challenges using it. It may be that the checker has several modes of operation and that the bug only happens in one of them, so this scenario doesn't even mean that the old checker is useless, just that there are cases where it is. That said, a checker script can only be removed by the script author (or Project-GC itself, but we still would have to make sure that nothing else is using it). We are hoping to implement other ways of handling multiple checkers, like a voting system of some sort.

[+noncentric]

Thanks for the information pinkunicorn. If the checker writer copies the code to a new checker, then can the previous checker be deleted from PGC or does it always remain? It would be good if the previous checker could be deleted, or if the CC tag can be removed, to avoid any confusion with multiple checkers for the same challenge.

 

The previous checker may well have other challenges using it. It may be that the checker has several modes of operation and that the bug only happens in one of them, so this scenario doesn't even mean that the old checker is useless, just that there are cases where it is. That said, a checker script can only be removed by the script author (or Project-GC itself, but we still would have to make sure that nothing else is using it). We are hoping to implement other ways of handling multiple checkers, like a voting system of some sort.

Okay. I was thinking about how checkers have the GC code in the name of the specific checker. Is that based on "tags"? So, a specific script might have 10 'tags' because the script is used for 10 challenge caches. It's the same script, but it works for 10 different CC's because those CC's have the same requirement. Is that how things work?

 

If so, then it might be a good idea to let CC CO's remove "tags" if the script doesn't work for their challenge and another script is created instead. Not sure if that's feasible or not.

[+widdi]

I'm not very happy about the reintroducing challenge caches. Here in germany several cachers exaggerated them. The rules to be allowed for logging were so complicated, that some "crazy cachers" needed months to fullfill the rules. If I think about wasting petrol, time and disturbing nature for one cache and its rules? I think there is no ballance between fun and real life.

 

OK.. I use my ignorelist. But we have Cachers, that built up powertrails with challengecaches. I think, that will happen again in germany. If I think about the blocking of the old way. There were several cachers very sad, that their new "higher wider better challenge cache" could not be published any more.

Sure. it's a game. everyone plays it with his own rules and preferences. But... I think the biggest amount of cachers - loves easy, normal caches, normal riddles,....

The rules for challenges should define a framework, that the accomplishing of the demands should be less dangerous and done in a real timeframe. No one wins, if nature has to suffer from cachers without regard.

[+MartyBartfast]

 

If so, then it might be a good idea to let CC CO's remove "tags" if the script doesn't work for their challenge and another script is created instead. Not sure if that's feasible or not.

 

Not sure that would be necessary, as the definitive checker for the challenge will be the one linked to on the CC page, therefore all the CC CO needs to do is change the link on their page to the new checker.

[+eigengott]

I had in mind statements saying that the cache or a stage is on a cemetery (in the cache description, not as a statement of the finder!) and not just mentioning the word cemetery in the description.

You will never be able to automate such a check.

 

Actually it's pretty easy to do such a check. You just need a list of cemetery polygons and then test if a cache (or one of it's stages) is inside such a polygon.

 

OpenStreetMap is one possible source for cemetery polygons.

[+JL_HSTRE]

Not wanting people to find your cache to meet a challenge is like not wanting people to find your puzzle cache unless they solved it the way you intended.

 

Even if there were no Challenge caches people would seek rare D/Ts anyway. Filling your DT and Calendar grids are two of the most obvious personal challenges of geocaching.

[+Harry Dolphin]

And from the point of view of the finder of a challenge cache: I guess what I liked by far the most about this challenge cache

https://www.geocaching.com/geocache/GC4Y7WG_challenge-steiermark-13-bezirke

was preparing my list of qualifying caches and thinking about all the memories that came back.

I did not just list 13 arbitrary caches but tried to list very special ones. Several other cachers also reported how much they liked this aspect of being remembered about nice caches.

So while one could write a checker for that very challenge cache above, using the checker would take away a lot of the enjoyment brought to me by the cache (not only with respect to my own visit but in particular with respect to the list presented by the other visitors of the cache).

The output provided my project-gc can of course not take into account personal preferences.

 

I presume that I could still prepare a list of the caches I wish listed for New Jersey County Challenge. Though it would definitely not be the list that the checker would come up with. Likewise, when I go for the Blue Cache Challenge, I would list the caches that I want listed (which would be the ones not found in over a year. Just found one that had not been found in over three years!)

[+narcissa]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

[+narcissa]

Not wanting people to find your cache to meet a challenge is like not wanting people to find your puzzle cache unless they solved it the way you intended.

 

Even if there were no Challenge caches people would seek rare D/Ts anyway. Filling your DT and Calendar grids are two of the most obvious personal challenges of geocaching.

 

I think there are different reasons. When a cache suddenly becomes high traffic because of a challenge cache, it does tend to drag down the calibre of people finding it and puts the cache more at risk of false logs, damage, and other silliness. I'd be inclined to modify a cache listing to make it no longer qualify for a challenge that was attracting unsavoury characters to it.

[+NYPaddleCacher]

This might actually be a good example which demonstrates how some challenge caches are so complex that, perhaps, maybe they *shouldn't* be published. If a CC is so complex that a PGC can't be written to verify that one has completed it, then perhaps it's too complex to be published.

 

I'm pretty sure that the point of a Challenge caches isn't a contest to see who can create the most complex challenge cache.

 

Actually, that is already the case in the old guidelines. They include this bit of text: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document. A lengthy list of "rules" would be sufficient reason for a challenge cache to not be published."

 

Agreed. However, with this new version of Geocaching Challenges that no long becomes subjective. The reviewer doesn't have to make a decision on whether or not the challenge "should be easy to explain, follow and document" using some subjective interpretation of "easy". Instead, the complexity of the challenge is simply determined by whether or not a challenge checker exists for it.

 

 

[+NYPaddleCacher]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

 

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

[+Team Microdot]

Not wanting people to find your cache to meet a challenge is like not wanting people to find your puzzle cache unless they solved it the way you intended.

 

And?

[+Team Microdot]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

 

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

 

I always believed a challenge cache could not require finding a specific list of caches - but this suggests I was misinformed!

[+ChileHead]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

 

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

 

I always believed a challenge cache could not require finding a specific list of caches - but this suggests I was misinformed!

 

They can't. You can write a challenge checker for it, and a reviewer may have erroneously published such a challenge, but they were not allowed in the previous rules. I assume this won't change with the new rules.

Edited April 23, 2016 by ChileHead

[+Twentse Mug]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

 

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

 

So a bonus cache can be turned into a challenge cache?

[+Touchstone]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

 

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

 

So a bonus cache can be turned into a challenge cache?

Technically, probably not. That would be considered a pretty major change to the Listing page, which should require a new submission. A bit like changing the basis of a Puzzle Listing from one type of Puzzle to another.

 

Realistically, there's nothing that prevents people from setting up the polygon example above to check to make sure all the elements of the Bonus cache are fulfilled. I'm not all that familiar with the PGC site, so I'm not sure whether it would then be capable of spitting out the Final coordinates for the Bonus Final. I'm guessing there's probably a way to do that, kind of like the various Geocheckers out there.

[cezanne]

I had in mind statements saying that the cache or a stage is on a cemetery (in the cache description, not as a statement of the finder!) and not just mentioning the word cemetery in the description.

You will never be able to automate such a check.

 

Actually it's pretty easy to do such a check. You just need a list of cemetery polygons and then test if a cache (or one of it's stages) is inside such a polygon.

 

OpenStreetMap is one possible source for cemetery polygons.

 

I cannot believe that openstreetmap has polygons for all cemeteries worldwide and I cannot think of a checker which would check for all them either. I'm not even sure whether project gc can check for waypoints which are not hidden - if they are hidden the checker has not even a chance with this approach if all cemetery data is available. Some of the nicest cemetery cache I know have header coordinates outside the cemetery and the final outside of the cemetery, the stages are inside but not adressed by coordinates but by a way description to avoid having cachers run around with GPS-r devices in their hands on the cemetery.

[+Touchstone]

I had in mind statements saying that the cache or a stage is on a cemetery (in the cache description, not as a statement of the finder!) and not just mentioning the word cemetery in the description.

You will never be able to automate such a check.

 

Actually it's pretty easy to do such a check. You just need a list of cemetery polygons and then test if a cache (or one of it's stages) is inside such a polygon.

 

OpenStreetMap is one possible source for cemetery polygons.

 

I cannot believe that openstreetmap has polygons for all cemeteries worldwide and I cannot think of a checker which would check for all them either. I'm not even sure whether project gc can check for waypoints which are not hidden - if they are hidden the checker has not even a chance with this approach if all cemetery data is available. Some of the nicest cemetery cache I know have header coordinates outside the cemetery and the final outside of the cemetery, the stages are inside but not adressed by coordinates but by a way description to avoid having cachers run around with GPS-r devices in their hands on the cemetery.

Let's face it. The only serious drawback to this approach is that you haven't taken the time or initiative to figure it out. The pieces of this problem are all there to be assembled. The fact that you prefer a manual method over a more automated method does not exclude you from continuing you to use your manual method. The fact that a cache owner won't put these checkers in place is a failure of the cache owner, not the system.

[+eigengott]

I cannot believe that openstreetmap has polygons for all cemeteries worldwide

 

Yes, the data is likely inclomplete. But how is that different from the past situation? I claim that this cache is on a cemetery: http://coord.info/GC4RNE3 Prove me wrong! And no, that there's no cemetery on the map doesn't tell you anything. That the map data is incomplete is your premise (and I actually agree to that).

 

With a web-based checker things become much easier, as both owner and finders use the same criteria about what cache is on a cemetery: it's in an area flagged as "cemetery" in some map dataset pulled at some point in time. It really doesn't matter that the data is incomplete.

 

As to the technical details: polygon checking is pretty cheap. There are already checkers on project-gc.com which do this: http://project-gc.com/qa/?qa=4577/new-checker-counts-founds-inside-given-polygon Also you can "widen" polygons, so that they cover also everything, say, up to 80 meters around a cemetery.

Edited April 23, 2016 by eigengott

[+CanadianRockies]

This might actually be a good example which demonstrates how some challenge caches are so complex that, perhaps, maybe they *shouldn't* be published. If a CC is so complex that a PGC can't be written to verify that one has completed it, then perhaps it's too complex to be published.

 

I'm pretty sure that the point of a Challenge caches isn't a contest to see who can create the most complex challenge cache.

Actually, that is already the case in the old guidelines. They include this bit of text: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document. A lengthy list of "rules" would be sufficient reason for a challenge cache to not be published."

Agreed. However, with this new version of Geocaching Challenges that no long becomes subjective. The reviewer doesn't have to make a decision on whether or not the challenge "should be easy to explain, follow and document" using some subjective interpretation of "easy". Instead, the complexity of the challenge is simply determined by whether or not a challenge checker exists for it.

Even with a checker, it's possible for a challenge cache to be too complex to be explained succinctly in the cache listing page (and thus run afoul of the current challenge cache guidelines).

 

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

 

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

[+ShammyLevva]

.....

 

Checkers aren't infallible....

 

Lots of challenge checkers simply say if a user has qualified or not. I would request that checkers provide a list to the user of how they qualified...

 

and even when they do provide a list to the user of how they qualified.. they are not guaranteed to be correct.

 

This one for example..

 

http://coord.info/GC3GEPV

 

In order to claim this cache you must reach 666 Points exactly, No more, No Less.

 

According to the checker, I qualify.. and it gives me a list of the 20 caches I found which show how I qualify. Thing is, I didn't ONLY find 20 caches that day, I found 26.. so the checker has ignored 6 of my finds which would have taken me over the 666 tally.

 

 

I'll have a look, can you provide the link on the project GC forum where you reported the error please?

[+Team Microdot]

This might actually be a good example which demonstrates how some challenge caches are so complex that, perhaps, maybe they *shouldn't* be published. If a CC is so complex that a PGC can't be written to verify that one has completed it, then perhaps it's too complex to be published.

 

I'm pretty sure that the point of a Challenge caches isn't a contest to see who can create the most complex challenge cache.

Actually, that is already the case in the old guidelines. They include this bit of text: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document. A lengthy list of "rules" would be sufficient reason for a challenge cache to not be published."

Agreed. However, with this new version of Geocaching Challenges that no long becomes subjective. The reviewer doesn't have to make a decision on whether or not the challenge "should be easy to explain, follow and document" using some subjective interpretation of "easy". Instead, the complexity of the challenge is simply determined by whether or not a challenge checker exists for it.

Even with a checker, it's possible for a challenge cache to be too complex to be explained succinctly in the cache listing page (and thus run afoul of the current challenge cache guidelines).

 

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

 

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

 

Which raises concern that such a ridiculous challenge would be published?

 

Would any volunteer checker writer be willing to waste their time on such a pointless exercise only to see a cache published that nobody will ever care to find?

[cezanne]

Let's face it. The only serious drawback to this approach is that you haven't taken the time or initiative to figure it out. The pieces of this problem are all there to be assembled.

 

So how you do capture the case I mentioned which is quite frequent that stages are on a cemetery but no waypoints? How can a computer deal with that?

[cezanne]

Yes, the data is likely inclomplete. But how is that different from the past situation? I claim that this cache is on a cemetery: http://coord.info/GC4RNE3 Prove me wrong! And no, that there's no cemetery on the map doesn't tell you anything.

 

My formulation was that the description should mention that the cache or some stages are on a cemetery. That's not a map issue. Typically translation software is not good enough to do multi caches or mysteries but good enough to get a rough gist of what the cache is about if needed.

If a cache owner really has doubts in some case, he/she is free to ask other finders of the cache, and yes, I would do that if it I were the owner of such a cache. Such cases would occur however rather infrequently - I'd say for less than 1 out of 100 logs. Actually, there are many more cheaters when it comes to difficult puzzle caches. If I owned a cemetery challenge and a small fraction of the found it logs were not from cachers who properly qualified, I would lose less than with a setup which can be checked automatically.

 

With a web-based checker things become much easier, as both owner and finders use the same criteria about what cache is on a cemetery: it's in an area flagged as "cemetery" in some map dataset pulled at some point in time. It really doesn't matter that the data is incomplete.

 

It will be easier to decide in case of disputes. I would not call it easier as the result is not the same and in any case some of the nicest caches will be lost. It also leads to different logs when cachers just press a button and copy and paste their challenge fulfillment message from project gc into a log or when they actively remember their qualifying caches.

Those who see challenge caches only as a reward for some kind of "achievement" will not care - I do care however very much about logs.

Edited April 23, 2016 by cezanne

[+LFC4eva]

.....

 

Checkers aren't infallible....

 

Lots of challenge checkers simply say if a user has qualified or not. I would request that checkers provide a list to the user of how they qualified...

 

and even when they do provide a list to the user of how they qualified.. they are not guaranteed to be correct.

 

This one for example..

 

http://coord.info/GC3GEPV

 

In order to claim this cache you must reach 666 Points exactly, No more, No Less.

 

According to the checker, I qualify.. and it gives me a list of the 20 caches I found which show how I qualify. Thing is, I didn't ONLY find 20 caches that day, I found 26.. so the checker has ignored 6 of my finds which would have taken me over the 666 tally.

 

 

I'll have a look, can you provide the link on the project GC forum where you reported the error please?

 

I haven't reported the error anywhere apart from here. I didn't know there was a project GC forum until you asked the question.

 

I read somewhere else that this checker was telling people they qualified when they hadn't.. I thought they were mistaken because I thought it had told me I didn't qualify.. then I realised I had only used the GSAK macro previously. That one works fine.

[+Wet Pancake Touring Club]

Let's face it. The only serious drawback to this approach is that you haven't taken the time or initiative to figure it out. The pieces of this problem are all there to be assembled.

 

So how you do capture the case I mentioned which is quite frequent that stages are on a cemetery but no waypoints? How can a computer deal with that?

Challenges have always required action by two parties. The first party is the CO. Originally, they had to outline the rules. With the announcement from Rock Chalk, that has been redefined to mean that CO must outline the challenge rules in a manner that a computer can process. The second party is the cacher that want to log the challenge cache. They have always been required to prove that they met the rules. Now, they must prove that to a computer algorithm, rather than a person.

 

Looking at your cemetery challenge caches. Here's what is needed to prove it, using a computer algorithm. First, we need a set of polygons that show the locations of cemeteries. Difficult, but not impossible. The second is proof that the person doing the challenge was inside of the required number of polygons. That is the part that is currently missing from PGC. However, my GPS can produce a track file with waypoints. If I could upload that to PGC, then PGC would have all of the information needed. This idea keeps the onus on the CO of the challenge cache, and the person that is attempting to log the challenge cache. In this example, the amount of work required by the cacher may increase, but it was their choice to go after the challenge cache. No other parties need to be involved. Other CO's with caches in cemeteries will not need to add an attribute.

 

Almost all of the above discussion has been on the limitation of PGC, as it currently exists. So, when the moratorium is lifted, I doubt that the cemetery challenge cache as outlined above would be allowed. However, what I propose is technically possible. And, it is implied that PGC will not be the only approved online challenge checking web site. We could easily see a change to PGC, or another web site that could handle your cemetery challenge. It might also work for some the distance and elevation change caches. All it means is that challenges may require more work on the part of the cacher.

 

Does this idea solve all of the remaining cases? No. But it does allow a method for a cacher to prove they qualify for a challenge without any changes to caches. No new attributes, no new fields, no additional waypoints needed. Is it possible to 'cheat' with this method? Of course it is. But challenge caches have always had this problem, and I don't believe my solution would increase the likelihood of cheating.

[cezanne]

That is the part that is currently missing from PGC. However, my GPS can produce a track file with waypoints. If I could upload that to PGC, then PGC would have all of the information needed.

 

True but I do not believe that this will ever happen and the issue is also that then there is no connection to geocaches - you could upload a trackfile from a visit to a cemetery not related to geocaching and it could ell be that no cache leads to that cemetery. Of course by adding further levels of complexity you could finally design something that also takes care of this issue, but in the end it will be something very involved just to take care of one type of many challenges that are excluded by the new model.

 

Almost all of the above discussion has been on the limitation of PGC, as it currently exists.

 

That's quite natural. While we have been told that further rules from Groundspeak will be announced and that project gc is working on a system to allow new checker writers etc, there has not been a single piece of evidence that project gc will obtain more powers and that requirements like uploading tracks (something a lot of cachers have issues with) could ever be part of anything at gc.com.

 

Is it possible to 'cheat' with this method? Of course it is. But challenge caches have always had this problem, and I don't believe my solution would increase the likelihood of cheating.

 

I'm not concerned about cheating - it will happen anyway. I however think that such a system will never be implemented and will not get the green light from gc.com. Moreover, it's quite involved and a lot of time and effort has to be invested for things which are so easy to check manually.

[+Team Microdot]

Challenges have always required action by two parties. The first party is the CO. Originally, they had to outline the rules. With the announcement from Rock Chalk, that has been redefined to mean that CO must outline the challenge rules in a manner that a computer can process. The second party is the cacher that want to log the challenge cache. They have always been required to prove that they met the rules. Now, they must prove that to a computer algorithm, rather than a person.

 

Not quite.

 

The accessible find data of the cacher who wants to log the challenge cache must fulfill the criteria defined through the checker.

 

Strictly speaking this doesn't constitute any sort of proof and other than posting relevant logs said cacher is completely passive in this process.

[+ShammyLevva]

So I submitted my most intense challenge to PGC to see if they could do it. I am a little dismayed at the responses that went completely over my head. I don't know if any one is going to make one for me or if I am going to have to learn the code to figure it out.

 

http://project-gc.com/qa/?qa=10119/someone-help-with-checkers-caches-within-distance-challenges&show=10134#c10134

 

Truly great challenges that inspire you might very well be a thing of the past with this new requirement. Personally, I am not hopeful for the future of challenges. Especially given Groundspeak had 1 year to get this ironed out and here we are on Year+1Day without a resolution.

 

Challenges drive my caching. See my profile for my list of goals around some truly great challenge caches. http://www.elrojo14.com

 

That great challenges will no longer drive me to go on wonderful cache runs is kind of sad.

The sort of challenges you have outlined here are a wonderful way of getting people out caching. From writing a checker point of view they aren't impossible just a lot of work. What the guys at project GC were saying is that some of the wording is a bit vague from a checker point of view but doable.

 

For places within a distance of a place, the complication is what boundary do you mean. If you meant say within a mile of the coordinate at the middle of the location then that is a trivial check. If you meant, which I strongly suspect you didn't, within a mile of any physical point within the boundary wall of the location then that's more complicated as you would need to draw an outline around the physical boundary then extend it by 1 mile.

 

For the vast majority of the items in the list if you as the challenge author putting together such a challenge were happy that "Angelus Temple - any geocache within .5 miles" meant any geocaching within .5 miles of the centre of the temple then any challenge checker author could knock that up very quickly without watering down the challenge.

 

So in essence what the project GC guys are saying is for these sorts of challenges creating a checker needs the CO to be involved to confirm he's happy with the definitions. They were being very very picky as you had said within .5 miles of an area rather than within .5 miles of a point. So assuming you are wanting the challenge to be to visit an area rather than to measure precisely if the are .5 miles of a boundary line, then confirming you are happy with .5 miles from centre of object then that's fine.

 

Other criteria such as on Alcatraz island is made easier from a challenge checker if you take the centre point of the island and draw a circle round it so as to include the entire island. NOTE you don't have to go into such detail on the challenge page, just as long as you as the author sign off that this is acceptable way for the checker to work it would achieve the objective. Your challenge remains intact and you have a simple checker, within X miles of this point, within y miles of that point.

 

This is simply an example of where challenge setters communicating with checker writers can create really great challenges by understanding what is required of both sides. I hope this inspires you and that I've understood your intent and given you a solution that will help you understand what the project GC guys concerns were.

[+CanadianRockies]

This might actually be a good example which demonstrates how some challenge caches are so complex that, perhaps, maybe they *shouldn't* be published. If a CC is so complex that a PGC can't be written to verify that one has completed it, then perhaps it's too complex to be published.

 

I'm pretty sure that the point of a Challenge caches isn't a contest to see who can create the most complex challenge cache.

Actually, that is already the case in the old guidelines. They include this bit of text: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document. A lengthy list of "rules" would be sufficient reason for a challenge cache to not be published."

Agreed. However, with this new version of Geocaching Challenges that no long becomes subjective. The reviewer doesn't have to make a decision on whether or not the challenge "should be easy to explain, follow and document" using some subjective interpretation of "easy". Instead, the complexity of the challenge is simply determined by whether or not a challenge checker exists for it.

Even with a checker, it's possible for a challenge cache to be too complex to be explained succinctly in the cache listing page (and thus run afoul of the current challenge cache guidelines).

 

Suppose, for example, that I create a challenge cache (with a checker) that requires you to find 100 very specific types of caches. The first cache must be a Canadian puzzle cache found on the third Tuesday of January five days after you had found a U.S. EarthCache. The second cache must be a letterbox... Etc. Etc.

 

You can see how such a checkable challenge cache is too complex to be easily explained, followed, and documented. Reviewers still will have to make subjective judgment calls regarding this guideline.

Which raises concern that such a ridiculous challenge would be published?

If you care to reread my first sentence (especially the part that is now in boldface), you will see that I answered your question. No, such a ridiculous challenge would not be published -- neither pre-moratorium nor post-moratorium. I assume, of course, that Groundspeak doesn't drop their current guideline that: "The requirements for meeting the challenge should be succinct and easy to explain, follow, and document."

 

Some people might mistakenly believe that the checker requirement means reviewers no longer need to make subjective decisions about whether a proposed challenge is easy to explain, follow and document. My example showed that such decisions still will need to be made.

 

Would any volunteer checker writer be willing to waste their time on such a pointless exercise only to see a cache published that nobody will ever care to find?

No, most probably wouldn't. Which is why the current "succinct and easy to explain, follow, and document" guideline will probably continue to exist.

[+ShammyLevva]

Bad news is if you wanted to replicate it in your state, better start learning LUA.

 

That's not true, the responses to your query on Project-GC said there are already checkers (the LUA code) which will work for you. All you need to do is properly define the area for each zone.

And this is where a proper checker might help eliminate disputes: for example one of your criteria is within 0.3 miles of Lock Historic district, but is that from some nominal centre point - where is the centre?; or within 0.3 miles of the district boundary - where is the boundary line? so there's potential for dispute, a defined checker would eliminate that by forcing you to define precise boundaries for each criteria before setting the cache.

Click the link that says .3 miles from the Locke Historic District. It shows you a definite .3 radius from the center point of N 38° 15.034 W 121° 30.587. I already made very definite, specific requirements for this challenge. That challenge literally took me a year to get going with that much research and HTML. I guess I am just not excited to have to try and replicate all of that in LUA language.

If you can provide a file with three columns, first column a distance second column a Northing third column a Westing then writing a checker for this one becomes trivial.

[+ShammyLevva]

Either

1 look through a list of 25 caches, openning them all up on a map, to see if they covered on all the 25 islands

Or

2 click one link which says "MartyBartfast qualified for this cace on April 1st with these finds ...."

 

2 takes less than a second, 1 takes god knows how long.

I would estimate #1 would take about 5 minutes, max. If the CO's willing, what do you -- and everyone else in the world -- care whether that's how they do it?

Well that was a response to a specific point stating that a checker would be a wast of time, and I was just demonstrating that it would actually be a time saver.

 

As to the "what do you care bit", I don't care as I'm not a fan of challenge cachers anyhow, It's GS who care and they care enough to think something needed to be done. I'm just a bit tired of seeing all the moaning, wailing and gnashing of teeth over something for which we only have the vaguest details so far.

The checker for polygon-based checkers would require a lot of upfront effort on the part of the CO. They would have to define the boundaries of all the areas. In the Island Hopping challenge, which I am also hoping to complete, the CO would have to define the boundaries of ALL islands in the state. The challenge requires finding caches on only 23 islands, but there over 70 islands in WA that could be used as qualifiers. The time spent creating 70+ polygons to enable Option #2 may well exceed the time spent checking each Finder's list of caches in Option #1.

 

More importantly, I think it should be up to the CO which method of verification they want to use. With the new requirement, they'd HAVE TO create the polygons because the polygons are needed to create a checker. Imagine if the challenge was to find caches on 3 islands. The CO would still have to create the 70+ polygons and the incremental time compared to Option #1 would be even greater.

 

Also, consider that Option #1 does not require the CC CO to have the technical ability to define polygons, while Option #2 does require such knowledge.

The boundaries for ALL islands in the state already exist on Open Street Map no creation necessary.

[+ShammyLevva]

I'll wait and see how the challenge checker works on Noah's Ark Challenge (find thirteen pairs of caches wit a animal's name in the title.)

Will the checker be able to find the 'hen' in:

Hell's Kitchen's Kitchen!

POPS - Stonehendge

If it cannot, then LUA must be a shockingly poor programming language. In most languages, it's actually harder to find "hen" as a complete word.

The problem with this sort of challenge is not finding a word in a name that's trivial a CanadianRockies says. The problem is that the "list" of possible animals is endless, what language is the animals names in? What constitutes an animal, do birds, insects etc count? Challenges that have open ended lists are IMPOSSIBLE to write a comprehensive checker for. You can write a checker that does a decent job but it's only ever going to be as good as the list the checker author puts on the cache.

 

Thus open list challenges will almost certainly not be allowed as they cannot have a verifiable checker. To fix this a CO would need to define a list of valid words.

[+Team Hugs]

Would the new rules permit someone to base a challenge on a defined list of geocaches?

I saw a challenge checker that seemed to do that. It had a a list of qualifying caches (not that every cache in the list had to be found)

I always believed a challenge cache could not require finding a specific list of caches - but this suggests I was misinformed!

 

Depends on what you mean by a "specific list". One type of challenge cache I see frequently along these lines is the "Historical Caches Of [NAME] County", where the challenge is to find X% of the Y oldest caches in the county. That's technically a "defined list" of caches, but one with other objective measures involved.

 

And, out of curiosity, when this news broke a few days ago, I started poking around PGC and, yes, indeed, there are existing checkers for these sorts of caches already.

[+ShammyLevva]

I would think that the challenge cache CO would work with the scripter/tagger both upfront and to address post-publication bugs through edits.

If a checker is written and that checker writer becomes inactive, maybe they become busy with other things or are otherwise unable to continue as a checker writer, then can another checker writer 'take over' the checker?

 

Take a look at the "Activity Log" on the Project-GC challenge checker page and you will see a pattern of regular maintenance and improvements of the checkers.

Is there an Activity Log for each individual checker? Can you point out where to find that, as I'm having a hard time finding such a link? Not sure I'm looking in the right place.

You are misunderstanding how checkers work. The actual checker code is an open source piece of code that all of the checker authors can see. Multiple caches can be tagged against a script. Someone losing interest has no bearing on the checker as any checker author can simply copy the script and make an edit. Many checker scripts have been improved in this way over the years and thus caches are re-tagged with new improved checkers.

 

Because of this there is no specific activity log for each individual checker that regular users can see.