Clan-Wallace

That mystery is full of Red Herrings and I've been caught 'Red' handed with another Red Herring. My face is 'Red' . Sorry for the fuss.

No, I had not solved it. But that's a worthwhile check to test. Just a case of finding another one that I have a solution for (or can solve) that also has a solution checked but returns false. . Message me if you find a candidate.

The API call to check if a cache has a solution checker generally works Ok. But the call fails for some caches. For example: $data = gcapi2("geocaches/GC81P9G?fields=referenceCode,geocacheType,hasSolutionChecker","GET") Returns false: {"referenceCode":"GC81P9G","geocacheType":{"id":8,"name":"Mystery","imageUrl":"https://www.geocaching.com/images/wpttypes/8.gif"},"hasSolutionChecker":false} But, as you can see, GC81P9G does have a solution checker. Is this because the the cache page does not have the 'newish' solution checker attribute? If this is the case, an easy fix would be to update the database to add that attribute if it does not exist for all caches that have the 'newish' Geocaching solution checker. Or am I missing some non-sensible reason why this API call is returning an incorrect value?

Found Lab Stages do have a Log Id but they are out of sequence with Cache Ids. So you are correct in that displaying ALs and Caches together, we get all the Caches in one group and all the Lab Stages in another group, albeit, at least they are on the same day found. Because Lab Stages do have a Log Id, you can display them in the order they were found within a specific day. Take a look at some stats' my macro produces, For the AL Source to sea: The River Hamble, I deliberately found some on different days and a couple on the same day just for testing. The different days are in order and if we focus on the same day I completed two labs, 2023-08-18, we can see that Lab 5, LBU6Xi05 (As stored in the GS database) was Find 4 ( Overall 552 ) for Adventure 95 and then I found another different AL Lab Stage (Overall lab find 553). Then I came back to the next Lab 3, LBU6Xi03 which was Find 5 ( Overall 554 ) for Adventure 95. So it is possible to have a bit of history.

'Archived is not the same thing as 'Found Archived' (Or Found 'Private' or Found 'Off'). In your 'MyFinds' PQ, you get all your 'Found Archived' caches and if you follow the URL of that cache, you access the 'Found Archived' cache details. 'Found Archived' caches are part of your total finds. 'Found Archived' caches are part of your Geocaching history of where you have cached and part of your geocaching statistics. Users would be very unhappy if GS removed 'Found Archived' caches from their MyFinds data and it would make no sense if they did. When GS made Lab Stages into Geocaching finds, they became part of a users total finds, their history, their statistics and they expect, that when you follow a link on their Lab Finds web page, they can view or record data for their found Adventure. Now this is true with the current Lab Finds web page, we can do all of these things, even for 'Hidden' Adventures. But we are missing the point of this post. Why do some 'Hidden' Found Adventures (I only have one out of my 10 hidden ones but I know others are also experiencing the same issue) suddenly have 'broken' links?

When looking at the Adventure Labs View Finds web page, when you select the banner of an Archived (non-public) Adventure, it correctly takes you to the Adventure's description page, which also has the QR code so that you can scan with the AL App to open that Adventure for more details. If you shared the link to the Archived Adventure with a user who has not found it, they do not get access to these details. I get that. However, just lately, some of these Found Archived Adventures return Error 500 and are no longer accessible. In fact, we have a broken link, which will give any web master a very poor rating using the various web tools. If I use the AL App and filter on Completed ALs, then try to view one of these Adventures, they do not appear in the App. If I try to access the Adventure via the API using the Adventure Id, we get a 404 status code and obviously no returned data. Can it be explained to me why I am no longer able to access, in any way, some of my Found Archived Adventure details? While on the subject of Found Adventure Labs, with Caches, we can download the 'MyFinds' pocket query, which also includes all the Archived Found Caches. Can the web page include an option to download our Adventure Finds in the same way so that we can combine all our finds together as waypoints in an app such as GSAK? This would allow us to correctly generate stats for our Geocaching activities. Such as in the attached image.

That is now 13 THIRTEEN years since Ground speak was first informed that the GPX generator does not include additional information that is available in the API, (leading to their users having to place additional burden on GS Servers in order to get this missing, required data) and no representative of Ground speak has had the decency to respond to this ongoing issue in all those years. What is the point of these forums if your customers are not listened to and acknowledged?

If you navigate to a cache page, say https://coord.info/GC913JF and then follow the link to View all logs, the website uses the cache's GUID to access the logs, https://www.geocaching.com/seek/geocache_logs.aspx?guid=47153c79-a741-4427-85d4-4b6437e5dd66. On days gone by, this cache GUID was made available in Pocket Queries and through the API. As my code can no longer obtain the Cache GUID, my link to access the logs directly, Cache Logs, no longer works. My link to Gallery Images for the cache has been updated to use the Cache ID, https://www.geocaching.com/seek/gallery.aspx?ID=7933816. Interestingly, you can still access the Gallery Images using the old method, https://www.geocaching.com/seek/gallery.aspx?guid=47153c79-a741-4427-85d4-4b6437e5dd66 May I kindly request that the URL links for Cache Logs also be updated to use the new method, CacheID? Thank you.

As @Goldenhawk never let us know his test findings, I have been creating some Custom URLs in GSAK and have been searching for an answer on how GSAK could use its Special Tags to access the Message Center for a specific user (Not their email). As @Goldenhawk indicated, we can get to every useful page for a specific user on the Geocaching site using the Owner Id instead of the Owner Guid and other special tags, except for the Message Center. The Custom URL that gets nearest to that requirement is this: https://www.geocaching.com/account/messagecenter You are now in the Message Centre but not in the users specific conversation However, you can now either: Click on a user name in the left-hand column. Type in the user name in the search text box at the top. So now I have a Custom URL with the name Message Centre, in a folder named GC.com, created like this: GC.com\Message Centre=https://www.geocaching.com/account/messagecenter?%OwnerName Following the link opens the Message Centre but not in a conversation with the specific Owner. However, the Owner Name is displayed in the Address bar ready to be copy/pasted into the search box. Now, in GSAK, selecting this Custom URL opens the Message Centre for the currently selected cache, whose Owner is JoeBloggs and the address bar displays https://www.geocaching.com/account/messagecenter?JoeBloggs. A quick copy/paste of JoeBloggs into the search bar creates a conversation with the user. As it appears, there is no way of getting the Users GUID from the API, I believe this is the best we can do, unless anyone knows better.

Mapping is broken: Example: Malta Regional Search gives Which is correct for the listing but when "Map These Geocaches" is pressed we get: Just 4500 plus miles out.

Groundspeak wet our appetite by making the API available. We spend many hours/days/weeks developing code to access the API in meaningful ways to aid the geocaching community plan their trips and not have to revisit locations already visited, avoiding time wasting, extra expense, additional carbon into the atmosphere, etc. Then bang! No access to the original API. Shame on you Groundspeak. The very least you can do is to make the lab stage locations and whether or not the adventure needs to be done in sequence within the final (restricted) API.

User-Defined Child Wapoints There are numerous Geocaching Apps and software (like GSAK) that are available and almost all of them have the ability to add custom child waypoints for a specific cache. That's all very well but if you use more than one app or device (as many of us do) or your membership is shared with a partner / family member / team, then in each and every case we might have to add that same child waypoint, repeatably. Surely it makes sense that GC.com is our central database for all caches of interest to us and the ability to add user-defined child waypoints on the cache page would rectify this issue for one and all. You download caches and there are all the additional custom waypoints, whatever app or team member makes the download. (One ring to rule them all). Feature Enhancement If this much needed feature is hopefully provided for us, perhaps an additional child waypoint feature could be added. That is, a 'Calculated Child Waypoint'. All that would be required is instead of entering coordinates, you would be able to enter the formula that will be used to calculate the coordinates once the answers have been collected, as in many Multicache scenarios. The note field would also be utilised so that the user can enter a cut-down version of the information about where they need to look for answers and the questions that need to be solved. (Rather than trying to scan through an over-bloated description, in italics, in fading light on a rainy day). Here's an example of how this might look: P0 P0 Church Car Park (Parking Area) N 53° 04.258 W 001° 42.569 Note: There's a narrow entrance to the left of the Church C0 C0 Muti Stage 2 (Calculated) N53° 04.(A+A)(B-E)(C-D-D) W001° 42.(D+E)(C+F)(E+G+H) Note: As you enter the churchyard, to your right, you'll see a plaque in memory of Joanna Rugman. She lived from ABCD to EFGH. Checksum: 48 (or perhaps: Checker available) Application developers, including GC.com, could easily parse the formula with regular expressions to check it is a valid format, valid expressions and then create textboxes for each letter parsed. This would allow the user to enter a value for each letter and the app would calculate the result. Allowing the user to set this calculated set of coordinates as the final location. I feel sure many members will see this feature and its enhancement as a very useful addition, aiding us in our Geocaching Adventures.

I can see that 'Groundspeak Customers' have been requesting an update to the old GPX format, still in existence today, way back in 2011. It looked like progress was being made in 2014, with more Customer frustration appearing in 2016. This post now makes that six years with no action taken as far as I know on matching the API to the Pocket Query generation tool. The new Advanced Search tool is a good example of improved use of the API. The pocket query tool could offer many more filter options and generate a new GPX format that contains many additional and useful items of data that is currently accessible through the API. Surely this also makes economical sense? How many Customers download the current GPX format and then have to use other applications, like GSAK, Android and IOS apps, which place further load on the Groundspeak servers, in order to download missing information they need to enhance their geocaching experience in the field and back home? Can a member of Groundspeak re-assure us that we are being listened to and action is being taken to fulfil these missing features that would make it better for everyone, including Groundspeak? Thank you.

OK, we want a flag for England, Scotland, Wales and Northern Ireland, which also qualifies for UK as a whole. I am happy to design the artwork. What's the procedure to initiate and implement this?