ShammyLevva

Project-GC, c:geo and others all have option to read corrected coordinates from personal notes. Thus many users have got LOTS of corrected coordinates in a personal note rather than in the corrected coordinates field. Would it be possible when at the point when a cache's full details are retrieved to have an option to update corrected coordinates if coords are detected in the personal note. The regex in the coordinates module could be used to detect the coords in a personal note. NB. It could auto skip the check of personal note if the cache already had corrected coordinates. Thus to the user as they look at a caches details or download an offline list with full details then the corrected coordinates field could be auto updated to reflect the personal note they have stored transparently to the user. It would make Cachly appear to just intelligently find the corrected coordinates and display the icon accordingly.

I’m not assuming they currently exist as a file. Only that when stored on iCloud they would exist as separate files so that a quick timestamp check would identify changes. The logic of the process is very simple if the list doesn’t exist then run the export routine as you describe only without user intervention required. If it does exist then compare date stamps can import export as appropriate if the dates are different. Note the date will be stamped as per iCloud so device independent. Really not a terribly difficult process to add as a large part of the logic already exists. In particular the core function of importing/exporting a list (that already takes care of how it’s stored internally for the single cache instance you mention) already exists so what would be added is the comparison with iCloud and the determining of actions based on the state of the sync.

Given the new proper iPad support in v4, that makes using the iPad to plan caching a pleasure to do, could consideration be given to v4 having an option to sync offline lists to iCloud. It would be great to be able to create a list on one device and have it auto sync to the other. Obviously this would be an option people could choose between say, don’t sync, manual sync, auto sync. Perhaps with a Wi-fi only auto sync for folks worried about data plan usage. So ideally then 4 options. I would envisage the auto sync check routine would only kick in to check for updates when you started the app or when you opened the offline list view. A date stamp check on the list data file on iCloud should be sufficient to confirm an updated file. This would also mean people’s lists would be backed up when they upgraded devices. Which is a commonly suggested thing people are surprised doesn’t happen.

A checker for a puzzle to add to cache pages would only be of use to cache owners. It would need to be accessible by ALL cachers not just those that run Cachly. Thus such a checker would impossible to add to Cachly as it would be rejected by the reviewers. For that reason this isn’t at all possible or desirable within Cachly.

I'm sure of the following. It occurs after saving a log, not submitting one. Once it closes the window and you view the map again what you are wanting to do is to click the next icon in the series. Now here is where the lack of repetition comes in. It is something to do with either the number of icons on screen or the proximity of the icon to the one you opened. Something that is determining what details to show in the pop up. Whatever it is when it occurs clicking anywhere opens the last cache. Note I do not for a minute think as per original poster that it is copying the cache details. I simply think it has cached the last cache details in a variable and the click is opening the previous cache. The fix is to zoom right in so that only the cache you want is visible this seems to be enough to force the variable to be set to the right cache. To fix I'd focus on anything that stores the cache clicked, or any proximity thing to make the selection of a cache easier. Specifically anything that would be affected by a zoom limiting what cache it could be when you click on screen. Hope this helps. Clearly from the user groups comments it's quite a common bug.

Yes I'd mentioned in another thread for adding waypoints out in the field I don't see it should be necessary to even try to upload to the website. When you are frequently in low signal areas as I am it makes adding waypoints a right pain. I'd rather it only uploaded waypoints when it was on wifi.

Did you get an error message at all? It sounds like the same issue as in another thread about the data network connection not being sufficient and it timing out?

My point exactly rragan. Having small clusters of less than 10 is indeed annoying and easily fixed by having a minimum clustering size. The algorithm I have used for my own Family Tree Analyzer program that can cluster based on where your ancestors lived has as one of its parameters as the minimum cluster size.

I do the same usually always work in Offline Maps. Perhaps a tweak to override if you have a 4G signal? Not sure if that's checkable in the iOS API though. There's options in the private APIs but that's not a great idea. Note however I wasn't talking about the send now for logs. I was talking about the intermediate options where intuitively you don't need a data link. ie: adding an additional waypoint - typically during a multi and adding a cache note. Both of these are done frequently in the field and I'd suggest shouldn't normally be trying to update the website. I can see a strong argument that there is no practical benefit to updating the website with waypoints and cache notes (notes NOT logs) whilst out in the field. Perhaps streamlining the process and saying waypoints and cache notes update when on wifi?

I've had this a lot too ususally happens when phone is in anything less than a 3G area. I'd suggest that if the user is in the offline map or using offline map and not on wifi then it defaults to saving offline. Typically if a user knows they are in a poor signal area they will switch to offline maps and/or offline tab. Cachly could take that as a cue to use offline mode for saving waypoints (and cache notes).

Team DEMPs pictures is a great example of why clustering with a low number of points is a very bad thing. With the official app you don't have any notion from that map of where trails lead. One of the key issues I'd see is the current zoom level caches vs the total list. If it is possible to determine the number of caches visible at that zoom before the map is drawn then I think that parameter should be the key. So I'd suggest you consider two parameters : Firstly as suggested is to set a cluster level below which clustering is simply off. Say 500 or maybe push it to 1000 caches, ie: if the current zoom level of the map contains more than X caches to display then clustering becomes a factor otherwise display the caches as is. Possibly user definable from 100-1000? ie: Turn on clustering if more than X caches visible. Secondly I'd suggest a minimum cluster size. As the map shows above clustering small numbers is counter productive. A cluster of say 10 or more could fix that. ie: only group caches together into a cluster if the resulting cluster size would be 10 or more. I have implemented a clustering algorithm in my Family Tree Analyzer program for mapping where ancestors lived and would be happy to share the source if that would help.

Ah ok shame. I'd sort of thought it might just be records in a map database that could be merged. Oh well. I can see that showing two at once is going to be far harder to achieve, without risking breaking something. I had hoped that some form of client side solution might be a way forward. I'm guessing from what you've done before server side the maps are generated according to parameters you specify so tweaks will affect everyone thus isn't an option either.

Following discussion on the Facebook Cachly User Group from a user that lives on the border of Germany and wanted to know if there was a way of selecting two or more offline lists. I was thinking about this. I can see that technically the selector selects just a single map and it would require a fair bit of re-writing to change that. Reading another article on lists it hit me that a possible solution may be as follows: Since the users download the offline maps to their device, might it be possible to have the option (similar to merge lists) to merge maps locally. For this to work the user would need to have downloaded the maps to merge to their local device. A merge option could then allow them to select two maps and combine the data into one newer offline map. This sort of user driven solution that was entirely local to their device would allow anyone on a state/country border to choose the maps either side of that border and to merge them locally according to their own needs. If they needed more than 2 maps merged they could do it in stages merge two then merge a third into the merged map. This keeps the interface simple.

I think this is separate from the locking the map in rotation mode Nic. I'd mentioned a while back that one of the features I liked about the Classic app that Cachly doesn't have is the "auto zoom". So that as you move the map zooms so as always to keep the current position and the target on screen. This is particularly useful when you have phone in a holder on dashboard of car and you are driving to a cache location to park up. At present when you get closer the map doesn't change at all other than the option to rotate. This means that it is at one zoom scale - when driving often this is a few miles out but when you are in the last few hundred yards to parking its REALLY handy for it to show it at a far more detailed scale as at the scale you started out at the dots are basically overlapping, so what you want is to zoom in. Doing this manually means taking your hands off the wheel to fiddle with phone which is inadvisable. On the classic app it would zoom as you moved so that as you got closer it was very easy to see and so safer whilst driving. Of course it is useful when on a lengthy walk too as you focus in on the area you want to search.

Unfortunately not. I've spent a while trying but as ever when you try to get an elusive bug to appear it never obliges. I will of course log it as soon as I can narrow down causes.