Jump to content

tallahah2o

+Premium Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by tallahah2o

  1. I like the idea. Since most of us aren't hunting caches out near the N0W0 coordinates, we have to enter all of the coordinates. Those of us who do hunt caches within a few hundred miles of home could benefit from having our default coordinates pre-populated. The ones of us hunting caches far away from our home coordinates may not benefit from the change, but are no worse off either. No harm, No foul. I don't see the bad here. I could see the same functionality benefitting us when we place caches as well as the basic Hide & Seek page. OTOH, It would be a convenience thing and understandably low on the priority list.
  2. Hey... That's a cool pic... wait... that looks familiar.. HEY! That's Mine! WOO! Yay Me !
  3. Wrong. The argument that receiving a list of archived listings will make your off-site data up to date is bogus. You're oversimplifying the issues to suit your own argument. The real deal is that the most accurate data is on the web site, and anything removed from the web site becomes immediately stale data. Relying on this stale data by using archived info is a Bad Idea, and an equally Bad Idea foir us to create features to discourage returning to the site for the most accurate data. Pocket Queries do a good job of offering you the best "stale" data. The better step is accessing data via WAP. I may be a bit confused myself, but I think I am seeing a different side of the coin. I use pocket queries to keep from using stale data. An example: I have a pq set up to run each friday for the nearest 500 caches to me. These are the caches I am most likely to hunt on saturday so I am getting the most updated data. Each item returned by the query gets updated in my records (whatever form they may be). An archived cache will not be updated, but, it also doesn't get removed. It is up to me to come up with a way to find and handle the caches that do not get updated. This is something that I want to do because it's no fun to hunt for caches that no longer exist; and it's something gc.com wants me to do because they don't want me annoying landowners who have asked us to stop hunting. It makes everyone happy. To verify that a cache is archived, I will go to that cache page. Then I will make the change in my records. I am likely to forget this step or skip a cache. I am not sure I understand the difference between returning to the site to read the cache page online and receiving an archive note for a cache in a pocket query. If I understand the quote above, we should consider pocket queries and print-outs stale basically immediately. I actually agree, but until I get internet on my cell phone, my data will never be more recent than when I last read the pages. If I tried to read the nearest 500 pages it would take hours... I'd spend all friday reading them. Then I'd go out and hunt on saturday with that information. Carrying the data with me that I received/printed on Friday night is no more stale than that alternative. The only difference I can see is that I may miss the update for an archived cache if I rely on a pocket query. It seems to me that adding updates for archived caches to fix this would be a good thing. I do understand that allowing access to archived data is in itself a bad thing. Perhaps there is some way to have a middle ground. I would like to throw a kink in the works and offer that an alternative may be to find a way to include just the waypoint id (GCXXXX) and some single field that would flag it as archived.
  4. To reiterate what's been said here, I would have to agree that there should be an active method for distributing current activities on caches that are archived. The current passive means do not seem to be working for many users. given the two options of a email notification or searchable pq's; I would prefer to see the archived caches as an option in pocket queries. An email notification would remind me to clear out the caches from my list, but I would still have to manually delete them/mark them/rip them out of my binder. Pocket queries are power tools by design. It gives us a way to find current information quickly and efficiently about multiple related caches. The current information on an archived cache is that it is archived. Although it is technically correct to say that the absense of data has meaning, it is not usually a good method for distributing information. In the examples above, there is not a clear, simple (automated or programmatical) way to determine if a borderline cache did not show up in a poket query because it got beat out by a new, closer cache, or if it did not show up because it was archived. To be able to run a pocket query that returns recently archived caches, gives me a way I can update my current information by sorting the list and getting a positive response on an archived cache. I can quickly flip to that page in my binder and just trash that one page. I'm done. The alternative seems to be to match each cache to a page and trash what's left. (the same theory applies to binders as the gsak database as the gps) One last thing, and I'm done - Hymr, it would seem to me that it would be better service to your land managers to make sure that when you archive a cache everyone is notified quickly to stop looking for it. If I have already loaded your cache in my GPSr, I may still be looking for it weeks from now if I forget to check the page.
  5. Just a thought - When I download waypoints as .loc files, the standard waypoint type is just waypoint with a dot. When I use gpx files to GSAK, it is listed as a geocache with the correct icon. The "type" listed was worded geocache both times (i think) but the icons were different... it's been a while since I've used the loc files, so I'm not 100% sure, about that. I do VERY distinctly remember when I first started having to manually change all the waypoints to geocaches before I sent them to the GPS to see the chests instead of dots. I can't reproduce your problem with my legend, but your last post makes sense that using a different raw data would give a different result.
  6. I've looked on my legend and cannot find any games. if they are on there, someone knows way more about this gizmo that i do. (I even watched the instruction video i picked up while doing a walmart cache... never mentioned any games) wait, the geko has games? <jealous>
  7. Mostly I've just been breaking some of the other tools out there and trying to better understand how my gpsr and map tools work. Using sql/html/asp/vb/gettoscript - no idea where the sandbox is or how we can use it.
  8. Nothing published, but I'm creating some tools for myself that I am willing to share when stable - please add me to the appropriate lists. Thank you
×
×
  • Create New...