LazyK

I see that it explains that the KML waypoints aren't accurate but it doesn't explain why. Is this inaccuracy because the KML is available to everyone and it would be like getting 'free' pocket queries if the KML coordinates were accurate? LazyK - Dan

Like any 'normal' geocacher, when I use GoogleEarth, I have the 'Geocaching Network KML' enabled. I'm noticing a small inaccuracy in where the waypoints are being calculated and therefore plotted. For example, I was looking at the cache GCT6QK (A.J.A.C.S. 2nd Annual Campout Event Cache): Listed Coordinates: N 32° 52.653 W 111° 12.026 Converted to DD: 32.87755, -111.2004333 I opened GoogleEarth and manually plotted a waypoint using those coordinates. It took me right where I thought it should be. But, when the KML finished loading, I noticed that the waypoint for the cache was a bit off from my created waypoint. Finding that curious, I saved the KML created waypoint. Geocaching Network KML: 32.8777, -111.2002 This inaccuracy is large enough so that downloading the waypoints from directly from GE to my GPS causes major problems when searching for caches. In this case, the two waypoints are ~90 feet apart. Now...for an event like this one, it's not a problem but for a micro, that's insane. Am I missing something? GE and GC both allegedly use WGS84 as the datum, so that shouldn't be the problem. Is the KML providing inaccurate/invalid coordinate values? Thanks, LazyK - Dan

Is there a way to transfer filters from one machine to another? Maybe an export/import filter? Or is there a file that needs to be moved? Thanks, LazyK - Dan

I would like to export to 'Street Atlas' format and set the 'Cache description format' to something like this: %Name (%Code) -- %Long Where %Long is is the long description. This would give me a page of entries like: 42.5228,-87.9497,? (GCJ5YR) -- <long description would go here>,2,1,1 This would allow me to generate one .txt file and print out the cache pages in plain text without all the extra (unnecessary) information. By doing that, I can save a lot of time since I wouldn't have to print each cache page individually or with all the pretty formatting, saving paper as well. Thanks, LazyK - Dan

Hello all, Is there a 'special tag' that corresponds to the true cache description? I see %des but I also see that that is really only %name in disguise. I'm looking for a way to get the Groundspeak:long_description field. Thoughts? Thanks, LazyK - Dan

While I'm a bit far away to adopt it, we did replace the container, add trinkets and put the log into a ziploc when we were there last week. It should be good to go for a while. LazyK - Dan

WTH is an 'Earthcache'? LazyK - Dan

Which would be soooo much better than most caches these days... JMHO. LazyK - Dan

You're saying it's ok to take something from a cache and leave nothing in return? Exactly my point and that's why TBs NEED to be traded for. Otherwise, "the cache will degenerate and entropy will be achieved"*. When it comes to taking something out of a cache, it doesn't matter if it has a little tag attached or not. If you take something out, you should put something back in. Taking an item and also leaving an item AND a TB would be ideal. But we all know how often that happens. As far as inbound TBs, you're right. They shouldn't be traded for. Outbound TBs, though, most definitely need to be traded for. LazyK - Dan (*Quote courtesy Team Tierra Buena)

Samsung v205 returns only the error message "Not Acceptable". LazyK - Dan

Travel bugs should be traded for like normal trade items. It's when TBs are taken with nothing is left in their place that a cache degenerates. Is it wrong if I leave a TB and take a pocket dictionary or a 'Hot Wheel'? The pocket dictionary may be kept while the 'Hot Wheel' may be traded again (like a TB). LazyK - Dan

According to http://www.w3schools.com/wap/wml_validate.asp, the page isn't valid wml. That may explain why it doesn't work in some browsers. LazyK - Dan

On the main page, there is a link to 'Recent Logs' which lists the last 200 logs entered on the site. Is there any way to filter that list so that it only shows the logs made for a particular state/country other than visiting/scraping the page every two minutes? Since I live in Phoenix, I'm really only interested in AZ caches. Granted, I do travel but I'd say 90%+ of my finds and 99%+ of my geocaching expeditions have been in Arizona. Because of that, I like to keep up with geocaching in Arizona more than geocaching in Michigan/Albania/etc. (not that there's anything wrong with Michigan/Albania/etc.). Would anyone else like to see a feature that shows recent logs per state/country? A simple drop-down box on the 'Recent Logs' page where we could select the state/country/etc. (like we can for cache searches) would be enough. I suppose the other option is adding every single cache in AZ to my watchlist... Thoughts? LazyK - Dan

Please count me in... LazyK - Dan

Bump... Excellent feature request, even if it was only for Premium Members. LazyK - Dan

How about an option for the Pocket Queries that allows the user to select caches that contain jeep travelbugs. Currently, pocket queries can return caches that contain travelbugs but how about being more selective. These appear to be stored differently in the database (because they get different icons) so how about letting a PQ grab just them? This would work for GeoCoins also. LazyK - Dan

I second the 'DNF' and 'Note' list request. LazyK - Dan

Unable to access using a Samsung v205 on t-Mobile network. All I get is an error message indicating "Not Acceptable". Found this description of the error message: Precompiled WML cannot be loaded; usage yields a "Not Acceptable" message and the page cannot be rendered. Is the WAP search page 'precompiled WML'? Dan

I'd love to see a checkbox added to the search page that allows the search results to include the archived caches as well. Anyone else think this would be a great addition?

Has anyone else noticed that the 'new' state search result page is out of date quite often? For Arizona, there were 4 or five caches that were approved on 11/3 and are still not listed on the new search result page. If you go to 'Hide and Seek a cache' page and select Arizona from the pulldown, you'll see them. Just how long is the delay in updating the new search results? Does that query select from a different database than the old one?

quote:Originally posted by treemoss2:I like your solution to hide them better. Better yet - don't hide anything at all, but post it. How many of those you think it may take before they get tired of it. The other thing you can do is to make them multi caches with the first coordinates somewhere outside the park. That way unless they track down every single cache in town, they'll never know if any have been placed in the parks.

Just posted a find on a marker that already had a find logged and noticed that the logs blend in with one another. There's no white space between them to visually mark them as different from one another as there is with the 'regular' cache log pages. It's all just one large grey block. AI1926

How about 1933? DU0943

Maybe the marker is imbedded in the pole (several feet off of the ground) and is one meter below the light.