ecanderson

Based upon terminology in this thread, I would say that would be 'bad evil', on the order of a nano in a giant rockpile. Nothing original about it -- just a pain in the arse to find.

I left him a voicemail on Friday afternoon. Was a bit surprised he didn't pick up. He may be traveling.

I left him a voicemail late Friday afternoon. It's unusual that he didn't pick up, so my best guess is that he is traveling.

Ever since I started geocaching about a year and a half ago, I've been a regular customer at the Coleman Outlet Store up in Loveland, CO. They've got stores in 10 different states in about 90 locations. They know why I'm buying all of this stuff, so they are even kind enough to provide a discount. Ponchos for a buck. Coleman lantern LED key fobs for two bucks. Their "survival kit" for two bucks. Little beener/compass thingys for a buck. A package of chemical handwarmers for a buck. They've got all kinds of goodies there. "Regular" size caches almost always get something from my Coleman bag-o-swag unless my supply has been depleted. Yeah, it adds up, but it's cheap entertainment all the same. I've only taken two swag items in all that time (if you don't count the Mondo whistles we've been collecting for another purpose altogether) - simply because there were only two items that really called my name when I opened the cache. One was a really cool little 3/4" compass rose. The other was a bungee cord that was a perfect fit for the situation in the back of the cachemobile.

This is automatic ONLY if you happen to hit one of the "key" caches that causes your information to be queried and added to the list. The statistical model they've used to determine which caches are used for the sample is pretty cool, and it works the vast majority of the time. However, it is possible to have >200 caches and have missed every one of the caches that would trigger your entry in the list. If that happens, you can always ask to have your stat added directly by contacting the owner of the site -- which I intend to do right now since I don't think he realizes he's getting alarms on it at present...

Contrary to the above, I'd go one step further and recommend the Summit HCx to you. I know a lot of folks with units like the 60Cx that have never even tried to use the real magnetic compass even though they've got one, but once they watch you use your own in tough environments, they start using them right quick. Backing away from a target by 40' and doing a little eyeball triagulation can get you hides under dense trees, near bridges, and here in Colorado, close to canyon walls. It's the least expensive option of the series that gives you the additional tool.

Those, I hate. There are times when I've written precisely that, and have done so by way of apology for the really crappy formatting and upper/lower case and brevity and ... phones aren't always the best logging tools. If I happen to hit a FTF (doesn't happen all that often, but it happens), I'll pull out my cell phone to make an initial, brief found log so that all of the regular FTF hounds in my area aren't jumping into their cars and interrupting their lives in an attempt to make the FTF. When I get home, I'll usually edit the log and clean it up so that it's presentable.

Guess I'm not clear about what you are trying to do. All geocaching.com coordinates are in DD MM.MMM format, using the WGS84 datum which, unlike some of the older methods that varied by country, is used worldwide. Your GPSr should be set up to deal in both that format and datum. If you're getting hung up because of a puzzle cache that is using a peculiar datum, let us know WHICH one and perhaps we can help. If your only problem is that you're dealing with DD.DDDDD format vs DD MM.MMM format, that's easy. ".DDDDD" = "MM.MMM" / 60 "MM.MMM" = ".DDDDD" x 60

For some folks, it's a social event. I know a couple of older couples that always cache together as a "safety in numbers" sort of thing. Some of our caches can be a little strenuous, and it's nice to have someone along for one of those "just in case" moments. Lost one our charter members out here one year, and while it wasn't possible for his caching buddy to be of any help, it was good that he was there. billzjeep was on the trail geocaching with jeepers1&2 and suffered a massive heart attack. We have an annual CITO event in his honor. I've probably done 80% of my caches solo, but have a buddy at work that also caches regularly, and we like to go out during lunch and grab a couple when we can. We also plan weekend bike runs when there's a long string of them somewhere. With two of us, we can drop a pickup vehicle at the other end! And then there's the "buddy system" - I don't think I'd consider some of the mountain caches out here in Colorado without two people. You get dinged up there, and there ain't no cell phone coverage to call someone to drag your sorry cache out of the woods

I tend to run about 5% DNFs, if current stats are any indication. Of that 5% (I've only been at this for about 16 months), I'd say that a good 75% of them have turned out to be missing. Had a rough patch this spring where I'd solved a bunch of puzzles over the winter, and found half of them MIA when I arrived at GZ, confirmed by the owners. My personal % is made up of several factors. If I arrive on scene during a lunch cache run, I try not to search for caches with 2.5 or higher difficulties. I know I can't devote the necessary time to those at lunch, and save them for the weekends. That helps a lot to keep the DNF rate down. If I DO get silly and tackle a 3.0 during lunch, but can only spend 10 minutes looking (typically not nearly enough for a 3.0), I'll take a couple of lunch passes at it before recording the DNF if I have no luck. No sense raising red flags when the lack of looking on my part is the problem. Another reason for the relatively low DNF rate is that we've got quite a few easy ones around my area.

The geocaching.com site points to the following rating suggestions http://www.clayjar.com/gcrs/ When you create the entries for your caches, on the "Report/Edit a Cache Listing" page, right next to where you select the difficulty and terrain ratings, you'll find that link.

Wouldn't be the first time it has happened to me. Spend the winter solving puzzles (hardcopy) and the spring finding them. Unfortunately, found too many muggled that way, too. Serves me right for not looking back on gc.com before heading out, but of all the ones that bite me, it's puzzles previously solved where it takes me some time to get out to the final.

Let's set aside the issue of bookmarks for a moment and point out how many shades of gray there are in this. If I create an "A to Z" challenge cache where you have to come up with a collection of 26 traditionals whose Groundspeak names start with the letters A to Z, and unless I put out 26 or more such caches myself, it is inevitable that to meet the challenge, other caches will be used. So what? Took me a while to get the Q and Z logged, but it was fun.

I did go back and try to log in again, and you are correct. This "viewstate" business is evidently only going to appear the first time through. Which leaves me to repeat an OLD question ... WHY, unlike other sites, does wap.geocaching.com not manage cookies such that one can avoid logging in every time on a cell phone? Sites like yahoo.com and others seem to be able to manage this. Having to type in a login name and password to retrieve log data after 30 minutes of inactivity is a real nuisance. I believe that if it were not for that requirement, I'd not be seeing the viewstate error to begin with since it's the transfer from the login server to the database that seems to cause this error.

I recently picked up a new phone, and it behaves very badly on the WAP site. After providing my login data, and having to tell the phone that it is OK to be redirected to another site, I get the following message along with a great deal of source code text to which the browser evidently took exception. Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. The problem relates to an "invalid viewstate". At this point, I am now unable to retrieve information in the field! Has anyone else encountered this? The browser claims to be something called Obigo

All good again with IE7 and Firefox. FYI, it's been a week or three, but I had a day where the "balloons" didn't work when clicking on a cache icon on a map page. Did have zoom features and alt map (satellite, top, etc.) features at that time, though.

Wish that were true. I'm having the same problem with Firefox and IE7. Not being able to bring up sat maps for trail reviews is a real PITA. For "street" caching, I could live with this, but...

There are some caches (rockpiles come to mind) where many of us would as soon ignore the lack of a smiley than endure the brain damage of a find. A hint that reduces the self abuse to an hour or so seems fair enough, and we use them without hesitation.

Broomfield, Colorado has a goodly few per square mile, and on a per capita basis (our population density isn't nearly as high as many of the cities above), one of the higher densities around: 5 mi = 280 10mi = 801 25mi = 2792 50mi = 4248

I still want the stupid cookies to work properly so I don't have to keep logging in every 30 minutes or so! No other WAP service that I use that employs cookies has this problem!

Of interest, many of the major roads out here are suspiciously close to specific latitude and longitude positions! They just missed laying I-25 on W105 -- here it's at W104.98, and I break my grid at W105, leaving the "interstate" caches to the other side. So like you, I chose my "grids" along major roads of convenient spacing.

Only once, typically, since I don't include the logs. Just want the basics on paper so I can make notes as I go. I'll often take a look at the listings of immediate interest "live" before I go out to be sure things are still "active" and that there haven't been a recent string of DNFs. As an example, I maintain one area bounded by N40°6' ~ N40°10' and W105°5' and W105°10'.

While true in part, the 500 limit is only part of the issue. Unlike some, I'm still keeping paper logs, reducing cache listings to single page print each (Firefox is GREAT at reducing graphics for keeping things on a single side of a page when pressed). I like to keep my copies in a set of binders, each covering a particular grid area (NOT a radius!). As things happen here, a 4 mile radius will more than fill 500. To keep things easier to find when in the field, I break the metro area down into a grid system in my binders, but can't get Groundspeak to do the same. Would love to have my binder for the city broken into a 3x3 grid of about 100 entries each by Groundspeak. Both my rather limited-memory Garmin eTrex and my notebook could live in harmony that way, pulling in just the chunks that might be of interest on a given day or two. Tools like GSAK can be used to produce square or rectangular area filters if you get past the basic menus and try out the somewhat clunky "polygon" feature, but I'd need an overlapping set of about 6 x 500point radius lists to make it all fully work here. Why would Groundspeak want to waste the bandwidth sending me all of the duplicates that a set of 6 overlapping lists would create??? I'd love to tell Groundspeak's database to give me the town in 9 square chunks of about 100 each so when I'm out in the real world, I can focus on just one of the 9 grid sections with ease.

I've been working with the Groundspeak search system for a couple of months now, and have concluded that the "radius search", while useful, may not always be the best approach for either Groundspeak or its users. Especially in the case where Pocket Queries are being developed, radius searches - especially in high cache density areas - are often not helpful in achieving the desired result. In order to cover a metro area without gaps, radius searches must inevitably be created that cause a great deal of overlap, adding to the CPU and bandwidth from the Groundspeak servers, and requiring a lot of duplicate elimination by some 3rd party software on the user's end. Moreover, one can imagine that the Groundspeak's system of computation of the legitimate hits within radius searches cannot be done without a bit of math thrown in to compute the allowable coordinates at the circumference of the circle (anyone remember X squared + Y squared?) How about a GRID system in addition to a radius search? The user would need only supply two corners of the desired grid area. This would allow non-overlapping database sets to be delivered to the user, and would vastly simplify the computation required for determination of which caches fall into the search coordinates. Users could then create "grids" of non-overlapping cache data as well, avoiding duplication and allowing the loading of unique data sets for hunts.

AMEN to that! But I believe my phone DOES accept cookies and using my WAP enabled phone, I do not find it necessary to log into any site on a regular basis (United Airlines, Google, Yahoo, and a whole host of others). All of them remember me well. The ONLY site I use that insists on a new login about once every hour if idle is Groundspeak's WAP site. So my #1 request would be to properly utilize cookies where possible. This frequent login business on an otherwise very useful "in field" site is for the birds! My #2 request to make the site more useful in the field would be to make the use of decimal degrees optional when entering a coordinate cache search. Even Google Earth knows what "N40 11.356 W105 3.886" means. Permitting a version of degrees/decimal minutes would beat the heck out of always having to approximate a conversion to decimal degrees without a calculator. Yes, I can get it in the ballpark, but in cache rich areas, a small miss brings up pages of ones I don't want first. Yes, I know that Groundspeak's internal database is in decimal degrees, but that's not how logs are posted, and is not the coordinate system most of us use on a daily basis. Why here, then? ------------ Edit: It appears in reading just a few posts further that at least a version of the above is in place, but there was no way of knowing the format from any online docs I've seen for the WAP interface. I'd still love to avoid the "-" and use a "W" (for reasons peculiar to my phone, and probably others), but if I can get the above mentioned methods to work, I'll be far happier... Edit 2: It doesn't work for me without extra care. I have carefully submitted (without the quotes) "40 11.777" "-105 3.867" and the first cache at the top of the search list is GCGTCH at N40 15.301 W105 36.904. This isn't helpful, folks. Any leading zeros on the decimal minutes MUST be included. It requires "-105 03.867" (note the leading zero) in order to bring up proper information. That's another thing to add to the WAP user interface page, wherever it is! If someone can point me to a UI doc somewhere, that would be really helpful. If there isn't one, the WAP site is too useful to not be well worth explaining fully and "cleaning up" just a little bit. ------------ Last, and #3 in the list -- and while peculiar, only a nit -- the menuing system itself is a bit counterintuitive. In particular, it would be nice to avoid the intermediate two entry screens to "OK" a request, and the flow in general isn't what one would expect.