ACME WildCachers

If this was added, I would want an option to globally disable it. I often have notes in progress with coordinates in them that are NOT the actual corrected coords because I haven't solved the puzzle correctly yet. I would not want Cachly to assume that any coords in my notes are definitely the corrected ones. If this were an optional setting, would you want coordinates detected in the personal cache note to be saved as a corrected coordinate waypoint which would filter back as corrected coords to geocaching.com?

I created an account and tried to edit my user page with the same result. The URL after I saved my changes had something like modqueued (I didn't save it) which would seem to indicate the change has to be approved. Assuming that's temporary or something is misconfigured.

Had to be mostly virtual waypoints, right? @rragan, how long was the hike?

Will you add the nickname field? This is where I have caching usernames stored and was confused why I wasn't getting the option to call anyone.

@barefootguru I understand how the My Finds PQ works. My question was about whether updating all caches in that offline list would update the logs in such a way that my own would no longer be there if there were many logs posted after mine. I had time to test it out tonight, and here's what I found in case anyone else is curious. I loading the My Finds GPX into an offline list. After that initial import, none of the caches had cache notes, but they did have just my log as expected. Updating all caches using basic data was enough to pull down cache notes, last found date, add the red heart on favorited caches, add the corrected coord indicator (even though the coords were already corrected), and maybe a few other minor things. My logs were still visible. Updating all caches using full data pulled the most recent logs but still kept mine even if it was significantly older than the new ones being added. So this does seem like a good compromise to keep a record of both your own public logs and your cache notes.

@barefootguru I have a question about your workflow. If your log entry is no longer part of the last x logs that will get pulled down when the cache is updated, what happens to your log that was originally loaded from the Pocket Query GPX? Does it get replaced by the newer logs or does it remain?

I can see some value in this as I also like to include the date when I add information to a cache note. However, I suspect that this could not be implemented in exactly the same way as the date keyword could be inserted into a log or template, as I think that pulls from the date set on the pending log entry. Since there is no long entry for a cache note, there's nowhere to pull the date from. That said, I would definitely support an option to quickly enter the current date in the cache note.

I love the logs tab for exactly this reason, and I also use it with regularity. It's unfortunate that the API doesn't allow retrieving more information here as it's usefulness is a bit hobbled by those limitations. I know GCHQ has been open to small changes lately. @Nic Hubbard, any chance you can ask them about adding this? I figure it can't hurt to ask. Understanding that not everyone feels the same way, I'm wondering if the tabs could be user defined from a pre-defined list larger than the current four? I've seen other apps that allow reordering and pulling options to the front that are otherwise hidden behind More. Don't care about trackables? Hide that option away, but put Bookmarks or Pocket Queries in its place, etc. That would be a nice feature for power users who really like to customize their experience.

Saying "seen with" does seem to imply that the cacher had the trackable in their possession. Using "seen by" would help a bit, but I agree with rragan that "discovered by" is better since it matches the term used for that trackable log type.

I like the stoplight colors. I can't say that I've never looked at two shades of red next to each other and wondered about the difference, but I'm not sure knowing the difference at a glance is really that important. To me, the five dots are mostly a representation of the recent health of a cache. Any shade of red indicates something negative (DNF, disable, archive), while any shade of green indicates something positive (smiley, enable). If I really care to know which is which if there are multiple reds, I'm always going to tap through and read the logs for that, anyway.

I think clustering is a reasonable way to show there are a lot of caches in a relatively small bit of screen real estate without using up a ton of memory. My guess is that most people that are bothered by clustering dislike it because it is implemented too soon, meaning at the wrong zoom level. Team DEMP's comparison is a good example. All of the caches on the Cachly screenshot are still clearly identifiable as distinct caches at that zoom level, and I don't think the number of visible pins is enough to hurt performance. So clustering at that level feels more like an annoyance than a helpful feature. Once the pins start to overlap in a way that they can't easily be individually selected with a tap, that's the point when clustering feels to me like a useful feature. And it certainly would help display many thousands of caches on a map without bringing the app to a screeching halt. I think your plan sounds pretty good. The one thing I'm curious about is allowing the user to disable clustering entirely. What would actually happen if a user tries to show the map with clustering disabled if there ere enough caches on the list to otherwise crash the app. Will you just load the first n caches where n is a number that will still allow the app to function?