Hey,
I want to hide a Challenge Cache with the Geocode GC9DDQB. To fulfill the Challenge, a Geocacher has to have found at least one Geocache on all "Distance to finds" sectors that can be found in the GC.com statistics (see the example image below). As far as I understood the guidelines, such a challenge should be possible, but please correct me if I'm wrong. I do fulfill the challenge as well of course.

Thanks in advance to the friendly challenge checker creators :)
Felix/Feluko



Edited 1 time(s). Last edit at 07/01/2021 11:34PM by Feluko. (view changes)

Howdy,

So while your idea appears to comply with the geocaching.com guidance, there is a technical limitation in the project-gc api that prevents checkers from accessing home coordinates. This make us implementing this as a.checker imppss9ble at this time.

There are a couple of options to work around this. The first is to center the finds on the cache locatiion. You would want to check with your reviewer on that being acceptable. Some might call that an arbitrary polygon.

The other is we can request an extension of the API to compute the chart you ask for.. that will likely take a long time just because there are other priorities for the site.

Both options have risk.

I wish I had a better answer.

Hello sloth96,
Hm, sad to read this. I thought you guys had access to the home coordinates as the Project-GC profile stats shows stuff like "nearest/farthest cache" and "cache centroid is xxx kilometres away from home". I don't want the cache to use a given coordinate for the distance, because I want it to show the same result as the statistics-page on GC.com.

So the question for me is now if I wait for a new script or if I decide to drop the idea. I think I'd rather like to wait for a new script then.

Thanks
Felix

No point in waiting, please READ FIRST

Quote
What a checker can not do
* The checkers does not have access to the user's home coordinates. Challenges are not allowed to be based upon them either, and haven't been allowed to for several years. This is a matter of integrity.

Hi vogelbird,
I know that challenges can't require to show for example the GC-Code nearest cache to the user's home coordinates as this would compromise their privacy. However, this one would just show how many caches within a certain range from the home coordinates have been found by the user. This does not compromise the privacy of the user (I don't want the checker to show any GC-Codes of Caches in the distance ranges). I have read through the challenge caches guidelines on GC.com and have not found anything that would speak against such a cache. Only the "Read First" from Project-GC has this point in is so I assume that either this has been added as an example of a cache that could compromise the privacy of users or that there is not yet a script for challenges based on home coordinates. As said, the GC Website has this stat in their statistics page which doesn't show many different statistics and the website clearly sais that it's okay to use "information broadly available on Geocaching.com". So this part of the read first is most likely not because GC would not permit this - at least I don't see a reason why they shouldn't after reading the challenge cache guidelines.

Felix

There is also this hurdle:

Quote

Challenges based on geographic areas other than countries, states/provinces, counties (or their local equivalent). For example, user-defined mapping polygons, latitude/longitude, radius, etc.

If you want, you can always ask your reviewer or HQ to get a definitive answer, but I don’t think the API will include the home location any time soon.

There is a get farthest api call we have access to. I am not aware of a script using it. It is documented here

https://project-gc.com/doxygen/lua-sandbox/classPGC__LUA__Sandbox.html#a91560b921f4a4ce5e0e85f3b15ad6c2b

So would it be possible to create a checker based on this script? I would try submitting it then as I don't really think that Groundspeak would have anything against such a challenge.

No. We may only be able to show one cache and that callay be buggy as it is likely untested.