Megalodon

I am using GSAK and in a self programmed macro a am requesting a GC code and it's status: $data = GcApi2("geocaches/$codeGC?fields=status,referenceCode","GET") If the request is for a geocache code (I used 'GC5O234' here) that has been archived already and the GC code contains an 'O' (the letter !) like the one I used (GC5O234), the return code is not ok. The API comes back with the response: status:archived and referenceCode=GC50234, so the letter 'O' I used when requesting was cachnged to '0' (the number). I would have expected, that I get the status of GC5O234, not the one from GC50234. The same behavior I realized with GC codes containing an 'S', the result is the used code by the API ist '5' nad not 'S' Why this correction in the API response ?

I just found on the Groundspeak webpage: Adventure Lab New deadline: March 31, 2021 We have extended the deadline to March 31, 2021 for all Adventure Labs to go public. HQ will monitor changes over the next few months to see if further adjustments are needed. There is no need for those with Adventure Lab credits to write in to request an extension.

The biltema caches are the biggest bulls*** that has ever been created/invented, because they are handled differently in Germany/Europe according D- and T-values: -in some parts they are T5, because you need a fishing rod to get them (they are hanging up to 10-12m in a tree) -in other parts they are D5 for whatever reason, I do not know (I think it's not that DIFFICULT to get them down with a fishing rod that is long enough) The results of these biltema caches are: -you can forget the 81 matrix, because D5- and also T5 caches can now be earned with biltema caches, you don't need to solve a hard mystery anymore for a D5 and you also you do not need to climb up a tree - just a biltema cache is enough, it's done in minutes. -you can not be sure to have a climbing or boat cache, if it is a T5, it could also be a biltema cache -you can not be sure to have a hard mystery or multi cache to solve, it could also be a biltema cache -special tool required does not tell you, if you need a fishing rod, a lock picking set or something else Since we have biltema caches, it's the owner's descision to make it a D5 or T5, the information of these values are worth NOTHING, they do not tell you, which cache type or difficulty you can expect and even not how hard to get your caches have been that you visited. Now everybody has the best statistic values, but they are only pimped !!!

yes, of course and these others do need 4 digits after the comma to more precise?! Let's see, the bikers for better knowing how they have done the curves? The walkers to know, if they used the left or the right track of the ants? The fishers to know, if they found the best place to catch the biggest fishes? Or the ones going by boat to find back to the place where they spotted the dolphins yesterday? ...just joking, sorry. Back to the point: I do not want to use the 4 digits, because I have to take care of two more numbers when entering a coordinate. Garmin offers it in the configuration and so they should implement it and now fix it, that's all I expect. The device is quite good, I like it.

I can of course ignore the 4th decimal place, BUT if there is an option to use 3 or 4 digits after the comma, I would expect that to work and not to offer ALWAYS 4 digits. For me it's the problem when I enter a corrdinate, I have to manually skip the 4th digit, even if I DO NOT NEED it !!!!

wow, no answer is also still an answer, something about, we just don't care...

Now we already have firmware 5.00 - but still no possibility to change the prcision to 3 digits after the comma of the decimal minutes? Really?

The new API function has different results: 1. coordinates are correct 2. coordinates not correct 3. forbidden (in case of using the function on caches which have NOT the geocaching.com checker enabled) 4. API limit exeeded (in case of using the checker more than 10 times in 10minutes on the same GC number)

Big "Thank you" to the engineers, they fixed it and I tested it already and it's working fine. The only thing that I am missing is an expand to all mysteries. It does not make much sense (to me) to be able to check only the new mysteries which are using the geocaching.com internal geochecker.

There is a problem in this new function. As an example I refer to the following mystery: [GC Code removed by moderator] The checker uses the coordinates in format decimal minutes (i.e N 51° 18.035 E 1° 16.456, this is the solution the checker accepts -> green !). Convert it to degrees in decimal format, you get: N51.300583 E1.274267 If I use this solution with the new API function, the result is a red checker. If I use N51.300584 E1.274268 for the checker, the reult is correct (green). Two possibilities: 1. the checker also accepts solutions that may vary by '1' in the 6th decimal place (0.000001) 2. the internal solution in the database is rounded correctly from the decimal minutes input format to decimal degrees.

Sorry, I am only asking myself who is taking care of the API, a single person ?

What does it mean "not well-received" ?

Wow, that's really interesting. You are right, they both should return the same result. I just retried what you wrote and I can confirm the API I use in GSAK does NOT return the same result as the Checker on the website ! I am very interested in the explanation from the API programmers.

That's it, exactly ! But it would also be fine, if the save the solutions correctly rounded wow: the moderator is quick in geleting GC numbers, but how about an answer ?

There is a problem in this new function. As an example I refer to the following mystery: [GC Code removed by moderator] The checker uses the coordinates in format decimal minutes (i.e N 51° 18.035 E 1° 16.456, this is the solution the checker accepts -> green !). Convert it to degrees in decimal format, you get: N51.300583 E1.274267 If I use this solution with the new API function, the result is a red checker. If I use N51.300584 E1.274268 for the checker, the reult is correct (green). Two possibilities: 1. the checker also accepts solutions that may vary by '1' in the 6th decimal place (0.000001) 2. the internal solution in the database is rounded correctly from the decimal minutes input format to decimal degrees.

As far as I know only 10 checks in 10 minutes are possible using the API, just keep calm, arisoft.

I do not only want the HQ to respond. I only want the new API function "check coodinates" to be extended to more than just the ones using the geocaching.com internal checker.

Why do you only share your opinion? I wanted to make clear, that giving this new API option is totally nonsense so far, if only the caches which enabled the internal checker can be tested. How about an answer of the groudspeak HQ ?

nice to know, but the caches which can be checked then are very less, so this way the new API function is not needed. Otherwise tell me for what should it be used ?

but every mastery cache needs to have a final coordinate, right ? and if there are some cache you need to find and/or there is no final coordinate (older caches?!), so the response could be 'n.a.' and not true or false.

I like this new added function, but not only for caches that use the geocaching internal checker. This does not make any sense to me, becacuse none of the old caches have this one in use and many owners do not use it. How about implementing this possibility to check the already found solutions ( I use a single 'solved mysteries' database in GSAK) for ALL mystery caches?

I know the 404 errors have already occoured weeks ago, but not that frequently, I admit. So thank you very much for getting it fixed !!! Keep an eye on it and tell the engineers they have to test it first before they do the changes right 'on the fly'. Greetings from another engineer

that is not the problem. geocaching.com has a generally problem with requests, not just the GC codes which results into openeing the geocache listing, but also with profiles of users, geocache logs, trackable pages etc. Why do I not wonder, that no admin of the website answers ?!

This error is getting more and more old. "It's not a bug, it's a feature" ;-) I do not know why or for what I pay my 30 Euros per year: Groundspeak only has the servers, they own nothing else, the boxes and everything else in the game ist OURS, it belongs all to private geocachers taht have to pay 30$ or something clos to it per year, only for maintenance of some servers, that's all. How about taking care of a bug that is known for weeks now ?!

Just today I remind me this error with too many finds for changed notes, but which are NOT changed any more still exists. It's a month ago now, how about asking the guys at Groundspeak to fix this issue, it's not that hard to fix, I think, is it ?!