The A-Team

This is awesome and very timely. I just got back from a trip and have a bunch of Waymarks to log, so this will greatly save time by not having to go back in and edit the date on each one. Thanks for this and the other fixes!

I just came across this category and thought I'd give it a shot. I may have to enlist the help of a cacher, but I figured I'd start here to see if a Waymarker could help first. My name converts to 84 32.832. Using this as west longitude will be the most viable option by far. This longitude runs close to the following major population areas: Just west of Sault Ste. Marie, ON Lansing, MI Cincinnati, OH Lexington, KY Just west of Atlanta, GA Any help from a fellow Waymarker would be greatly appreciated.

Well, it's now been 3 months since this release. It looks like development has largely halted on this project, judging by the lack of further updates from Lackeys or changes to the search's behaviour. It could be that developers have been shifted off to start another project, which is what seemed to happen with many of the past projects that never reached completion. The lack of movement on even the critical issues is very concerning. It would be one thing if the users just had to deal with functionality that had been removed or didn't look as good as it could, but users are also having to deal with broken functionality. One wonders if the wider staffing issues have also hit HQ, and they're just scraping by with a few developers. I've said it before, and I'll say it again: if you don't have enough cash-flow to maintain the necessary staffing levels to support the product that is geocaching.com, it might be time to increase the membership price. Jeremy's promise was never realistic (and it had to have been around 20 years ago at this point), so I wouldn't worry about "breaking" it. With inflation these days, a price increase is inevitable and absolutely necessary. ...and by all means, if there's anything the community can do to help, please let us know. We all want this site to keep going.

Correct. The Friend League was introduced to track progress in the Mary Hyde promotion in 2017. It was later renamed to the Leaderboard and has been used for 6 other souvenir promotions since then, as well as the current Signal's Labyrinth one.

Thanks for those changes. They're both good improvements. That being said, these are improvements that didn't need to be dealt with right away. While these are greatly appreciated, even more appreciated would be fixes to some of the functionality that appears to be broken. This includes filters that don't work as expected, distances based on arbitrary locations in regions, and many other things that have been mentioned throughout this discussion.

I really don't have any issue with most of the proposed changes, but one thing that I'd like to see reconsidered is the merging of the "Waymarking.com Features & Functions" sub-forum into "General Waymarking Topics". That sub-forum is meant for bug reports and discussions, and it would be best if those were kept separate from more general discussions, similarly to how the analogous website and app sub-forums are their own separate entities.

From what I recall from a few years ago, the Personal Cache Note feature was partially broken in such a way that the search filter didn't work well. The issue was that when someone cleared out the contents of the Note for a listing, it didn't set the value back to "null" (ie. this listing has no Note), but rather just set it to an empty string (ie. this listing has a Note, but it's empty). This meant that listings where the user had since cleared the Note still showed up in search results when this filter was used. Rather than fixing the root issue by setting empty Notes to "null", they chose to just drop the search filter. At least, that's how I interpreted things. It could be that things later got changed since the last time I looked into this issue.

I also noticed another issue recently. The HTML title of the search result page is simply "Geocaching.com". When one has several tabs open, it can be easy to lose track of what one of these tabs is, since the title is so vague. Ideally, the title would include some of the filter terms, along the lines of "Geocaching - Search for [keyword] in [region]". At the very least, it could be something generic but still meaningful, like "Geocaching - Search results". As some examples of how a meaningful title has been done in the past, my public profile page has the title "Geocaching > Geocache Information for User: The A-Team", or the browse map has the title "Geocaching > Geocaching Maps".

I think the listed themes are pretty good and would be sufficient in most cases, but one that I think should be included is "Culture". My first Adventure is a tour of our local Chinatown. While I can certainly add three themes from the current list, not being able to add "Culture" is missing out on the primary focus. I can also think of several other Adventures I've completed or seen where the local culture is the primary topic. As mentioned by others above, "Cycling tour" is one other major theme that seems to be missing.

Interesting. I see the same thing. If you follow the links for some of the other event types, the URL uses "types=" values of 13 (CITO), 453 (Mega), 3653 (CCE), etc., and the correct results are shown. However, the "Event Cache" link using types=6 returns all of the event types, rather than only the type=6 "Event Cache" results like it should. I think I see why this is happening. On the search filters, all event types have been collapsed into the single "Event" filter. When this filter is selected, it uses "ct=6" in the URL. It seems that the meaning of cache type 6 has been redefined for the purposes of the search to represent all event types, not just the type 6 Event Caches. Rather than do this redefinition that we can see causes side-effects elsewhere, what the engineers could do is define a new cache type value that would represent to the server that all event caches should be returned, which would allow type=6 to revert to representing only Event Caches. As a side-benefit, this would also allow an improvement to the filters where the user could select the "all event types" filter that would use this new cache type value, or could specifically select one or more of the individual event types. I recently wanted to do a search for only CITO events, and it was hard to find them in the results due to the high proportion of Event Caches that were included in the results, since we can currently only filter for all event cache types.

Thanks onepooja. I can confirm that each of the above now works as expected for me. Hopefully the team can squash a bunch of the other bugs in short order.

Overall, I think this could be a good change once some issues get sorted out. Some have already been mentioned, but I'll list everything I see (in no particular order of importance): When doing a region-based search, the distance (and therefore initial sorting) is based on some arbitrary point, maybe the geographical centre or geocoded coordinates of that region. With the previous search, and the expected behaviour, this distance would be based on the user's home location. The "Filtered by" toggle just toggles and does nothing useful. I guess it's supposed to hide all the individual filter elements displayed below it? The date formats don't respect the user's site-wide setting and seem to be forced to the US "mm/dd/yyyy" format. The hover text in the "Geocache name" column is inconsistent. If you hover over the name, GC code, or hidden by, those all show the cache name. If you hover over the region, it shows the region. The hover text should either each show their respective text, or all show the cache name. The cache owner name would probably be expected by many to link to the cache owner's profile, but it isn't hyperlinked. Hyperlinking this would be a useful improvement. When a cache is in a region where there aren't any sub-regions defined on the website (e.g. Zimbabwe), the location is shown as "None, Zimbabwe". If there isn't a sub-region, that part should be omitted. The linked number in the Favorites column has very different formatting than the rest of the text in the list (e.g. blue, smaller, and Tahoma rather than Noto Sans). This should be made consistent with the rest of the text in the list. In the Filters dialog, clicking the "x" at the top-right would be expected to simply close the filter dialog without saving changes, as opposed to clicking the "Apply" button to intentionally save the changes. However, clicking the "x" does save changes and re-performs the search. The "disabled" or "premium" badges shift some of the other text out of alignment compared to other caches that don't have the badges. This makes it more difficult to scan down the list looking at an element like the location, since the position of that text varies. In cases where a cache is both premium and disabled, the badges can cause the location text to get truncated. The badges should be moved to another spot so they don't affect the position of other elements. There's no hover text on the cache type icons or additional badges (e.g. Found, DNF, Owned, Draft, Personal Cache Note, Corrected coordinates, etc.). The prioritization of columns respective to the size of the screen seems odd. From narrowest to widest screen size, these are the columns that are displayed by default: Geocache name, Favorites Geocache name, Distance, Favorites Geocache name, Distance, Favorites, Info, Size, Difficulty Geocache name, Distance, Favorites, Info, Size, Difficulty, Terrain, Trackables, Last found, Placed on (all columns) There could be more intermediate steps between the last two modes, and the D/T ratings should always be paired and never show the difficulty alone. I can't remember if this was an issue with the previous version of these lists, but steps should be taken to ensure the cache name never gets truncated. These steps could include font size changes, wrapping, column widening, etc. The width of the result list is capped at 1440 pixels wide. Many modern desktop users have a 1920-pixel-wide display, so the list could take advantage of that extra space (for example, to help rectify the name truncation I mentioned in the point above). As mentioned by others, archived caches aren't shown when expected. I know that's a lot, but a number of these are fairly small bugs or improvements, or things that could be put on the roadmap for longer-term development. Since the team has just recently been working on this, though, I expect a bunch of these could be knocked off pretty quickly and this could be made into a pretty good piece of the site.

Ah, yes, I see now that changes were underway and I must have been caught in the middle. The regional filter is working correctly now.

When I try to filter a search to a country, the search just loops back to the home page again. This can be reproduced in one of two ways: Type in a country and select the "Regional search" Click Filters, type in and select a country, then click Apply In both cases, rather than the country filter being applied, you just get redirected back to the home page. The regional filter works as expected if you select a national sub-region (ie. state, province, bundesland, etc.). I see the issue in both Firefox and Chrome, and for any country I tried.

(Never mind. I think my post was too off-topic)

I've been using the new drafts page for quite some time, so I've largely gotten used to it and don't have any major complaints (other than having a graphical representation of the log type, which would indeed be a big improvement). However, the above quoted item is one that I've never understood. I take lots of photos, and I always try to upload them to the closest cache. One of the easiest ways to match things up is to compare timestamps between my photos and the logs. When the new drafts page was rolled out years ago, a design decision was made to intentionally hide the timestamps, and I don't understand why. What's gained by doing so? It only hides 5 characters of text, so it can't be for decluttering. If you're going to have the timestamp there, why not just make it visible all the time? It would be far more useful if it was, because then a user could easily glance down the list without having to hover. Or am I just missing something, because a UX designer at HQ must have had some good reason for hiding the timestamp?

I'm a bit torn on this. While I was a bit surprised that the new souvenirs are now very basic, I think it's still better than having to wait 13 years for the rest of the souvenirs to be released. Hopefully the plan is for HQ to gradually upgrade these graphics over time. It would be a shame if the digital souvenir for finding a cache in one of these rare areas just remained a cookie-cutter one. Members should be proud to show off the souvenir they got for finding the only cache on Pitcairn Island, for example.

I just noticed that a batch of 10 souvenirs has been released. Do you happen to know if you got the Bermuda souvenir on Wednesday or Thursday? I'm sure people don't look at their souvenir list daily, so it might be hard to pin down the release date. HQ did say that they'll be released on Wednesdays.

...and I just got a different error on another failure: Uncaught (in promise) ChunkLoadError: Loading chunk 30 failed. (error: https://www.geocaching.com/account/app/dist/drafts.82c6351f3dc8db66a234.js) requireEnsure https://www.geocaching.com/account/app/loader?v=y5dtdolMOQVQVsar8Ho3xmNlvAawYKlTMovR1WRgS1E1:1 drafts https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 execute https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 route https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 loadUrl https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 any https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 loadUrl https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 start https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 onStart https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 triggerMethod https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 start https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 467 https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=y5dtdolMOQVQVsar8Ho3xmNlvAawYKlTMovR1WRgS1E1:1 244 https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=y5dtdolMOQVQVsar8Ho3xmNlvAawYKlTMovR1WRgS1E1:1 checkDeferredModules https://www.geocaching.com/account/app/loader?v=y5dtdolMOQVQVsar8Ho3xmNlvAawYKlTMovR1WRgS1E1:1 webpackJsonpCallback https://www.geocaching.com/account/app/loader?v=y5dtdolMOQVQVsar8Ho3xmNlvAawYKlTMovR1WRgS1E1:1 <anonymous> https://www.geocaching.com/account/app/mainJS?v=vgSt3QimGLyrZ1K4z5cCeq1hgMWY-DrUn5qiaG1tXZU1:2

I just thought to check the debug console and found some errors. These seem to occur each time the Drafts list fails to load, so they're likely related. Uncaught TypeError: t.Model is undefined exports https://www.geocaching.com/account/app/mainJS?v=PqCEbdDR_kqyZoajS3trXf0E92VGTtd1FAG3PTLrLL01:2 33 https://www.geocaching.com/account/app/mainJS?v=PqCEbdDR_kqyZoajS3trXf0E92VGTtd1FAG3PTLrLL01:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 38 https://www.geocaching.com/account/app/mainJS?v=PqCEbdDR_kqyZoajS3trXf0E92VGTtd1FAG3PTLrLL01:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 485 https://www.geocaching.com/account/app/tou?v=_ewbPxQ8cCxRtmgLU7mFjQG_Nr7sYuXQZiNgOPWpPnE1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 484 https://www.geocaching.com/account/app/tou?v=_ewbPxQ8cCxRtmgLU7mFjQG_Nr7sYuXQZiNgOPWpPnE1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 checkDeferredModules https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 webpackJsonpCallback https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/tou?v=_ewbPxQ8cCxRtmgLU7mFjQG_Nr7sYuXQZiNgOPWpPnE1:1 mainJS:2:143949 and Uncaught TypeError: Re.getStagingDomain is not a function <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 513 https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 512 https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 checkDeferredModules https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 webpackJsonpCallback https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1 vendor:2:736198 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/vendor?v=3ABfI4zIdLByN7KP8euOmOpnlREH_vP3aOHPIiqa2Cw1:2 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 513 https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 512 https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1 __webpack_require__ https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 checkDeferredModules https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 webpackJsonpCallback https://www.geocaching.com/account/app/loader?v=PQm-CSyiLp7wU40xm4eZOQiVqpmXJIKUW3Yfgzau7Vc1:1 <anonymous> https://www.geocaching.com/account/app/signUpValidated?v=f8rhaNAFXEa6RF7pMZ7F6Y9RspHT0y09oz9F_R__mis1:1

I'm currently seeing the issue on the Drafts page. If I log a cache and then refresh the page to update the list, about half the time the Draft list doesn't load and I just get the spinning circle. Occasionally, even the menus in the green header bar don't load. Refreshing restores everything on average about 1/3 of the time. This is in Firefox 95.0. Could it be related to which web server we each happen to hit? Is there a way to see which one we're on anymore, or is that no longer in the source code? I don't see it in there anymore.

According to the promotion page, the souvenir is only for logging one of the trackables. It only mentions "a special math bonus" for finding all five, not another souvenir.

Oh hey, I just noticed that my name was invoked. I haven't been hanging around here much, so I only just noticed. Souvenirs can be grouped into a few major categories: Attending a Mega/Giga event Finding a cache in a region (ie. country, state, province, etc.) Finding all of the caches in a GeoTour Date-based (ie. finding a cache on a specific day/weekend/week/season) Finding specific caches (HQ, Original Cache Location, Project A.P.E., GC8NEAT Locationless, or one GPS Maze) Other Marketing promotions (e.g. 15 Years of Geocaching, Reach the Peak, Wonders of the World, etc.) Notable milestones (so far just 3 million caches) For a few years, World Wide Flash Mob events (2011-2014) Special one-off (e.g. Creation Celebration, Maker Madness, Mars Perseverance Rover, Texas Instruments Spread Math Love) Other others (2010 BSA Jamboree, Marination! test souvenir) You could come up with a fairly short description to cover most of these, but then things get more complicated when you get to the "Others", where there's a much greater variety in what you need to do for each one. One thing that they seem to have avoided is awarding souvenirs for accomplishments. There have been many requests in the past to award souvenirs for things like filling your calendar, Fizzy or Jasmer grids. It seems that they're happy with leaving those to be covered by challenge caches.

This has been a longstanding issue. The root of it is that when you remove a note, it isn't actually removing it. I believe the fix is relatively simple, but it must not be a high priority. Here are the two cases that can occur: 1. A listing that has never had a note - In this case, the note field is set to "null" (ie. absolutely nothing) 2. A listing that had a note, but then you clear it out - In this case, the note field is set to a zero-length string It's a fine distinction, but in programming it's an important difference between "nothing" and "something, but with no content in it". When something like the list page checks for a note, in case 2 there's technically a note (albeit with no characters in it), so it flags it as having a note. In order to fix this behaviour, the site would need to be modified to do one of the following: 1. Consider zero-length notes as empty, in addition to null values 2. When someone clears a note, set the value to "null" It seems that they've made some changes to the logic on parts of the site, as you saw where the listing page isn't showing the badge anymore. They just need to carry that same behaviour over to the other places where the badge is shown (lists and map).

I'm not sure exactly when it happened, but it looks like this issue has been resolved recently. The GPX downloads now contain the expected data again. Thanks to the developers for resolving it.