Programmatic Execution of Challenge Checkers

Question

Since p-gc's challenge checker technology is the authoritative source for geocaching.com hosted Challenge-Caches, it would be of great help if p-gc provided a REST API through which a checker could be programmatically executed and the results returned back for instance like this:

{

   conditionMet: "true",

   logTextFragment: "User xyz has met the challenge conditions for geocache GC1234 ..."

}

Comments

What would be the use for this?

---

caches frequently are laid out in series, sometimes called power trails. There exist such power trails which are actually all challenges. Preparing a tour, I assemble them all in a spreadsheet and I would like to iterate through the list of GC-Codes and call the REST API in question here and get a "true" or "false" for each of them, indicating whether I meet the condition or I don't.

Let's say there are 47 challenges in that round and I get a "true" for only 9 of them, I might conclude that it isn't worthwhile (yet) to pursue that tour. On the other hand, if I get 39 times a "true" I might go for it.

The whole scenario would not only run in a Spreadsheet, instead, If that REST API existed, I'd write a GSAK macro and execute it on a carefully filtered GSAK database.

---

one year now and no response from anyone really in charge at p-gc?

Had it helped if I'd better outlined the use case? Well here we go:

I want to write a GSAK macro to run over a filtered GSAK database and get the challenge condition met or not met programmatically for a list of geocaches, which happen to be challenges. This is what I'd use the REST API call for.

---

I don't see how you can complain about one year response time when you yourself have the same response time.

I doubt this will ever happen since what your asking is for data to be stored in a way that it's cyrrently not. I don't see why Project-GC should supply you with a special API for use with a different 3rd party program, putting more traffic on their own servers without any benefit for them seems like a bad business decision.

---

I had actually hoped somebody officially representing project-gc feature development could have a look at it and then come back with an answer.

I see your point of course and from my perspective it is actually Groundspeak who should come up with challenge checkers and they should extend their Live API by a method which returns "true" for challenge condition met and "false" for challenge condition not met.

As a matter of fact, Groundspeak has completely offloaded (subcontracted?) the challenge checker logic to project-gc, so project-gc is the only entity that can technically provide this type or REST API, which is why I am asking here and not at Groundspeak.

And with respect to business decision: I am a paying customer and I am sure there are many more paying customers who would use that service, most of them not being programmers of course would use it as as GSAK macro. Unfortunately those folks don't speak up here nor upvote on the proposal but be assured they would happily use the GSAK macro based on that REST API service.

Answer 1

While a rest API for several functions have been under consideration for years, and probably will happen at some point, this api method wouldn't have the highest priority.

By reading the reason to why you want this in the comments I would like to state that you don't need an API for it. As a paying user of Project-GC you can already see the true/false state on our maps.

When you can't it's because the auto-challenge-checker system hasn't run your account on those particular challenges yet. That can be solved in many ways (by us). For example we have been looking into letting the users target specific areas instead of emanate from the users home.

Another variant would be to be able to let our system run challenge checkers on all geocaches in a Virtual GPS. That is also something that would make more sense to us than letting users run challenge checkers via API methods.

Comments

First: thx for taking the time answering.

I do actually make use of the true/false state shown on the map. Currently, by looking at the map I manually take down a specific marker which I put into the PCN field of the cache such that I can later run queries based on that marker.

The situation for many of us is that we go on a hike and when we hit challenge caches where we don't meet the conditions, we put a "Write Note" log in and later, once we meet the conditions, we either log a new found-it or convert the earlier write note into a found it. That is best practices and complies with the GC's guidelines.

Now here comes the point: in order to do so, we need to re-run the checkers in order to figure out when we actually have met the conditions. Therefore the API as we certainly don't want to manually do the thing on the map.

If procject-gc implemented the method you pointed out at the bottom of your answer, running the checker (periodically?) on a VGPS, then I would  put all challenges in question into that VGPS, export it as a GPX and process the result in whatever tooling is appropriate, e.g. GSAK, In this case I'd need the true/false somewhere in the GPX otherwise it isn't of much use really. I'd assume the true / false could be placed somewhere into one of the "User" fields that are already there, assuming they make it into the GPX then. Of course there would be other means to put it into the GPX, feel free to come up with our own ideas, whatever fits into development.

Thx again for your answer

---

Actually, your use-case where Challenges have notes is already fairly covered by Project-GC. You should read https://project-gc.com/w/Auto-challenge-checkers#Background_processing for more details about that system. Specifically the highest priority (#1) item in the list of nine points.

Sure, it's not daily, but fairly close to it.

Disclaimer: The Auto-challenge-checker system is a paid feature and therefore not available to all.

---

I have read the referenced documentation and it is all nice and dandy. Still it requires visual check on a map and manually processing the results, e.g. typing something into the PCN field of the cache for which I now meet the condition. At least that's how I understand it. Am I missing something?

Above where you mentioned to run the checkers on a VGPS, that would actually do the trick if, and only if, the true / false also goes somehow into the GPX that I would periodically export from the VGPS and the GPX would be something I can programmatically consume afterwards.

---

@hxdimpf You don't have to look at the map, just look at the challenge tab in your profile stats. It lists all challenges you have a note on and the green/red icon based on the result from the auto run challenge checkers.

---

"a note on" ... you mean I have logged a "write note"? What about those I haven't visited yet? Assume there is a power trail of all challenges. I want to put those into a VGPS and execute an export GPX let's say weekly and then programmatically parse the GPX. Visually looking at something, whether it is a map or a table in the stats just doesn't cut it.

On that power trail: I wouldn't even go on a hike if I'd only meet the conditions of 8 out of 40 challenges. Once I meet let's say 32, I'd go and log write not on the remaining 8.

I won't push on the VGPS anymore, I am sure you technically understand the use case and what would need to be done in order to make it happen. Whether you do it is of course your decision.

At least I agree with you, it isn't really required to run those checker real time in the context of a REST call. Your periodic checking in the background is sufficient, it is just about how you make the results available for consumption.

I rest my case now ;)

Thx much for your help

---

Or if you want to "game the system" in the meantime you could just post notes on caches and wait for the system to run the checkers for you. Also you don't seem to realize that your talking to two different people here since your answering stuff I haven't said so I'll just leave this conversation totally now since you don't seem interested in my input either way.