Jump to content

Moratorium update


Recommended Posts

The 10 hiking multi caches of length at least 20km ...

 

I assume the only way this could be valid is if the cache had posted parking coordinates, so that you could use the difference in parking & location to determine if it is > 20km. There's an attribute for > 10km, but not one for a larger number. Of course it gets complex if the posted coords were 1km from the first (public) waypoint of a 20km multi, as now a checker cannot be written.

Link to comment

Wow. That's sad. A fun and interesting would be disallowed because the list is open-ended. Sounds like programmer error to me.

...

 

So some fun challenges would not be acceptable because the programmer is incapable of providing a checker? Wow!

 

How would YOU program a computer to deal with a list of unknown items?

 

For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

Link to comment

Wow. That's sad. A fun and interesting would be disallowed because the list is open-ended. Sounds like programmer error to me.

...

 

So some fun challenges would not be acceptable because the programmer is incapable of providing a checker? Wow!

 

How would YOU program a computer to deal with a list of unknown items?

 

For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

 

I wondered how efficient searching that list could be from lua. If there was a sql or mongo type database a search of a large dataset would be quick. I assume there is no database in pgc other than cache data. Could an interpreted language like lua do? Does pgc have execution limits for scripts?

Link to comment

 

Which means there is a problem if the CO doesn't actively maintain the list.

 

Yes it does. That's going to be a part of challenge cache maintenance now, based on the type of challenge that is published. If one's not willing to do the maintenance, perhaps one shouldn't put out the cache in the first place. I'm pretty sure that goes for ANY cache, not just challenge caches.

 

Absolutely - people who aren't going to maintain caches as and when required shouldn't put them out at all - there's no perhaps about it.

Along with that, checker writers should agree to checker maintenance or else not write the checker in the first place. It hasn't been made clear yet how much PGC will open up to allow CC CO's to write checkers. In the current format, it's not as though any cacher can just write a checker and throw it up on PGC. There is a process in place to control who can create and/or tag checkers.

 

The key point is that as a CO for that sort of challenge you could not expect to just lie back and have everyone else do the work you would need to maintain a list of valid words. So the onus for those sorts of caches is entirely on the CO actively maintaining a list of valid words.

The onus is also on the checker writer to update the checkers they create for a specific CC. If a CO sends "here are more words to add to GCxxx checker", via whatever system is as yet to be implemented, then will there be an SLA for the checker writer to make those changes? I hope checker writers that agree to write checkers will understand the long-term commitment of writing a checker for a cache that can't continue to exist without the checker being maintained. Of course, many checkers won't need updating, so those would be the ones to write checkers for if a checker writer was unsure about the long-term commitment.

Link to comment

I find it funny how many posts here talk about word challenges, as they are mostly pretty mundane. Their checkers should be pretty easy to write and maintain, but requires effort on the CO to come up with the initial set of acceptable words. I haven't used lua, but am proficient in dozens of other langues (my background is compiler & language design), so I expect that a language like lua should be able to easily check if a cache title contains one word in a list.

 

I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

So far, the types of CC's that seem to be problematic are Lonely Cache, Elevation Gain, and Blackout challenges. I'm not sure what technical requirements would be necessary to enable PGC to 'see' the data necessary for such challenges.

Link to comment

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.

 

Wow. That's sad. A fun and interesting would be disallowed because the list is open-ended. Sounds like programmer error to me.

The nearby challenge cache asks for thirteen cache names which would cause a phobia problem: Example: Uranophobia: Fear of Heaven for: Pamachapura: Stone From Heaven.

So some fun challenges would not be acceptable because the programmer is incapable of providing a checker? Wow!

NO NO NO NO NO! The programmer is PERFECTLY CAPABLE of writing the checker. You have completely and utterly failed to understand what I wrote.

 

CHECKING a list of words is trivial.

PROVIDING the list of words isn't trivial.

 

So as a CO if you provide a list of valid words that meet your challenge then the checker can easily be written. If the list is open ended and the CO cannot provide a list of valid words then the checker will be incomplete.

 

The best compromise here is that the CO provides a long list of valid words and the list gets added to as enterprising cachers come up with new ones the CO sees as valid. These new words are then added to the checker. This is extra work but is achievable. The key point is that as a CO for that sort of challenge you could not expect to just lie back and have everyone else do the work you would need to maintain a list of valid words. So the onus for those sorts of caches is entirely on the CO actively maintaining a list of valid words.

 

Sounds to me that the programmer is incapable of providing the checker. As someone said: human minds work differently than computers. The programmer is incapable of providing the required checker. "Sorry. That challenge will not be approved because our programmers are incapable of providing the required checker."

Sad.

Link to comment

I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

Okay. Here's one of my favorite challenge caches: Week Streak Challenge Series #11: Fizzy Filler. You start by selecting seven of your least filled Fizzy grid cells. (Usually you don't have exactly seven cells tied for least filled, so you must manually choose some or all of the ones you will go after.) Then, on seven consecutive days, you must find a cache that is from each one of those seven selected cells. I suppose you could write a checker if the listing page required that your last "Write note" log be strictly formatted, such as: "Selected: 3.5/5.0, 4.5/1.0, 5.0/3.0, 5.0/4.5, 3.0/4.5, 4.0/5.0, 4.5/5.0". But what if someone accidentally uses tab separators instead of commas separators or omits a ".0" or uses a capital "Oh" instead of a zero or uses a lowercase "el" instead of a one or uses a comma instead of a period as the decimal mark? I can see that increasing the number of appeals if a Project-GC checker rather than a cache owner determines which geocachers successfully complete the challenge.

 

Here's another. I have a Meta-Challenge that requires you to find at least 100 other challenge caches. Since GC currently doesn't have a "Challenge" cache type or "Challenge" attribute, there's no viable way Project-GC checkers can infallibly distinguish between challenge caches and, say, a desktop puzzle cache that happens to have the word "challenge" in its title.

 

I'm currently working towards completing the "Washington Puzzler's Challenge - Irish Style." It has a similar issue as my Meta-Challenge challenge in that it requires geocachers to find caches that have "a puzzle to be solved to generate coordinates for the cache." GC has the "?" cache type, but that category includes many non-puzzle types of caches.

Edited by CanadianRockies
Link to comment

I find it funny how many posts here talk about word challenges, as they are mostly pretty mundane. Their checkers should be pretty easy to write and maintain, but requires effort on the CO to come up with the initial set of acceptable words. I haven't used lua, but am proficient in dozens of other langues (my background is compiler & language design), so I expect that a language like lua should be able to easily check if a cache title contains one word in a list.

 

I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

So far, the types of CC's that seem to be problematic are Lonely Cache, Elevation Gain, and Blackout challenges. I'm not sure what technical requirements would be necessary to enable PGC to 'see' the data necessary for such challenges.

There's also the question of whether animal-, food-, and other word-type challenges will be required to have a fixed list of acceptable words or will be open to other acceptable words if they come to light.

 

A similar issue arises with certain souvenir challenges, such as the Souvenir Triathlon Challenge. This challenges requires souvenirs from three non-U.S. countries, from three U.S. states, and for three special dates/events. But GC doesn't currently categorize its souvenirs. So, unless GC's new checker guideline allows for open-ended lists that can be modified in the future, there isn't an infallible way for a Project-GC checker to validate this kind of challenge.

 

And a similar issue occurs with some trackable challenges, such as Utah's Trackable Icon Challenge. Humans are pretty good at determining whether a geocoin belongs to categories such as Woodstock, Civil War, volunteers, national parks, benchmarks, etc. But a Project-GC checker will need to rely on an open-ended list that is constantly being updated.

Link to comment

How would YOU program a computer to deal with a list of unknown items?

I guess that's not my problem. It's up to the programmer to come up with the solution. This sounds like "I can't count above ten, so you cannot require more than ten caches." If a programmer cannot come up with the solution, that's the programmers problem. It's a simple Challenge Cache. So far, everyone has supplied the required list.

Right, though in theory the programmer could make a sort of auto-lookup and AI that could analyze the text content and cross-reference words with their definitions, then decide whether a title contains a valid word/phrase and qualify :P But now you're emulating a human checker, and much more prone to error or disagreement with false positives/negatives.

Definitely much easier, as first mentioned waaaaay back in this thread, to program the checker with a custom input list that each CO can provide with their cache. It would be like an "Animal name checker", where the script is open-ended, but parses a list input. Various COs could provide different lists - perhaps one CO wants a list of mammals, so provides their list of [currently] acceptable animals, which of course can grow over time as new finders ask the CO if 'this animal' not on the list can be accepted, which if the CO agrees he can add it to the 'tag', or whatever. Another CO might use the checker script with a custom list of known fish species. Another of birds. etc.

One step better - perhaps the checker author could maintain a list of every animal that all CC owners' caches have approved, and COs could use that global list as a launching point when they design their challenge with their valid word list.

Lots of possibilities. If GS and PGC build in some little bonus features :P

 

But, such challenges can't be worded as "find 100 caches having an animal name it their title" - since that's an open-ended challenge. The description of the challenge would have to explicitly list what words are accepted [currently], and that if a finder has a request for a new animal, to contact the CO and ask to add it to the list. Technically, this is what we do right now with an "open ended" challenge like this. Finder provides the cache list, and the CO reviews to determines if the person qualifies, even with new words. Post-moratorium, this would just become more automated, with a bit more work on the CCO part.

That way, if the CCO is unresponsive, then the challenge description can remain as is: A list of valid words that can be used to qualify. Have a word not on the list? No qualify.

 

Once it's verified, the CO adds it to the list and doesn't have to worry about translating again.

How do you think that such a challenge would be worded? I'm quite convinced that the cache description of future challenge caches will need to be very precise what is allowed and what not.

"Bird name challenge"

- Find 100 caches with bird names in the title, single or plural. Valid names include:

[ Chicken, Blue Jay, Goose, Geese, ...... , Eagle ]

* If you have a bird name not in the above list, contact me [the CO] and I may approve it and add it to the list.

 

Hmmm.... Interesting idea. I'm almost sorry you brought it to everyone's attention. One could satisfy the GS requirement by having a challenge cache requiring animal names, supplying a checker that checks for "dog", "cat", and "cow" to satisfy the GS requirement, then the CO would just manually check the list every time without worrying about the fact that the checker is dismally inadequate. Sounds like a good plan to me, but now that it's on the table, I'm sure the final announcement with have verbiage to guard against this affront to the new standard of antagonistic requirement checking.

Again, if the wording matches the challenge checker, I don't see a problem with it at all.

If the wording says "any animal name", but the checker examines from a specific limited list, then there's a problem with the challenge ('and is subject to archival', as they say). But if the challenge lists what is accepted and doesn't imply that more is acceptable (unless/until added to the list), then the challenge would be valid.

 

And another problem if 'actively maintains the list' becomes a euphemism for 'disagrees with the finder over an item the finder wants adding to the list'. Then you're back to disputes and possibly even Needs Archived logs on the basis that the CO isn't maintaining the list.

Not if the wording is easily understood as "valid words include" rather than "any word of type..." (when it's actually checking a limited list).

 

As has previously been suggested though, there's nothing stopping CO's who can't be bothered to maintain a checker simply accepting all finds whether they qualify or not. They might even state same on the cache page - editing post publication if necessary.

And this would put the challenge 'subject to archival'.

Link to comment

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).

No, you're not understanding. If the challenge says "with [selection of words] in the description", then that is accurate to what the checker says. No one can verify if a "cache is in a cemetery" - a human checker has to trust the either some waypoint of a cache was in the cemetery boundary, or the posted coordinates are in fact inside a cemetery boundary, and regardless of what the satellite imagery may show (if it's even high-res enough). None of that is [currently] objectively verifiable. BUT, if the challenge states "must have 'cemetery' in the title or description", a checker can run that and objectively verify.

 

Even if titles and descriptions can be edited, what's being checked is accurate to the challenge description and objectively verifiable. "Hike 100km" isn't objectively verifiable. Nor is "Find 10 caches that require hiking 20km", nor "Find 50 caches with some part within a cemetery", and so on.

 

If the API has access to the data required to analyze and provide a response to a challenge [even if it's something GS may open to PGC in the future], and the challenge description accurately describes what is being checked, then that is a valid challenge that can be published. And I think that's part of what caused the big headache for appeals on publishing - interpreting the challenge description compared to what is (and can be) actually checked and verified. "Find 10 library caches" has no way of being verified. In any manner. "Find 10 caches with 'library' in the title" can, but there's no guarantee that qualifying caches are actually 'library caches'. The former is an examble of a challenge could never be considered valid, fundamentally, unless GS adds for example a 'library cache' attribute. Even then, the challenge would need to be understood as "with the 'library cache' attribute", not "caches in a library".

 

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.

Except that there are thousands upon thousands. Does OSM have an API ability to check a supplied GPS coordinate against some parameter like 'cemetery boundary'? Or would the challenge writer and/or CCO need to maintain a list of acceptable cemetery boundary IDs? The latter would be ridiculous.

 

But that raises an interesting point - if PGC allows coders to call other external services by API, then it could theoretically be possible to incorporate other location-based databases within challenges. A checker would send a user's found caches' coordinates to this '4th party' service to determine if enough qualify. Of course if that last service changes or becomes inaccessible, both the CO and the challenge author would need to be on the ball to make adjustments since the challenge checker would be 'broken'.

 

For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

Bingo! Do PGC scripts allow calling external APIs?

 

Also, presumably the challenge cache listing would have to reference the data source of acceptable animal names that the checker uses, so that finders can check for themselves as well.

 

The 10 hiking multi caches of length at least 20km ...

I assume the only way this could be valid is if the cache had posted parking coordinates, so that you could use the difference in parking & location to determine if it is > 20km. There's an attribute for > 10km, but not one for a larger number. Of course it gets complex if the posted coords were 1km from the first (public) waypoint of a 20km multi, as now a checker cannot be written.

Do challenge checkers currently have access to additional waypoints?

That could be a good way to check distances. And rather than the challenge reading "Hike 100km for caches", it could be worded as "Find caches where total distance between waypoints (sorted by code) sums to over 100km" (but this also means qualifying caches would only include those with multiple public waypoints indicating the route - so likely a very limited list of qualifying caches, but at least something that would be verifiable by cache data). Cezanne could even gather people who like those special kinds of lengthy hiking caches and encourage COs to add indicative waypoints so that the checker can objectively verify qualifying caches.

 

Sounds to me that the programmer is incapable of providing the checker. As someone said: human minds work differently than computers. The programmer is incapable of providing the required checker. "Sorry. That challenge will not be approved because our programmers are incapable of providing the required checker."

Sad.

Sounds like the sound you're hearing is pretty limited. The request is to have a programmer program a script that would check and verify an open (non-existent) list of every possible animal name known to mankind, and thus in more than one language. Incapable programmer? Of course. But you're comparing to a human who 1] has a large list of animals already hard-coded in their brain-script, and 2] has the mental capacity to cross-check unknown words manually and make a judgement call, even adding the new animal to the list in their brain-script. This human isn't checking cache titles an "open list". That is literally impossible. So a PGC script, just like a human, would have to 1] have access to a list provided either by a CCO or hard-coded by the script author, or 2] have the ability to analyze and cross-reference words to an external source (also a list) automatically.

That phrase: "Sorry. That challenge will not be approved because our programmers are incapable of providing the required checker" is indeed valid if the challenge being coded implies "any animal name".

But as described by coders, provide a list of valid words and the checker can be written. Even better, if PGC can call another external API service to check words, then at least that's still feasible and a step closer to an "open list".

Link to comment

Okay. Here's one of my favorite challenge caches: Week Streak Challenge Series #11: Fizzy Filler. You start by selecting seven of your least filled Fizzy grid cells. (Usually you don't have exactly seven cells tied for least filled, so you must manually choose some or all of the ones you will go after.) Then, on seven consecutive days, you must find a cache that is from each one of those seven selected cells. I suppose you could write a checker if the listing page required that your last "Write note" log be strictly formatted, such as: "Selected: 3.5/5.0, 4.5/1.0, 5.0/3.0, 5.0/4.5, 3.0/4.5, 4.0/5.0, 4.5/5.0". But what if someone accidentally uses tab separators instead of commas separators or omits a ".0" or uses a capital "Oh" instead of a zero or uses a lowercase "el" instead of a one or uses a comma instead of a period as the decimal mark? I can see that increasing the number of appeals if a Project-GC checker rather than a cache owner determines which geocachers successfully complete the challenge.

I would love to see the ability for PGC to request user input! A few of my SQL queries to check complex challenges have custom parameters added, especially with multiple queries where I choose certain values from prior results. In a case like this, the script checker could request seven valid D and T combinations (not a free text entry) which would be used to check qualification. If PGC could add that level of flexibility in the scripting system, that would do wonders for challenge explanations, flexibility, and creativity.

 

Here's another. I have a Meta-Challenge that requires you to find at least 100 other challenge caches. Since GC currently doesn't have a "Challenge" cache type or "Challenge" attribute, there's no viable way Project-GC checkers can infallibly distinguish between challenge caches and, say, a desktop puzzle cache that happens to have the word "challenge" in its title.

Was the meta challenge published before restrictions on requirements? Doesn't sound it would have been published under near pre-moratorium guidelines, because as described, the 'task' required would be somewhat subjective. You could require 'Other' types with 'Challenge' in the title, but that would be it. So I'm honestly wondering how the challenge was published as worded (other than by reviewer exception) as I don't think it would have passed muster by the most recent publish rules.

 

I'm currently working towards completing the "Washington Puzzler's Challenge - Irish Style." It has a similar issue as my Meta-Challenge challenge in that it requires geocachers to find caches that have "a puzzle to be solved to generate coordinates for the cache." GC has the "?" cache type, but that category includes many non-puzzle types of caches.

Same as above, I don't think a 'puzzle' challenge cache would get published, since 'puzzle' cache vs 'challenge' isn't explicitly detailed (other than by Unknown+"Challenge"). And what about field puzzles? And, do multis count when there's a puzzle included in the text? Seems too vague a challenge requirement (to get published pre-moratorium) since it would require a lot of human subjective judgement calls.

 

That said, I do still very much hope that part of the as yet unexplained updates to CCs includes a parameter of some form that explicitly identifies a challenge cache.

Link to comment

I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

Does Project-GC have access to the Waymarking.com database? If not, then it would be problematic for their checkers to handle most Waymarking challenge caches, such as: Waymarkable: Quasy Challenge Cache 2 of 8 (visit 100 Waymarks).

 

How about geocaching.com's benchmark database? If not, then there could be issues validating certain kinds of benchmark challenges, such as: Challenge of a Century: AlphaNumeric BenchMarks (includes finding 33 benchmarks with numeric-only designations).

 

Certain challenges exclude caches that you used to fulfill another challenge cache(s). For example, Pan-Saskatchewan Geo-Challenge II and Mapsheets AB, final Triple Crown Jewel Challenge. Project-GC checkers would have a very difficult time trying to parse some lists of caches that you used to qualify for a previous challenge(s).

 

Some challenge caches allow teams of geocachers to jointly qualify for a challenge, such as: 10,000 Finds Challenge with a Twist. Can Project-GC checkers prompt the user to input a list of geocachers whom they teamed up with on a certain day?

Edited by CanadianRockies
Link to comment

Okay. Here's one of my favorite challenge caches: Week Streak Challenge Series #11: Fizzy Filler. You start by selecting seven of your least filled Fizzy grid cells. (Usually you don't have exactly seven cells tied for least filled, so you must manually choose some or all of the ones you will go after.) Then, on seven consecutive days, you must find a cache that is from each one of those seven selected cells. I suppose you could write a checker if the listing page required that your last "Write note" log be strictly formatted, such as: "Selected: 3.5/5.0, 4.5/1.0, 5.0/3.0, 5.0/4.5, 3.0/4.5, 4.0/5.0, 4.5/5.0". But what if someone accidentally uses tab separators instead of commas separators or omits a ".0" or uses a capital "Oh" instead of a zero or uses a lowercase "el" instead of a one or uses a comma instead of a period as the decimal mark? I can see that increasing the number of appeals if a Project-GC checker rather than a cache owner determines which geocachers successfully complete the challenge.

I would love to see the ability for PGC to request user input! A few of my SQL queries to check complex challenges have custom parameters added, especially with multiple queries where I choose certain values from prior results. In a case like this, the script checker could request seven valid D and T combinations (not a free text entry) which would be used to check qualification. If PGC could add that level of flexibility in the scripting system, that would do wonders for challenge explanations, flexibility, and creativity.

The way this challenge is set up, you must select your seven desired Fizzy cells before you start trying to find them. Unless Project-GC checkers have the ability to store this input data for weeks/months/years (which I seriously doubt), your idea would allow someone with 20 empty Fizzy cells to find any seven of those 20 and claim a find, which isn't the intent of this challenge.

 

Here's another. I have a Meta-Challenge that requires you to find at least 100 other challenge caches. Since GC currently doesn't have a "Challenge" cache type or "Challenge" attribute, there's no viable way Project-GC checkers can infallibly distinguish between challenge caches and, say, a desktop puzzle cache that happens to have the word "challenge" in its title.

Was the meta challenge published before restrictions on requirements? Doesn't sound it would have been published under near pre-moratorium guidelines, because as described, the 'task' required would be somewhat subjective. You could require 'Other' types with 'Challenge' in the title, but that would be it. So I'm honestly wondering how the challenge was published as worded (other than by reviewer exception) as I don't think it would have passed muster by the most recent publish rules.

My Meta-Challenge (and many other similar ones) were published after the new challenge guidelines were implemented. You seem to be confusing what is "verifiable" with what is easily verified by a computer. The current guidelines allow for challenges that humans can verify. Most humans have little trouble distinguishing a challenge cache from a desktop puzzle cache that happens to have the word "challenge" in its title. So why wouldn't a reviewer have published such meta-challenges?

 

That said, I do still very much hope that part of the as yet unexplained updates to CCs includes a parameter of some form that explicitly identifies a challenge cache.

While that would be nice, it wouldn't really help Project-GC checkers verify such meta-challenges...unless Groundspeak actually required all existing (and archived) challenges be modified to conform to this new cache type or attribute. Requiring a change to match a new "Challenge" cache type would make sense but also would involve a lot of work (probably too much work to require previous challenges to conform). And requiring all challenge caches to include a "Challenge" attribute also would involve lots of work...plus Groundspeak generally has shied away from requiring the use of attributes (even on future caches).

 

I'm currently working towards completing the "Washington Puzzler's Challenge - Irish Style." It has a similar issue as my Meta-Challenge challenge in that it requires geocachers to find caches that have "a puzzle to be solved to generate coordinates for the cache." GC has the "?" cache type, but that category includes many non-puzzle types of caches.

Same as above, I don't think a 'puzzle' challenge cache would get published, since 'puzzle' cache vs 'challenge' isn't explicitly detailed (other than by Unknown+"Challenge"). And what about field puzzles? And, do multis count when there's a puzzle included in the text? Seems too vague a challenge requirement (to get published pre-moratorium) since it would require a lot of human subjective judgement calls.

No, multi-cache puzzles cannot be used in this challenge because only "?"-icon finds can be used. No, field puzzles cannot be used in this challenge because, "The information to proceed to solve the puzzle must be on the [cache] page." Again, just because a challenge is too vague for a computer checker to verify doesn't mean it's too vague for a human to verify.

Edited by CanadianRockies
Link to comment

So I just skimmed about first replies in this thread, but what is wondering me the most (a question that annoyingly isn't answered yet): what is happening to existing challenge caches? Will they become grandfathered or do they have to implement a checker too? I think at least for this GS should make a statement soon.

Link to comment

 

No, you're not understanding. If the challenge says "with [selection of words] in the description", then that is accurate to what the checker says.

 

What I'm saying is that no automatic checker can check this as it can be in every part of the description and it all possible languages and the checker cannot contain context. Human beings can make a difference between e.g. "the cache involves a walk of 20 km" and "The next village where you can stay overnight is 20 km away". YOu cannot just search x km with x>20. The same is true for cemetery.

I could write something like: The trail is named after Mr A who got burried in the cemetery in Vienna.

Of course human beings have to trust the provided data (that's also true for attributes) but they can understand context.

Edited by cezanne
Link to comment
For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

Bingo! Do PGC scripts allow calling external APIs?

According to Groundspeak's current challenge cache guidelines, "The challenge criteria on the geocache page...must be verifiable through information on the Geocaching.com website."

 

I suspect Groundspeak doesn't want to place itself in a position where a 3rd or 4th party might decide to discontinue its services (or start charging for them). Situations like that could result in drastically modified (or archived) challenge caches that produce angry complaints from some geocachers who might have been worked on these challenges for months (or even years). In the past, Groundspeak generally has tried to avoid such situations. I'm guessing/hoping the deal they have worked out with Project-GC minimizes the possibility of this happening.

Edited by CanadianRockies
Link to comment

So I just skimmed about first replies in this thread, but what is wondering me the most (a question that annoyingly isn't answered yet): what is happening to existing challenge caches? Will they become grandfathered or do they have to implement a checker too? I think at least for this GS should make a statement soon.

This topic's original post included a link to this post: Challenge Cache Moratorium update.

 

That post includes this statement: "All future challenge caches must include a web-based challenge checker." Although it doesn't explicitly say so, that statement strongly implies that existing challenge caches will be grandfathered (i.e., they will not need to implement a checker).

Link to comment

I find it funny how many posts here talk about word challenges, as they are mostly pretty mundane. Their checkers should be pretty easy to write and maintain, but requires effort on the CO to come up with the initial set of acceptable words. I haven't used lua, but am proficient in dozens of other langues (my background is compiler & language design), so I expect that a language like lua should be able to easily check if a cache title contains one word in a list.

 

I'd be more interested in seeing what sorts of challenges that currently exist can't have checkers written for them, and what would have to change either on the GC side or on the project-gc side to make the viable.

You completely missed the point. A challenge cache of "caches with animal names in the title" is a perfect example because the list of all possible animal names is unbounded. We discussed how an unbounded list could be managed, but only by changing the checker requirement from being for a checker that confirms the requirements to a checker than can be expanded as needed. In my mind, that change is the equivalent of saying that the CO manually checks the list just like he always has without a checker, but then is required to waste his time and effort expanding the list every time someone uses a new animal name for no purpose other than to satisfy GS's checker requirement.

 

On a more practical level: there are a heck of a lot of animal names. Is there any size list that would stress project-gc or take too long to search?

Link to comment
Here's another. I have a Meta-Challenge that requires you to find at least 100 other challenge caches. Since GC currently doesn't have a "Challenge" cache type or "Challenge" attribute, there's no viable way Project-GC checkers can infallibly distinguish between challenge caches and, say, a desktop puzzle cache that happens to have the word "challenge" in its title.

Was the meta challenge published before restrictions on requirements? Doesn't sound it would have been published under near pre-moratorium guidelines, because as described, the 'task' required would be somewhat subjective. You could require 'Other' types with 'Challenge' in the title, but that would be it. So I'm honestly wondering how the challenge was published as worded (other than by reviewer exception) as I don't think it would have passed muster by the most recent publish rules.

My Meta-Challenge (and many other similar ones) were published after the new challenge guidelines were implemented. You seem to be confusing what is "verifiable" with what is easily verified by a computer. The current guidelines allow for challenges that humans can verify. Most humans have little trouble distinguishing a challenge cache from a desktop puzzle cache that happens to have the word "challenge" in its title. So why wouldn't a reviewer have published such meta-challenges?

CR's meta-challenge was published in late 2013, which I believe was after the most recent challenge cache guidelines update. Most recent before the moratorium, of course.

Besides CR's meta challenge, I've personally come across cache listings for 3 other such challenges (find 50 or 100 Challenge Caches) that were also published in late-2013. I've also seen a couple that were published in 2010 and 2011. I don't see why the Challenge wouldn't have been publishable under the pre-moratorium guidelines. Geocaching.com defines what a Challenge Cache is, so it's not as though the CC finder wouldn't be able to 'know' whether a cache on their qualifying list was appropriate or not.

Link to comment

I assume the only way this could be valid is if the cache had posted parking coordinates, so that you could use the difference in parking & location to determine if it is > 20km. There's an attribute for > 10km, but not one for a larger number. Of course it gets complex if the posted coords were 1km from the first (public) waypoint of a 20km multi, as now a checker cannot be written.

 

In addition to what you mentioned this also assumes quite flat terrain and areas where the route is almost like the crow flies which is pretty unrealistic in my area and in the mountains in general.

This sort of checker would not be even be able to recognize round trip caches that cover a route of 180km (header coordinates, parking coordinates and even final coordinates, though hidden anyway, are close to each other.)

Link to comment

The onus is also on the checker writer to update the checkers they create for a specific CC. If a CO sends "here are more words to add to GCxxx checker", via whatever system is as yet to be implemented, then will there be an SLA for the checker writer to make those changes? I hope checker writers that agree to write checkers will understand the long-term commitment of writing a checker for a cache that can't continue to exist without the checker being maintained. Of course, many checkers won't need updating, so those would be the ones to write checkers for if a checker writer was unsure about the long-term commitment.

 

I'd say you have this completely backwards. The onus is on the cache owner to make sure they have a working checker. They can do it themselves, or they can have someone else make it for them. In the latter case, they can either arrange that the checker writer will continue to maintain this checker, or just assume that it will be possible to find someone else that can copy the code and make needed fixes later. Either way is (from a technical standpoint) fine. Just assuming that someone who was nice to you and wrote a checker for you a year ago has time to fix a bug for you a year later unless you have already discussed that is arrogant at best.

Link to comment

A similar issue arises with certain souvenir challenges, such as the Souvenir Triathlon Challenge. This challenges requires souvenirs from three non-U.S. countries, from three U.S. states, and for three special dates/events. But GC doesn't currently categorize its souvenirs. So, unless GC's new checker guideline allows for open-ended lists that can be modified in the future, there isn't an infallible way for a Project-GC checker to validate this kind of challenge.

 

I have done some work on a checker to handle this. Souvenirs are an open set, but they are an open set that grows rather slowly and doesn't have multiple languages, so it's pretty manageable.

 

If I remember correctly, I did code to categorize souvenirs into countries, states, special days, events and others. After looking at the then-existing list of souvenirs it felt like rather simple to categorize all the existing ones and then add the few new countries and days that were announced and just assume anything else that wasn't known to be an event. What made me (at least not then) finish the checker was that I also needed to know what country each event belonged to, meaning that I needed to keep the list up to date monthly or so to be useful. Not impossible, but has to be done. We'll see if I finish it later.

 

But still, for at least a decent percentage of souvenir-related challenges there is already a working checker that knows about countries and states.

Link to comment

The onus is also on the checker writer to update the checkers they create for a specific CC. If a CO sends "here are more words to add to GCxxx checker", via whatever system is as yet to be implemented, then will there be an SLA for the checker writer to make those changes? I hope checker writers that agree to write checkers will understand the long-term commitment of writing a checker for a cache that can't continue to exist without the checker being maintained. Of course, many checkers won't need updating, so those would be the ones to write checkers for if a checker writer was unsure about the long-term commitment.

 

I'd say you have this completely backwards. The onus is on the cache owner to make sure they have a working checker. They can do it themselves, or they can have someone else make it for them. In the latter case, they can either arrange that the checker writer will continue to maintain this checker, or just assume that it will be possible to find someone else that can copy the code and make needed fixes later. Either way is (from a technical standpoint) fine. Just assuming that someone who was nice to you and wrote a checker for you a year ago has time to fix a bug for you a year later unless you have already discussed that is arrogant at best.

This was in the context of maintaining a list of valid words, for challenges that are based on specific words (such as animal CC's). The discussion was about starting with a long list of words, but then adding additional words to the checker if cache finders came up with a word that the CO hadn't thought of (or in a language the CO didn't know about) when they created the initial list. If CC CO's are not able to maintain the checker themselves, which depends on how PGC decides to regulate access in the future, then the CC CO will be reliant on PGC checker writers to make the script edits for them.

 

Other scripts, such as "find 100 earthcaches" shouldn't have bugs that require additional maintenance. But the context was about maintaining lists of valid words, which is a specific type of challenge that has been discussed extensively in this thread.

 

I think it's still valid to consider the checker writers' commitment to specific challenges.

-- In the past, checkers were created for cachers that requested them. Most of the requests I've seen were from CC finders, not from CC CO's. Those were certainly favors and not something the checker writers 'had to' do and there were no consequences if the checkers didn't function correctly.

-- In the future, the reliance on checkers to function correctly will be much stronger. If checker writers do not want to commit to long-term maintenance, then that is fine. They are not required to help with future debugging or edits to word lists. Hopefully the CC CO's and the checker writers they work with will have the discussion about maintenance. As you said, "unless you have already discussed that". That is the point I am trying to make. That both CC CO's and checker writers should consider the potential for long-term maintenance. If a checker writer knows that a checker is likely to require edits, such as word lists, then they should let the CC CO know that they don't want to be responsible for making those edits. Again, the context was about challenges based on specific words.

 

Regarding SLA's: If a CC CO needs an edit to a checker and asks the checker writer to make the edit, then how long should they wait for a response before reaching out to ask another checker writer to make a copy? Since CC's are subject to archival if their checkers are not maintained and/or don't work correctly, then timelines become an issue. These are details that the new framework should consider.

Link to comment

Does Project-GC have access to the Waymarking.com database? If not, then it would be problematic for their checkers to handle most Waymarking challenge caches, such as: Waymarkable: Quasy Challenge Cache 2 of 8 (visit 100 Waymarks).

 

How about geocaching.com's benchmark database? If not, then there could be issues validating certain kinds of benchmark challenges, such as: Challenge of a Century: AlphaNumeric BenchMarks (includes finding 33 benchmarks with numeric-only designations).

 

No in both cases. Project-GC is about geocaching. Waymarking and Benchmarking are not geocaching.

Link to comment

Does Project-GC have access to the Waymarking.com database? If not, then it would be problematic for their checkers to handle most Waymarking challenge caches, such as: Waymarkable: Quasy Challenge Cache 2 of 8 (visit 100 Waymarks).

 

How about geocaching.com's benchmark database? If not, then there could be issues validating certain kinds of benchmark challenges, such as: Challenge of a Century: AlphaNumeric BenchMarks (includes finding 33 benchmarks with numeric-only designations).

 

No in both cases. Project-GC is about geocaching. Waymarking and Benchmarking are not geocaching.

 

Sounds like the bolded portion of the current Challenge Cache guidelines will also be changing:

 

A challenge cache requires that geocachers meet a geocaching-related qualification or series of tasks before the challenge cache can be logged. Waymarking, Benchmarking, and Wherigo-related tasks also qualify.

Link to comment

This was in the context of maintaining a list of valid words, for challenges that are based on specific words (such as animal CC's). The discussion was about starting with a long list of words, but then adding additional words to the checker if cache finders came up with a word that the CO hadn't thought of (or in a language the CO didn't know about) when they created the initial list. If CC CO's are not able to maintain the checker themselves, which depends on how PGC decides to regulate access in the future, then the CC CO will be reliant on PGC checker writers to make the script edits for them.

 

We can safely assume that it will be possible for new people to become challenge checker authors and/or taggers. I'm not going to say that it will be possible at the same time as Groundspeak announces the actual guidelines and indeed (not being ganja1447) I won't give any specific time at all, but I'd expect it to be "reasonably soon".

 

-- In the future, the reliance on checkers to function correctly will be much stronger. If checker writers do not want to commit to long-term maintenance, then that is fine. They are not required to help with future debugging or edits to word lists.

 

As has been stated before here but probably still isn't clear to everyone: A checker consists of a checker script and a tag. The script is program code, the tag consists of a couple of fields to fill in on a web page.

 

Since much of the discussion here has been about animal name challenges (a to me incomprehensible challenge that has nothing to do with geocaching, but hey, I don't need to like all challenge types): The checker for this type of challenge is simple to trivial, and - of course - already exists. I don't expect the author of this script to need to do anything more even if more challenges of this type are added.

 

What is needed is a new tag for each challenge that connects this checker script to the specific challenge. The tag needs to contain a list of animal names, fruits or whatever. This list can later be edited by the tagger. This person could be the cache owner, the script author, or a third person. Tagging a challenge requires a special privilege, but it's not the same privilege as writing a script. As of today, 85 people have written at least one checker script while 361 people have tagged at least one challenge.

Link to comment

Sounds like the bolded portion of the current Challenge Cache guidelines will also be changing:

 

A challenge cache requires that geocachers meet a geocaching-related qualification or series of tasks before the challenge cache can be logged. Waymarking, Benchmarking, and Wherigo-related tasks also qualify.

 

Projec-gc cannot deal with the Wherigo site either. The geocache type Wherigo can be handled of course.

Link to comment

Wow. That's sad. A fun and interesting would be disallowed because the list is open-ended. Sounds like programmer error to me.

...

 

So some fun challenges would not be acceptable because the programmer is incapable of providing a checker? Wow!

 

How would YOU program a computer to deal with a list of unknown items?

 

For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

 

I wondered how efficient searching that list could be from lua. If there was a sql or mongo type database a search of a large dataset would be quick. I assume there is no database in pgc other than cache data. Could an interpreted language like lua do? Does pgc have execution limits for scripts?

 

I really haven't had a chance to do any LUA programming so I don't know it's capabilities. If it has some sort of library that can make HTTP requests, and there is a web service for a dataset that'll return machine readable data (e.g. as XML or JSON) then it shouldn't be that difficult. It was mentioned elsewhere that checkers couldn't be written unless the right attributes were available from GC. That assumes that the only data available is what comes the GC database and that's not true. For example, a cache listing contains lat/long coordinates and even though it doesn't include elevation data, one could look up the elevation for a point using those lat/long coordinates.

Link to comment

There was some discussion about elevation, but I don't know if it was brought up, but Project-GC doesn't seem to handle elevation well. Look at my stats, PGC list http://coord.info/GC1XYQ2 as my lowest elevation cache. They have it listed at -66 feet, but it is definitely on land.

 

Project-GC tries to handle elevation but without support from geocaching.com which doesn't handle it at all, so no help from that end. There is no "official elevation" of a cache.

 

From the FAQ:

I found a cache with a faulty elevation

 

Sadly there are a lot of geocaches with these issues. The elevation data does not come from Groundspeak since they don't have that data. We have therefore build our own SRTM-service for the purpose, it serves both SRTM1 and SRTM3. As a fallback for the areas these doesn't cover, we fallback to several over services, for example: Geonames, Google and MapQuest.

 

If you find that a value in Project-GC isn't correct. Please read below how our elevation data works, and also check other services like for example Geonames SRTM3. If you find out that other services has about the same fault tolerance, then there is nothing to do.

 

We do not do manual changes in the data. But if you find an entry that seems to be off by a lot more than in other services, feel free to report it so that we can investigate.

 

How is the elevation data calculated?

 

This is actually quite advanced, but we will try to simplify it a bit.

 

First off, we use different data sets for different areas on the earth. For most of the planet we are using data from the SRTM1 and SRTM3 databases created by Nasa. Nasa has created this data by measuring the height using satellites. SRTM1 has a higher resolution, but that data only exists around USA. SRTM3 exists for other parts of the world, except closer to the poles.

 

The SRTM1 data has ONE measure point per 30x30 meters, and the SRTM3 data has ONE measure point per 90x90 meters. What this means, is that there is no measurement for every coordinate, and therefore not for every geocache location. So what we do is that we interpolate between the 4 closests values to get a weighted average for the geocache location. In an area which is very hilly, like mountains, this will give a quite big fail factor and almost always a too low value. There is however no better way to do this, since the measurements just doesn't exist, well, except manually adding data for all the geocaches, which we do not do.

 

Other services like for example Geonames might have slightly different approaches to how they calculate the data, therefore we will have smaller differences. But they do have similar solutions.

 

Before using SRTM as our primary source we used AsterGDEM which is created by radar measurements. This data has measure points for every 30x30 meters in a larger area of the earth, which in one way makes it better. But, AsterGDEM is also known for being affected by radar shadows, which makes the data quite useless for some areas. We have found out that switching to SRTM has giving us more precise data.

 

For those areas where there is no SRTM1 or SRTM3 data we are falling back to other services which relies on other data.

 

tl;dr: The elevation data from Project-GC may be off somewhat. In areas with very steep slopes, by significant amounts. This is due to how elevation databases work, and can't be changed until elevation databases get better (which is continously happening) or geocaching.com starts delivering elevation data (not likely, IMHO). Still, for the vast majority of caches you will get elevation information that is probably correct within a couple of meters.

Edited by pinkunicorn
Link to comment

There was some discussion about elevation, but I don't know if it was brought up, but Project-GC doesn't seem to handle elevation well. Look at my stats, PGC list http://coord.info/GC1XYQ2 as my lowest elevation cache. They have it listed at -66 feet, but it is definitely on land.

 

Looking at the location of the cache, I don't think 66 feet is a terrible margin of error in that case.

Link to comment

I assume the only way this could be valid is if the cache had posted parking coordinates, so that you could use the difference in parking & location to determine if it is > 20km. There's an attribute for > 10km, but not one for a larger number. Of course it gets complex if the posted coords were 1km from the first (public) waypoint of a 20km multi, as now a checker cannot be written.

 

In addition to what you mentioned this also assumes quite flat terrain and areas where the route is almost like the crow flies which is pretty unrealistic in my area and in the mountains in general.

This sort of checker would not be even be able to recognize round trip caches that cover a route of 180km (header coordinates, parking coordinates and even final coordinates, though hidden anyway, are close to each other.)

 

No, a checker couldn't recognize this. But neither could a challenge cache owner. It's subjective, very subjective. I usually skip parking lot caches and road side caches, but if I happen to be taking a long walk with the dog I might grab them, mostly so I can say I walked 5 miles for the park and grab. Could I use that for a challenge that required a hike of a certain length?

Link to comment

Some of my favourite challenge caches have been thematic (25 Christmas words), letter-based (first letter of caches spelling out a phrase) or map-based (caches in X squares on walking map number X) - none of these are going to be possible and it will all be down to number crunching. To improve what exactly? Big thumbs down from me.

Link to comment

Some of my favourite challenge caches have been thematic (25 Christmas words), letter-based (first letter of caches spelling out a phrase) or map-based (caches in X squares on walking map number X) - none of these are going to be possible and it will all be down to number crunching. To improve what exactly? Big thumbs down from me.

That's a pity. Too bad you didn't provide input a year ago in the User Insight topic. It might have made a difference in the outcome. Unfortunately, what you describe, sounds like what many of the responses in that thread (and presumably the survey that followed) was exactly what a majority of people didn't like about the current Challenges out there.

Link to comment

It would be great if there was a "no challenge" attribute that removed a cache from being counted.

 

Why would you care? If somebody bothers you to add an attribute or something, feel free to ignore them. I can't imagine the number of people emailing cache owners to add something to their cache page will be significant.

 

I just can't believe that someone is such a whiner that he cared so much about his cache not being involved in challenges that he archived the cache. For me, that doesn't even compute.

 

I can't believe that there are geocachers that think others are obligated to keep a cache active if, for any reason at all, they don't want to continue to maintain it.

 

If someone wants to archive a cache they don't own an explanation to anyone.

 

Nice try. There is NEVER an obligation to keep a cache active, for any reason, I agree with that. But to archive it just because you don't want it involved in a challenge qualifier is such a petulant behavior that it makes me laugh.

Link to comment

No matter what the result is, I don’t think it’s possible for it to be better than the forum regulars think it will be. We could announce that we're sending a barrel of money to every active geocacher, and I'd be preparing for a riot here about some aspect of the plan to distribute free money.

 

But what I can promise is a result that is the best that we could come up in order to keep challenges while reducing the burden on reviewers. I do hope people will give it a real chance before bringing out the torches and pitchforks.

 

As a challenge lover myself, I appreciate any efforts to keep them even though I see my favorite challenge types being impossible to code with a checker (geographical). What I worry about is the long term partnership with a third party. There is no doubt the Project GC right now is top drawer and all in. But what does the future hold? And while disputes to GS and reviewers may be squashed with this system, all I see in my head now are disputes between CO's and challenge checker writers, and lots of archived challenges.

 

BTW, do we know if all past challenges are to be grandfathered as-is or will they be subject to the upcoming framework?

Link to comment

The way this challenge is set up, you must select your seven desired Fizzy cells before you start trying to find them. Unless Project-GC checkers have the ability to store this input data for weeks/months/years (which I seriously doubt), your idea would allow someone with 20 empty Fizzy cells to find any seven of those 20 and claim a find, which isn't the intent of this challenge.

Ok I think I understand... basically you'd need a snapshot of your DT grid when you start the challenge to prove you chose valid DT combos to use for the challenge, since the quantities in the grid could change over the course of the challenge in that the checker might show at the end that the DT isn't one of the lowest-count spots. That is an interesting quandry.

I wonder if a reviewer could respond as to whether that type of challenge would be (should have been) publishable, at least with the most recent publish guideline set. How is it verifiable? Technically, the CO has to keep a list of claimed start stats for cachers who do the challenge. So how does the reviewer reconcile the issue of unresponsive COs? Verification is 100% on the CO and if there's no record of the DT grid as of a past date, it would be impossible to verify (without analyzing the cacher's MyFinds log history).

 

Now theoretically, if PGC does have access to the find log history with dates, then it would be possible to run the checker. If the user inputs the DTs they chose for the challenge as well as the start date, then the script could verify that the DTs were of the lowest as of that date, and whether the cacher qualifies with the subsequent finds.

 

My Meta-Challenge (and many other similar ones) were published after the new challenge guidelines were implemented. You seem to be confusing what is "verifiable" with what is easily verified by a computer. The current guidelines allow for challenges that humans can verify. Most humans have little trouble distinguishing a challenge cache from a desktop puzzle cache that happens to have the word "challenge" in its title. So why wouldn't a reviewer have published such meta-challenges?

I'm thinking of issues where disputes could arise. I've seen a couple of traditional caches that are challenges, or grandfathered Unknowns without challenge in the title that are challenges. The issue here is that there are definitions with exceptions - in that case a human can see the exception, and with a virtual list, as it were, of exceptions, still decide to allow/deny a qualifier. If the script has access to an exception list, it can still be done. But in the case of challenge vs puzzle, I think they'd explain that as a trade-off [as the system exists currently] since there's no property that states what 'type' of Unknown it is (aside from Unknown+"Challenge", or field puzzle attribute). I suppose you could say that means that the "puzzle challenge" wouldn't be publishable post-moratorium because there's no metric for a script to verify it's an actual "puzzle cache". I just look at the rest of the wording saying there's more we don't know, and think that perhaps they've got some other tricks up their sleeve in working with PGC to provide some additional metrics. But I still the "puzzle cache" challenge as one of those subjective CO-judgement challenges, precisely because there's no actual way to state "this is a puzzle cache" (even though every human agrees that it is). There are other contexts where that wouldn't be allowed (like a cache requiring hiking 20km, or [pre-treeclimb attribute] what requires climbing a tree, etc - even though everyone may agree, there's no verifiable property).

 

At the very least, I'd consider all this part of the reason why there was a moratorium - to find some way to unify the system to reduce subjective judgements and exceptions.

 

So I'll cede you this point: If reviewers [universally, not by exception] would allow and publish a "puzzle cache" challenge pre-moratorium, then it sounds like by the current explanation of post-moratorium challenge cache setup and current availability of cache properties to checkers, the "puzzle cache" challenge wouldn't be publishable, because it's not objectively verifiable by scripting.

 

While that would be nice, it wouldn't really help Project-GC checkers verify such meta-challenges...unless Groundspeak actually required all existing (and archived) challenges be modified to conform to this new cache type or attribute. Requiring a change to match a new "Challenge" cache type would make sense but also would involve a lot of work (probably too much work to require previous challenges to conform). And requiring all challenge caches to include a "Challenge" attribute also would involve lots of work...plus Groundspeak generally has shied away from requiring the use of attributes (even on future caches).

I know a feature suggestion that addresses that in its attempt to address many multiple issues ;P

I don't think an attribute would suffice either, but it would certainly make things easier. If certain attributes have fine print associated with them, I think it'd certainly be feasible for reviewers to require the CO add the challenge attribute if they're trying to publish a challenge cache. Grandfathered challenges - well, either they won't count for meta-challenges, or such CCOs will have to maintain a list of grandfathered challenges that don't match the criteria. Alternatively, as GS has done with some other feature additions, they could give a window of time for CCOs to alter their challenge listings to add the attribute. There are a few ways to get around that. But I definitely believe that some form of explicit identifier for challenge cache listings should be in the works. That's one of the biggest most common issues raised in all these challenge threads.

Link to comment

Wow. That's sad. A fun and interesting would be disallowed because the list is open-ended. Sounds like programmer error to me.

...

 

So some fun challenges would not be acceptable because the programmer is incapable of providing a checker? Wow!

 

How would YOU program a computer to deal with a list of unknown items?

 

For this specific case (caches containing the name of an animal) I'd use an existing comprehensive dataset of animal names such as the Integrated Taxonomic Information System. It contains over 700 thousand scientific names and 125K common names. Sure, that list might not have every animal name, but odds are if a cache contains an animal name it would probably be on a comprehensive list. As a programmer I don't have to maintain that list myself, but can call upon a service with a name and it will tell me whether or not the name is on the list.

That might solve the problem for animal in English. I tried to enter hund (dog in Swedish) and got no result.

I have seen many challenges with x nr of y in the namne and I am not sure I have seen any with a language requirement.

 

And it in it self don't even solve the problem in english. Rook is in the database but the plural form rooks is not. And the cache "Rooks Nest Wood" http://coord.info/GC5YRCJ should be a animal cache if I am not mistaken.

It does not event contain the word dog only dogs as in the family and genus because dog is not a spices but the singular of a family of animal. The same for cow and i suspect that they should be accepted.

 

I am not sure if adding s is the correct plural for all animals in English.

And English is in that case easy for word forms. For dog i can think of dog dogs and dog's . In Swedish there will hund hunden hundens hundar hundars hundarna hundarnas. And you cant take all words starting with hund because hundra is one hundred and not related to dogs.

 

And it gets worse because many separated words in english becomes compound words in Swedish, the number of compound words are unlimited.

The cache "Dogs Bowl" would be hundskålen and "Town dogs" stadshundar. Match that and ignore all words kombinations with that refer to hundra(one hundred). Hundrastgården is dog related but hundraåringen is not.

It will be worse for ren (reindeer), ko (cow) and word related to myra(ant)

And list of ok words cant be used because if I call a cache Koträdsmysteriet (The cow tree mystery). It would be a ok Swedish word about a mystery cache related to a three that looks like a cow. It might never have been used before and gets 0 hits on google.

Link to comment

No, a checker couldn't recognize this. But neither could a challenge cache owner. It's subjective, very subjective. I usually skip parking lot caches and road side caches, but if I happen to be taking a long walk with the dog I might grab them, mostly so I can say I walked 5 miles for the park and grab. Could I use that for a challenge that required a hike of a certain length?

 

If the challenge cache is formulated so unspecifically, yes. Such challenge caches are of course then subjective.

It's however not subjective at all what the cache owner writes in the description.

Have a look at caches like

https://www.geocaching.com/geocache/GC3EFT1_vulkanland?guid=bc6fc608-511d-4790-91a6-63898366b82c (mentions at least 170km)

or

https://www.geocaching.com/geocache/GC22D00_lets-rug?guid=6d831ec0-e0b0-40a0-ba52-3cb2e630de33170km) (mentions 120km)

 

If someone comes along with such a cache in a completely different language, I also would be able to check quickly whether the cache fits the framework I described. Of course there could be caches out there

that do not mention any length bound and are still of this type. If a cacher might wish to use of one those, he/she might be able to come up with a convincing argument but even if one is not allowing such exceptions, what one can do manually very quickly goes far beyond what a checker will ever be able to do and it can be done with so much less effort and without subjectivity. (Of course someone could write 50km for a 500m walk in much the same way as wrong attributes can be used but I have never seen a cache where the length was wrongly specified by that much.)

Link to comment

No, a checker couldn't recognize this. But neither could a challenge cache owner. It's subjective, very subjective. I usually skip parking lot caches and road side caches, but if I happen to be taking a long walk with the dog I might grab them, mostly so I can say I walked 5 miles for the park and grab. Could I use that for a challenge that required a hike of a certain length?

 

If the challenge cache is formulated so unspecifically, yes. Such challenge caches are of course then subjective.

It's however not subjective at all what the cache owner writes in the description.

Have a look at caches like

https://www.geocaching.com/geocache/GC3EFT1_vulkanland?guid=bc6fc608-511d-4790-91a6-63898366b82c (mentions at least 170km)

or

https://www.geocaching.com/geocache/GC22D00_lets-rug?guid=6d831ec0-e0b0-40a0-ba52-3cb2e630de33170km) (mentions 120km)

 

If someone comes along with such a cache in a completely different language, I also would be able to check quickly whether the cache fits the framework I described. Of course there could be caches out there

that do not mention any length bound and are still of this type. If a cacher might wish to use of one those, he/she might be able to come up with a convincing argument but even if one is not allowing such exceptions, what one can do manually very quickly goes far beyond what a checker will ever be able to do and it can be done with so much less effort and without subjectivity. (Of course someone could write 50km for a 500m walk in much the same way as wrong attributes can be used but I have never seen a cache where the length was wrongly specified by that much.)

Your first example mentions "approximately 170 km", not "at least". It also states that the "preference" is to walk, but sounds like you can drive to portions of it.

 

Your second example mentions "about 120 km", and the use of public transportation to reach some of the Stages.

 

Sounds all very subjective to me. Any other examples?

Link to comment

Some of my favourite challenge caches have been thematic (25 Christmas words), letter-based (first letter of caches spelling out a phrase) or map-based (caches in X squares on walking map number X) - none of these are going to be possible and it will all be down to number crunching. To improve what exactly? Big thumbs down from me.

That's a pity. Too bad you didn't provide input a year ago in the User Insight topic. It might have made a difference in the outcome. Unfortunately, what you describe, sounds like what many of the responses in that thread (and presumably the survey that followed) was exactly what a majority of people didn't like about the current Challenges out there.

 

Actually at least I provided my feedback also a year ago, but I'm quite sure that my preferences (different from Oxford Stone's preferences but also along the same lines of not being number crunching kind of challenge caches) are what a minority prefers and that's the problem and also the reason why I reacted with "The mass has won again".

 

I'm not sure whether I'm correct but I guess that one of the reasons (apart from the reasons mentioned before) GS came up with the checker requirement was that this way they could prescribe a certain number or percentage of cachers of need to have already qualified and the reviewers could run checks (if project gc provided them with the power to do which should not be a big issue).

 

I do not buy the argument that there word challenge caches cause many appeals. Of course there are complaints from cachers who want to find every cache but find it tiresome to look through their lists of finds (while others enjoy this and are happy that there are also challenges for those who never will fill any grids or qualify for streak challenges etc). Furthermore, it is not always easy to decide for a reviewer how appealing a challenge is to the local cachers and using a checker will make this decision easier and more objective but also less flexible. Right now we can only speculate and need to wait for what is yet to come from Groundspeak. The requirement for a challenge checker will definitely ruin many challenges which are not number cruncher challenges.

Link to comment

No, you're not understanding. If the challenge says "with [selection of words] in the description", then that is accurate to what the checker says.

What I'm saying is that no automatic checker can check this as it can be in every part of the description and it all possible languages and the checker cannot contain context. Human beings can make a difference between e.g. "the cache involves a walk of 20 km" and "The next village where you can stay overnight is 20 km away". YOu cannot just search x km with x>20. The same is true for cemetery.

I could write something like: The trail is named after Mr A who got burried in the cemetery in Vienna.

Of course human beings have to trust the provided data (that's also true for attributes) but they can understand context.

Yes, but a human being can read the description and see that it says "the cache involves a walk fo 20km", but that human has not verified that the cache actually requires a 20km walk. That's not verified. That's subjectively judged. And what about hiking for a cache that doesn't actually require, in any way, a hike (as ChileHead as Touchstone discuss)? More appeals disputes.

 

If the challenge says "the description must indicate a hike length of 20km", that then is objectively verifiable by text analysis, even if the cache may not actually require hiking 20km (provided the checker has access to the description text in order to analyze it per the challenge requirement). Again, it's about the challenge description accurately describing what the checker is actually checking.

 

For attributes, it doesn't matter whether the attribute is valid or not - if the challenge says "requires caches with the Ruins attribute" rather than "requires cache hidden near Ruins". The former is objectively verifiable (has nothing to do with verifying the physical cache), whereas the latter is not. Seeing the difference yet?

 

You completely missed the point. A challenge cache of "caches with animal names in the title" is a perfect example because the list of all possible animal names is unbounded. We discussed how an unbounded list could be managed, but only by changing the checker requirement from being for a checker that confirms the requirements to a checker than can be expanded as needed. In my mind, that change is the equivalent of saying that the CO manually checks the list just like he always has without a checker, but then is required to waste his time and effort expanding the list every time someone uses a new animal name for no purpose other than to satisfy GS's checker requirement.

I don't think the CO would be obligated to maintain their list, unless they worded the challenge to allow "any animal name". If it's worded such that the cacher knows what words are allowed (and checked by the script), then the CO, for all they care, could leave the challenge as is (as long as the checker does its job of course).

It's about the challenge requirements being consistent with what the checker actually checks.

 

What is needed is a new tag for each challenge that connects this checker script to the specific challenge. The tag needs to contain a list of animal names, fruits or whatever. This list can later be edited by the tagger. This person could be the cache owner, the script author, or a third person. Tagging a challenge requires a special privilege, but it's not the same privilege as writing a script. As of today, 85 people have written at least one checker script while 361 people have tagged at least one challenge.

Cool, that sounds exactly like what I/we were hoping was capable. As I haven't connected a PGC checker to my (2) challenge caches, is it the CO who creates that tag? What form does it take? ie, if one of the fields is a list, is it an open input value with no max length, or is there indeed a limit?

 

That assumes that the only data available is what comes the GC database and that's not true. For example, a cache listing contains lat/long coordinates and even though it doesn't include elevation data, one could look up the elevation for a point using those lat/long coordinates.

If as mentioned above that requires the checker using an external API source, wouldn't that be disallowed? :mellow:

Link to comment

Your first example mentions "approximately 170 km", not "at least". It also states that the "preference" is to walk, but sounds like you can drive to portions of it.

 

Yes, I added the at least because several people who did the cache (including myself ended up with more than 170 km). For the sake of a challenge one would use 170km of course.

 

Your second example mentions "about 120 km", and the use of public transportation to reach some of the Stages.

 

Not some of the stages. You can split up the cache into several day trips and you can organize them so that you can travel home again. None of the many stages (of different type) are not known in advance, except the start.

 

In central Europe there is no area with 100km wilderness. You can always split things up and that's also definitely one of the modes the owners of such caches have in mind.

It's not about walking around one's hometown in one go and noone so far has done that for the Let's Rug example.

 

Sounds all very subjective to me. Any other examples?

 

It's not subjective at all. If I ever would set up a challenge cache involving such caches I would require the significant hike attribute and some minimum length mentioned in the cache description.

Of course there are people who do such caches by MTB and others who drive around many more km and then only walk to the stages (do not underestimate however the distance and height meters they still need to cover). I still would accept every such cache as a qualifying cache.

 

If a length field existed the two caches above would probably have entries 120km and 170km and then an automatic checker (checking for a lower bound in length and the significant hike attribute to exclude car and motorbike caches not cachers) would be possible and suddenly you would call the same scenario objective? That's somehow weird and completely unlogical.

Edited by cezanne
Link to comment

The way this challenge is set up, you must select your seven desired Fizzy cells before you start trying to find them. Unless Project-GC checkers have the ability to store this input data for weeks/months/years (which I seriously doubt), your idea would allow someone with 20 empty Fizzy cells to find any seven of those 20 and claim a find, which isn't the intent of this challenge.

Ok I think I understand... basically you'd need a snapshot of your DT grid when you start the challenge to prove you chose valid DT combos to use for the challenge, since the quantities in the grid could change over the course of the challenge in that the checker might show at the end that the DT isn't one of the lowest-count spots. That is an interesting quandry.

I wonder if a reviewer could respond as to whether that type of challenge would be (should have been) publishable, at least with the most recent publish guideline set. How is it verifiable? Technically, the CO has to keep a list of claimed start stats for cachers who do the challenge. So how does the reviewer reconcile the issue of unresponsive COs? Verification is 100% on the CO and if there's no record of the DT grid as of a past date, it would be impossible to verify (without analyzing the cacher's MyFinds log history).

 

Now theoretically, if PGC does have access to the find log history with dates, then it would be possible to run the checker. If the user inputs the DTs they chose for the challenge as well as the start date, then the script could verify that the DTs were of the lowest as of that date, and whether the cacher qualifies with the subsequent finds.

 

I don't think it should have been allowed at the time of publication because of rule at the time of publication

"3.2 Challenge geocaches cannot include restrictions based on 'date found'; geocaches found before the challenge geocache publication date can count towards the achievement of the challenge."

https://web.archive.org/web/20140916072453/http://support.Groundspeak.com/index.php?pg=kb.page&id=206

That don't allow for requirement to post a note to start challenge in my opinion.

 

With the modification that you have to have a week where you found the same thing without posting the note would i my interpretation be allowed. You might also what to add a requirement that x% of the DT matrix has to be filled before you start. It might be the case that to many started with a streak of 7 days and it is quite easy to do in the beginning.

With that modification it can checked for automatically

Link to comment

I still would accept every such cache as a qualifying cache.

 

So pretty much up to the whim of the cache owner? What could possible go wrong with that scenario?

 

If a length field existed....

 

I think it's better to keep the conversation restricted to features that are currently available on the website. Feature requests such as that should be directed to the Website subforum.

Link to comment

I still would accept every such cache as a qualifying cache.

 

So pretty much up to the whim of the cache owner? What could possible go wrong with that scenario?

 

In what sense up to the whim?

 

This sort of dicussion gets too tiresome for me - even if I had more time I do not know all subleties of the English language. I try to explain the scenarios that cannot be implemented as challenge caches. I did not suggest concrete formulations for challenge cache requirements.

 

If a length field existed....

 

I think it's better to keep the conversation restricted to features that are currently available on the website. Feature requests such as that should be directed to the Website subforum.

 

It was not about a feature suggestion but just pointing out that the border between subjective and objective cannot be based on whether a length field is used or the same is supplied in the text.

Link to comment

Some of my favourite challenge caches have been thematic (25 Christmas words), letter-based (first letter of caches spelling out a phrase) or map-based (caches in X squares on walking map number X) - none of these are going to be possible and it will all be down to number crunching. To improve what exactly? Big thumbs down from me.

That's a pity. Too bad you didn't provide input a year ago in the User Insight topic. It might have made a difference in the outcome. Unfortunately, what you describe, sounds like what many of the responses in that thread (and presumably the survey that followed) was exactly what a majority of people didn't like about the current Challenges out there.

You must be kidding. These kinds of caches have always been some of the most popular. The fact that you don't think enough people lobbied for them just demonstrates how completely interpreting the "input" was focused on the negative comments by people that don't like challenge caches at all and, for reasons I still don't understand, want them banned.

Edited by dprovan
Link to comment

Yes, but a human being can read the description and see that it says "the cache involves a walk fo 20km", but that human has not verified that the cache actually requires a 20km walk.

 

The type of challenge cache scenario I described can perfectly work with "the cache involves" - it does not need to reply on requires.

 

And what about hiking for a cache that doesn't actually require, in any way, a hike (as ChileHead as Touchstone discuss)? More appeals disputes.

 

No appeals at all when the cache description is formulated properly.

 

If the challenge says "the description must indicate a hike length of 20km", that then is objectively verifiable by text analysis, even if the cache may not actually require hiking 20km (provided the checker has access to the description text in order to analyze it per the challenge requirement). Again, it's about the challenge description accurately describing what the checker is actually checking.

 

That's not checkable as it can be in any language and one needs to understand the context except you ask for a fixed formulation in a fixed language and even when you will end up with incorrect checker results while no human being will make such mistakes.

 

For attributes, it doesn't matter whether the attribute is valid or not - if the challenge says "requires caches with the Ruins attribute" rather than "requires cache hidden near Ruins". The former is objectively verifiable (has nothing to do with verifying the physical cache), whereas the latter is not. Seeing the difference yet?

 

I understood that difference even before you explained anything at all. A computer checker can easily check for the presence of an attribute, it cannot check reasonably well for language that does not have to follow any format rules and it#s stupid to impose format rules and force humans to act so that computers can do some work more easily.

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