Map Not Found Caches does not show unfound caches [closed]

Question

I have several caches in Poland that have not yet been found. I noticed that they don't appear on the "Map Not Found Caches" in Project GC. Is this a bug or is there something I overlooked? Here is the list of GC codes that I can't see on the map: GCBQGK3, GCBN15X, GCBN15X, GCBN14D, GCBN147, GCBN13N, GCBN133, GCBN133, GCBN12D, GCBN121, GCBN10Y, GCBN10Q, GCBN10D, GCBN0ZT.

Answer 1

I checked two of the caches on your list. One had been found already, the other hadn't been found and it's showing up on the map. Since everything seems to be working correctly I don't see a reason to check the other caches as this just sounds like the data hadn't been fetched when you checked. The map can be several hours behind and sometimes even more when it comes to newly published caches.

Comments

And that's why you're not seeing your owned caches as the filter is required to include them. Case solved, it's working as intended.

---

OK, now I understand. That is very counterintuitive. A filter by definition excludes things. A user expects that without filters everything must be shown, and by adding filters I can show things selectively. That's standard logic in any user interface.

The page https://project-gc.com/Tools/NotLogged nowhere has the field "Profile name" (unlike "Map - D/T Matrix", for example), so nothing indicates to the user that the result will depend on the active account.

---

There are multiple filters that include stuff on Project-GC. For example almost every map tool on the site would be unusable if archived caches wasn't excluded as a standard and filters had to be applied to include them.

And it could be argued that all tools takes the logged in user into account as they show found status and/or if you own the cache as a standard.

With that being there will be a fix so that the filter is always shown for that tool.

---

I agree that not showing own caches by default is the desired behavior for this tool. After all, we usually use it to find opportunities for an FTF.

I just think it would be more logical to have a filter "exclude own hides" that is switched on and shown by default rather "include hides" that is switched off and invisible. This would be more consistent with the concept of a filter.

As I can see there are 5 "antifilters" with such inverse logic in the current interface:
- Include found,
- Include hides,
- Include disabled,
- Include archived,
- Include past events.

If these were not part of the "Add filter" drop-down list (because these are not filters) but always appeared on the page with their default on/off states depending on a particular tool, this would be much more understandable for the user. The fix you mentioned will hopefully address that.

---

What you're describing would be a horrible UX as the filtering would lead to "information overload" on lite 95% of searches, so no, that would not be more understandable for the user.