Jump to content

Team DEMP

Members
  • Content count

    555
  • Joined

  • Last visited

  • Days Won

    53

Posts posted by Team DEMP


  1. I'm not seeing a difference between the 2 satellite zoom levels in a spot I checked in NJ. I selected a cache and zoomed in as far as possible with Apple  flyover selected and then selected Google satellite. The both show the exactly same framed spot in the Cachly screen. 

    Is there Apple detail determined based on location? Am I doing something wrong or misunderstanding your analysis?


  2. Nic gave some specifics but I wanted to throw in some other thoughts. Offline maps and Pocket Queries (PQs) are 2 different features/functions that can be used independently or together. I use offline maps regardless of my access to a cellular network. I like the Open Street Maps which is what the offline maps are and I only switch to online maps if I want to use Google satellite view. Otherwise I use the offline maps. If you care about how much cellular data is being used (I don't), offline maps uses none of your data. It also seems faster to me loading the offline map vs the online, even when I have a full cellular signal. I use the offline maps without a Pocket Query (PQ) and just the live map view on the initial page when you launch Cachly. 

    Folks use PQs for different reasons. You can use a PQ with an offline map or with an online map like Google or Apple maps. 

    So to be total offline, you'd use offline downloaded maps and PQs, but they both work well even when online. 


  3. I'll start high level which may be enough. See if this helps...

    On the main map page that is displayed when you launch Cachly, click on the map icon displayed at the bottom. It's the icon with 3 stacked squares.

    In the map window that opens, the top option is Download Offline Maps. Click Download Offline Maps, then since it looks like you are in Rochester, NY, select North America, then United States and then New York or US Northeast. Do this while you are on Wifi. This one time download will finish and then will show listed under Offline Maps when you click the map icon displayed at the bottom of the main screen. 

    If the above doesn't work or you get stuck, let us know and we'll try to unstick things. 

    Edit: I took a screenshot of my map screen when you click the map icon (stacked squares) at the bottom of the main map displayed at launch. My screen show I've downloaded new Jersey, North Carolina and the US Northeast offline maps. These were downloaded by going thru the steps above and following the "Download Offline Maps" link at the top of my screenshot.  You can see by the check mark that the active map being used by me is the offline US Northeast map that was downloaded. 

    IMG_1344.PNG


  4. What do folks feel about the Add Coordinate to Log option in the Log Cache screen? 

    Yesterday I was at a cache that showed about 35-40ft off both on my iPhone and on my GPS. When I logged the find in Cachly, I selected Add Coordinate to Log and the latitude/longitude defaulted to the coords of the cache page and not the current coordinates. I would have preferred that the coordinates showed the current latitude/longitude at that moment. Since I'm on the log screen, I didn't have quick access to my phone coords so I looked on my GPS and entered those coords. 

    Is it more useful for folks to have current coords, which is relevant if logging at the site, or the original posted coords?


  5. I'm not a Cachly developer but I'm not clear what you are asking.

    Is it that you'd like to be able to customize new options that call URLs passing in values like the geocache id, latitude or longitude similar to how you can do in GSAK? As an example, if $cacheId, $cacheLon & $cacheLat were variables and you could add a new option similar to "View in geocaching.com" which allowed  "http://www.somedomain.com/someurl?x=$cacheLon&y=$cacheLat" as your custom action?


  6. This works fine for me on my iPhone and iPad. It's possible I need to log in the first time on each, as I don't normally use Safari as my browser, but after that, opening up other caches from within Cachly open up as logged in within the browser. 

    Is it possible that your iPad is in "Private" browser mode and each tab is opening a new private window that isn't honoring the existing cookies?


  7. On the main map page that is displayed when you launch Cachly, click on the map icon displayed at the bottom. It's the icon with 3 stacked squares.

    In the map window that opens, the top option is Download Offline Maps. Click Download Offline Maps, then Europe and then Belgium or whatever countries you want to have offline.

    I hope that helps.


  8. That's "correct" in that is how geocaching.com's API works. You'd see the same thing with the official geocaching.com application.   There are long and detailed threads on the geocaching.com API issue on the forums and even here including http://www.cach.ly/support/index.php?/topic/235-datetime-logging-issue/#comment-938 . The next release will allow you to log the cache on your correct date by tricking geocaching.com, but that comes with a disclaimer as you'll see in the thread. The disclaimer is if geocaching.com ever fixes things on their end, your adjusted logs will be likely be adjusted to be incorrect.

    But if you want to do it, it should be available shortly. Again, it's not a Cachly issue but Cachly will adjust it for you if you want.

     

     


  9. I wonder if you need to reconsider/alter your workflow.

    Right now you have an offline view of data in GSAK with corrected coordinates. 
    You don't seem to be updating geocaching.com with that info for some reason.

    You also have 2 downloads you are doing to Cachly - 1 from GSAK and 1 from Geocaching.com

    So I see the following options...
    a ) have 2 different downloads to Cachly and select one to view at any given time
    b ) Update geocaching.com with the coords you are entering in GSAK and just download the PQ from geocaching.com to Cachly
    c ) Update GSAK from geocaching.com where GSAK retains the corrected coords. You load Cachly from GSAK
    d) Possibly, a way to merge within Cachly but not sure if the expected results will be reliably obtained.

    Just my 2 cents.

     


  10. The filtering was just added into 2.0.1 which was just released to the App Store. Update Cachly on your phone and see if the new feature is now available for you. 
    It's not an advanced field search as far as I know but a generic keyword search/filter across the offline caches.

    IMG_1304.jpeg

     

     


  11. When I load an offline list and it loads, at the top of the map screen showing all the caches in the list is a search box. It seems to be a wildcard search that hits cache name and hider name though I'm not sure what else specifically. 

    Does that provide the function you are looking for?


  12. What you noted and were told was my assumption too. There was a thread I'm sure I can find where someone claimed they were told by a GC developer that it required updating/data migration, etc which didn't make sense.

    So if they properly store it as UTC, then they need to add in a view of the data using either browser/device timezone or a new account setting for timezone which just effects the display. The underlying data remains UTC. 

    And should GC "fix" it, the info displayed for Geosphere generated logs and whoever else manipulated the log data will likely be out of whack. 


  13. 2 minutes ago, Nic Hubbard said:

    With those points in mind, I will be keeping our logging date the same. I don't want to manipulate the date so that geocaching.com "looks" correct, but the UTC date in the database is incorrect.

    Thoughts?

    You findings match the analysis in the threads I've reviewed in the Geocaching forums.  I also had a pretty rough discussion in one of the threads where others, not in the know, claim it must be a HUGE issue because GC hasn't done anything to fix it. They claim it requires updating all data, etc. I completely disagree based on way too many years of implementing technology solutions and I expect there are multiple ways to address the situation. 

    Instead of addressing a real issue like this, they focus on changing the icons. Go figure. 

    I would do the same as Nic or if it was a real issue for users, make it an option they could enable with a HUGE disclaimer on the potential problem that would occur if GC ever does it properly. 


  14. 1 minute ago, AnyMules said:

    Thanks again @Nic Hubbard.  Your assistance and quick response on these forums (and emails) is greatly appreciated.  

    I've had a friend who uses c:Geo on Android to put a Write Note on that cache as well, and that's showing "Today" - so it appears that either a) It is Today now, or b): c:Geo is also doing whatever is required to log the correct date too.

    c:Geo doesn't use the API and emulates what you'd do on the web site. Though it's an "app" it uses the geocaching.com functionality. I'd expect c:geo to match whatever occurs direct on the web site.


  15. What I see from the above is that PT being GMT-8 means even though the date/time logged is the "next day", it's only treats it as the next day if the log time is > 0800z. Thats why the 3rd one shows as the previous day even though the date/time is the next day. 

    Whats odd to me is what is logged for Geosphere is what I thought it would do which is advance it by 8 hours to compensate, but if Nic is able to catch the API and see that it isn't doing them, I'm baffled. 


  16. 21 minutes ago, Nic Hubbard said:

    The part that is so far a mystery to me is that I can submit a log (on Sydney time) in both Cachly and Geosphere, and both show an almost identical UTC date being sent using the API. However, when viewing those logs on geocaching.com the dates are not the same. Cachly's is wrong. 

    You are able to capture the API request from Geosphere to GC?  Or are you going under the assumption that they would be the same? I always figured that the way Geosphere or an app would want to compensate for the GC date/time issue was to use adjust the time sent knowing that whatever time is sent will be converted to PT (Pacific Time) for the date. So to log something right now that is UTC/GMT or UTC/GMT+ where they just switched days while PT is still on UTC DAY-1 you'd want to log as tomorrows date if the users timezone is the next day from Pacific Time.


  17. As noted above, there was no expectation the latest version addressed what you are seeing. It's an issue on Geocaching.com and not the app.  As noted above in multiple posts it doesn't make a lot of sense for Cachly to code a work around to a defect on Geocaching.com. I expect that is what your previous program did but it isn't right and could cause other issues. It would also cause a difference between logging in Cachly vs logging in the official app or via the website. At best, Cachly would need to make it an option to address the site defect. 


  18. @AnyMules - I expect you might still see, depending on when you find/log, the web site show a find date of the day before you'd want it to. It's an error (though I'm sure they say it's a feature) on the GC end that Nic can't "fix". He could code for it, but he (and I, not that I have anything to do with Cachly) would consider coding on relying on a defect to not be acceptable. 

    At best, if Nic wanted to try it, he might consider a user option to make the behavior work like Geosphere for those that want it but leave the annoying default behavior that GC implemented for others.  If enabled, the option would need to adjust the date/time of the log based on the difference between local time and GC time. Logging on the web site will also cause a bit of a difference vs the app. 


  19. There have been very long threads on the GC forums about this. Because I'm only 3 hours different from the timezone GC uses, and I don't normally cache at night let alone the wee hours of the next day, it doesn't impact me. Even so, I followed along on the discussions. 

    What I can guess from all the info is that the API expects time passed to it in UTC/GMT but for some reason, the GC processing switches it to PT (Pacific Time) which means if you are logging on a different day, from the PT day, it shows as a different day it was logged. If you were in London which is currently 8 hours ahead of PT, you'd want to advance the time of the log by 8 hours so it showed as London's day vs GC's day or log after 8am London time and it would show the same day.

    If I have the info accurate, I can understand Cachly's reluctance to purposely code against a really poor implementation that GC decided to go with and use that assumption to timestamp logs.

    I have posted in the GC forum threads that it seems head scratching to me why GC refuses to just store logs as GMT, if they aren't already, and show date/time to be user specific based on time zone. I don't see any reason, and they have never responded in public, why they "fix" this behavior. 

×