ciarmer

One way to look at this is what do I want to know when considering my next cache target? In my view the distance and direction from my current location is more important than some of the other attributes that are shown in the list view (eg favorite points, trackables). I think it is very valuable. When I'm caching in a particular area and I've updated my list to reflect my location I generally am heading in a particular direction (either toward a destination or heading home). When I look at the list I can easily see how far away they are but one cache might be 1 mile east of me and another might be 1.2 miles west of me. I can't do any planning without doing more work on what caches I'll be near as I head to my destination. To me, the list view showing direction would be invaluable. An alternative might the ability to sort or modify the list based on direction (eg showing all caches toward the N, NW and NE of me) but direction is not currently a sort option). I certainly can't speak for other users but I can say that I am consistently wondering in what direction the caches on this list are. I end up clicking on each of the caches on the map to determine which caches on my list should be my next targets.

I've been using Cachly for quite some time now and it has become a key part of my caching experience. I'm not sure what I would do without it. I converted over from Geosphere and after a while, I never looked back. But I still have this one thing on my wish list. I have been waiting for the cache list to display the direction of each of the caches in the list. As mentioned in the post by rragan, this would help a lot when deciding what caches to tackle next. Is this still on the list for future updates or have I missed a setting in the existing version?

I just tried this and it appears that is what is happening. Seems if you just stay where you are, the list of caches by distance remains stable based on whether you've selected ascending/descending. It also seems stable if you decide to sort by some other attribute and then go back to distance sorting. But, this morning, I happened to be about 10 miles away from where I was initially and the results by distance using the same offline file seemed almost random. You can "fix" it so it goes back to a correct sorting by closing down the app and reopening it and then clicking on the offline file you were initially working with. It then reloads the same file (which seems to take a very long time - different issue) and then you get proper sorting with that offline file. I don't want to complicate this issue by asking about the time it takes to load an offline file - I'll try to frame a reasonable question on that topic for a separate post.

Yes. Very strange...... Because I can't replicate it either. Next time it happens, I'll try to identify the circumstances. Hopefully, I wasn't imagining it...! Seems like Bolling was able to replicate it with the current Beta version?

I've encountered some odd behavior that might be a bug so I thought I'd ask the question here. Best way to report this is to just provide the steps leading to the issue: 1. Download a pocket query and display the query in list mode, sorted by ascending distance. 2. Click on a cache, then click on the field showing the coordinates and distance. 3. Coordinates change from standard DD MM.SSS to decimal degree format (very convenient). 4. go back to list. 5. Click on any cache and look at the coordinates and distance to cache on the cache details page. Coordinates seem correct - distance is shown as 0 ft. for every cache. This doesn't appear to affect distance sorting in the list or navigation to the cache. Only seems to affect the display of distance on the cache details page.

I've posted this as a question assuming the feature does not currently exist. When viewing a "Live" or "Offline" list of caches, a mileage indicator is provided in the list for each cache. Is there a way to include (perhaps as an option), an indication of bearing from your location to the cache location? So, for each cache in the list, it would show, for example, 1.2 mi NE. The same type of bearing indicator would be very helpful on the cache details page as well.

I was out in the field yesterday working with version 2.0.1 The sorting of an offline list by distance seems much improved in this version. However, I still ran across some very odd results occasionally. Once in a while, a class of caches (for example, caches I own) appeared in the sort list incorrectly. Other caches were listed in ascending distance order and then somewhere down the list, a group of caches I own appear (out of order) and they'd be sorted correctly among themselves rather than sorted with the rest of the online caches. Then, after a short period of time, this phenomenon would disappear and they'd be sorted properly with the rest of the group. Seemed strange and hesitate to report it because it seemed sporadic and I can't determine the circumstances under which it happens. It might be that the sorting process gives rise to this and when I look at a list that I think is a final sorted list, I may be looking at a partially sorted list that Cachly is still working on.

Thanks, Team DEMP, for pointing out the new update. That explains why I couldn't find the search functionality!!

I have been playing with Cachly functions for merging offline lists and have some questions/comments. With respect to the Merge List function: 1) A minor point, but I find it a bit confusing when I hit the slider on list A and click on Merge Lists. I'm then presented with a list of the Offline Lists to click. I'm never sure whether I'm merging the list I started with to the list I'm about to click or the other way around. This is important since one of them will end up being merged with the other and one of them will be deleted. One improvement might be not listing the Offline list you started with since clicking it would only merge a list with itself (also see (2) below). 2) Another small issue, but this actually happened to me - I had one list left and noticed a bunch of duplicates. I took a chance and decided to merge that list with itself, thinking that might somehow eliminate all of the duplicates. The result was that the app worked for a little while and then ended up deleting the only offline list, leaving me with no offline list at all. Clearly my mistake but it was a bit of an unintended result. Perhaps some warning that you're about to delete the only offline list you have should be displayed? 3) I had anticipated that Merging two offline lists would result in a single offline list which contains a combination of the caches in the two lists, with no duplicates. Rules would need to be established on the attributes of the single cache that replaces all the duplicates. As it stands, it seems the Copy Caches function does the same thing as the Merge Lists function except the Copy Caches function doesn't delete the resulting empty list, but you still end up with duplicates in the resulting combined list. I think I understand the reason for the different Merge vs. Copy functions (i.e. the preservation of the resulting empty list). In my opinion, the elimination of duplicates, using some logical rules would be very valuable. 4) I also saw a post or two that referred to the ability to update cache data on a subset of caches in an offline list. I haven't been able to figure out how to do that because I can't seem to find the search functionality that would result in a subset of the offline list.

I reviewed forum posts related to searching of offline lists. There was a reference to being able to do a quick search of an offline list in Map view. But I have not been able to find that capability. I am using version 2.0. The ability to search an offline list in List View in the same way that you can search caches in Live view would be a terrific addition (if the capability isn't currently there). If it is possible to search an offline list and I've missed it somehow, please let me know.

Ok, Nic. Thanks. On the positive side, the use of the GSAK note coupled with using GSAK's "Publish" capability works flawlessly. The GSAK "Publish" capability puts the finds in the correct order (also allowing you to change the order or insert other activity between the finds - it actually orders the logs with a number like 200, 210, 220, 230, etc. which provides loads of flexibility). So I can leisurely turn my draft logs into final logs and then upload them (bulk upload) whenever I'm happy with the content and formatting and the find counts and formatting work flawlessly. The ability of Cachly to provide the GSAK file is key to this. For anyone not using GSAK, it becomes a problem. I know that Cachly is not designed to be a replacement for Geosphere (again, I'm one of the refugees). I never had an issue with the Geosphere find count. I have no idea how that program handled it; I can only attest to the fact that it works, offline, online, field notes, live logs, etc. Of course, as time goes on, the fact that the find count works makes no difference if the rest of the app is collapsing around you! I'm just mentioning it because other refugees who don't find the GSAK path or don't use GSAK, may have a problem with it if you decide to remove the find count keyword. I hope you don't mind, but as a refugee, I will probably be asking about things that I've grown accustomed to using Geosphere when I don't find a similar capability within Cachly. I hope you don't take those questions as critical commentary; rather as positive queries meant to potentially improve Cachly. From everything I've seen so far, Cachly is wonderful. The developer of Geosphere seemed to place great emphasis on offline data and GSAK integration - so that's where most of my future questions will probably center. Again, none of it will be or should be interpreted as critical criticism. I hope you understand. Thanks for your patience! I can't wait until my next outing with Cachly. Just need the temperature to go up a bit!!

I tested this and here's what I've found: 1. If I record finds and upload as logs, the Find Count increment works. However, the increment is based on the order in which the cache is uploaded for logging rather than the order in which the cache was found. (In other words, if I log 3 finds and save them in Cachly then upload them individually but make a mistake and upload them backwards, then the counter is incremented with each log and the order is backwards). 2. If I record the finds and upload them as field notes, the first upload has a find count which is one greater than it was prior to the upload but each subsequent field note upload has the same find count as the first upload. So, the answer to your question is the absence of a found count increment seems to be limited to those logs that are uploaded as field notes. But while the find count is incremented for each find if the finds are immediately posted as logs, the order of the finds is the order of the upload rather than the actual find order. Hope that makes sense. Let me know.

I have not tried it for published logs. I can try to do it on published logs tonight but then I'll need to delete those logs as I don't have any unlogged finds right now. As I mentioned, published logs from GSAK which originate from the Cachly GSAK note work fine. But I'm not sure what conclusions one can draw from that.

Yes. I am using 2.0. I did note that if I read my logs into GSAK using a GSAK note and "publish" logs from within GSAK, the find counts for each find are correct. (I believe GSAK interprets the find count variable and assigns a new value in this case). But the direct uploading of field notes from Cachly generates incorrect counts for every field note after the first for the example I described. Let me know if I can help in tracking down the issue.