paleolith

cezanne, I think you underestimate how often caches such as you describe actually do need archiving. If the CO doesn't get notifications or doesn't have time to disable the cache, then it really is time to archive it. Yes, sometimes a CO will be traveling, but if the CO is traveling in such a manner as not to be able to get email or access the web, then the CO should not be attempting to maintain caches. Either the CO should allow someone to adopt the cache, or it should be archived. Yes, sometimes a CO will be ill. If the CO isn't too ill to get on the web, reviewers will usually (and should) allow a lot of extra time to fix a cache if the CO says the delay is due to illness. If the CO is too ill to post to the web for months, then it's pretty unlikely (sadly) that the CO is coming back, and the cache should be archived. If the cache is worth keeping despite the above points, then someone else will post explanations, which the reviewers usually accept. See GC1ED for an example. It's certainly OK to email a reviewer. But if a reviewer disables a cache, that's usually going to be accompanied by the reviewer putting it on a list to be reviewed in a month or to, and archived if the CO has not responded either by fixing the cache or by posting an explanation. That's generally the same result as from posting a NA. Most often (at least in the places I've cached) the reviewer's response to a NA is going to be to disable the cache with a notification that the CO needs to fix the cache or post an explanation of why it isn't fixed yet. The reviewers normally give a lot of latitude to COs who are clearly paying attention but haven't been able to fix it yet. So I think there are plenty of protections already in place, and a new method to get caches disabled just isn't needed. Edward

Those are certainly good for a few years and keep the contents dry, better than 90% of the cache containers out there, but AFAIK the lids are polyethylene and so will eventually deteriorate in sunlight. I wish someone would make an ammo can out of ABS or polycarbonate or even PVC ... and sell it for the price of surplus ammo cans. Edward

It would probably be more productive to ask for table codes in BBcode. The problem with HTML is that it's basically unsafe -- there are numerous ways to mess up a page and even lead a user into sin and torment. If there were to allow HTML, then they would have to parse it and figure out how to prune it down to just the safe stuff. They had to do this for cache descriptions, and it led to all kinds of agony for those (I was one) who had used something innocuous which was hard to distinguish automatically from something dangerous. By contrast, adding table codes to BBcode would be pretty easy. A basic design principle is that it's much easier to start with something safe and build on to it keeping it safe, than to start with something dangerous and pare it down to make it safe. Edward

It's obvious that some people are happy looking at GC codes. Others are not. I've observed this disparity even among the few geocachers I know personally. General human interface guidelines say that people in general get along better with names than with codes. When I download direct from the web page, I send it to GSAK -- I have the association set so that GSAK automatically gets that file type. Then the last thing that happens is I load the GPSr from GSAK, which as noted above adds a "smart name" which it guarantees to be unique in the chosen database yet is easily recognizable about 95% of the time. It still has trouble with "Marksick's Malleable Mumbling Mickey Sickies ###", but ... well, I have problems with those too. Edward

Sounds like this person you know is confusing "official" with "officious". Edward

two years, 18 months, never. Used a lot in SoCal, so lots of hot weather, seldom wet. Fits my idea that the adhesive is too heat-sensitive. Yeah, this is clearly a real black mark on Garmin. Edward

I'm surprised nothing more definitive has been posted. The following is partly from memory of previous threads and partly from my one experience. My understanding is that the lower GC# has priority, not first to submit. (Which implies that if you expect this sort of thing to arise, you could game the system by setting aside a few GC#s to use later.) However, it's up to the reviewer whether to actually grant that priority. If you don't demonstrate intent to place the cache and progress toward doing so, you'll lose the spot. If you have unpublished pages that you don't plan to use for a while (reserved numbers, experimentation, etc), then it's best to move the coordinates into the ocean or some other place where a cache cannot be placed, so that the reviewers won't have to deal with a conflict. I once located a good spot and set up a page for it. There it languished for a few weeks. One Friday evening I got an email due to the reviewer posting a reviewer note saying a cache had been submitted within 1/10 mile. I immediately emailed the reviewer, posted a reviewer note saying I relinquished the space, and moved the coordinates offshore. But I missed the reviewer's work window and the cache didn't get published for another day. I was sorry about this because it was a friend of mine placing the cache and he had hoped for it to be in place during a (non-geocaching) event on Saturday. And it turned out that where I was hoping to place a cache, about 100 yards away, was across the park boundary and on private land anyway. The actual reviewer's log was Note that procedures may vary among reviewers, and I'm sure that old rule about no precedents applies here. Edward

I disagree on the "wasn't meant to be there". I'm not aware of any places where poison ivy is growing non-natively. It doesn't need to ... it's native to basically the entire eastern 2/3 of North America. And poison oak is native to much of the rest. Poison ivy may grow more thickly in some places due to openings and edge effects resulting from human activity. However, it is native in those locations. Still, I don't oppose attempts to remove poison ivy. I've removed it from places in my yard. It's very resistant to mechanical removal because it can regrow from even a tiny bit of root. I have places where for several years running I've donned latex or nitrile gloves and carefully followed every bit of root. After a few years, it looks like I've conquered it. Almost ten square feet clear! For those with larger infestations, or whose sensitivity prevents using this technique, weed killers containing both glyphosate and triclopyr claim to kill poison ivy. I have some of this product on hand but don't have enough PI to be worth trying it on. Certainly herbicides can cause a lot of damage when misused. OK, back from the dead, now perhaps back to the dead ... Edward

Smiles are achieved by the seeker, not awarded from afar. Edward

#1: use durable, waterproof containers. #2 and #3 are the same. Edward

Interesting, I may do it. I expect a large spread due to nearly complete canopy coverage in my yard. I agree that the nail is not necessary. I would picked a set of coordinates which I'm sure are in my yard, do the experiment on those coords, compute the centroid of my measurements and the average distance from the centroid -- or perhaps the mean squared distance, since the area to be searched increases as the square of the discrepancy. Other variations: Do it four or more times per day to determine how much the configuration of the birds matters. On each measurement, first get to the zero point as fast as possible and mark it. Then average for five minutes and record the reading. How much tighter do the averaged readings cluster? (When the average differs from the quick reading, you'll have to calculate where to place your marker, since you don't want to do a lot of five-minute readings to locate your zero.) The general goal of getting people to realize how far off their readings are likely to be has specific applicability to hiding. People who realize the potential error are more likely to take the five or ten minutes to get a good average. Personally I have not observed discrepancies among brands of GPSr. If complaints about accuracy of coords is frequent on a cache, then either everyone is reporting the same error, or the reception is bad and it jumps all around. I don't recall a cache where accuracy complaints excluded any brand of GPSr. I'd have saved myself some grief (and perhaps money) if I'd done this as soon as I bought my first GPSr. It took me several months to realize that is was sometimes giving me seriously bad readings, up to 100' off. At first I just rebooted it, which often reduced the error a lot. Only when it was long out of warranty did I start realizing that it was just a dud. One cache, I knew the basic location, GPSr told me to go 75' away and jump off a cliff. On another it kept bouncing me back and forth between two or three locations, and I knew they were all wrong (and scattered over 100' or more). Replacing reduced my DNF rate significantly. At first I thought it had "gone" bad, but later realized that I'd been having very bad readings from the start and just did not realize it. (I'm not naming it because I'm sure it was just a flawed sample, not a flawed design.) The amazing thing is that I hid six caches using that GPSr (which did not even have an average function) and no one has had any trouble finding them due to bad coords. Of course it helps that they were all ammo cans and hardly hidden at all -- all were in locations that said "I DARE a muggle to come here". Edward

Currently there is apparently NOTHING in the "trackable items" section of the regular web site that says tracking numbers are secret. It's all over this forum of course, and there's a page in the GS KB that says so, but the only link I found to that KB article was also in this forum. If you go to "Trackable Items", "Travel Bug Home", "Travel Bug FAQ" (!), "How to Log a Travel Bug", or the TB "Post a New Log" page, there's absolutely nothing (that I could find anyway) about not posting the tracking number in logs. Is it any wonder we see this violation so often? We absolutely cannot assume that cachers read the forums! Can something be done about this without waiting for a major education effort? A note in the "how to", a note in the FAQ, a note underneath the "Travel Bug Tracking #" field on the "Post a New Log" page ... I just emailed a cacher who had posted a tracking number. He said "makes sense but I never heard of it". I have to tell him yeah, they sure do make it hard to find! Edward

Two problems. And neither one is the possible similarity to a virtual cache. First, as others have noted, if this many muggles are around then you'll likely have problems anyway. Most of us tend to underestimate the chance that someone not looking for a cache will notice it, no matter how well hidden it is. Second -- some have said that advertising the Alternate Logging Method on the cache page is undesirable. Whether that is true or not, the larger problem is that many cachers won't read that far before going to find it. Yes, if it's going to work, it has to be on the page, a point that some miss -- if cachers are not aware of the ALM before searching, then they may compromise the cache unnecessarily. But it also won't work if the cachers just don't read the full description, and that WILL happen, and will happen a lot. As a result, I don't think the ALM will be very effective in achieving the intent. To my mind -- and this is not verified -- the most effective measure would be to have the cache clearly labeled with ID indicating that it's part of the Forest Preserve. Since you worked with them on the placement, I'd think it very likely you could also get permission for this. That won't always protect it -- young kids for example may pay little attention -- but many accidental finders would be much more likely to replace it with such an ID. Edward

you'd get a better response in the website forum. I tried to ask a moderator to move it but the "report" function seems to be inoperative at the moment. Edward

Yet another case where it makes sense (to me anyway, asking for consensus here is a fool's mission) is when you develop a challenge cache and have no advantage over others in meeting the challenge. I've done two of these, logged both as finds, but in neither case was I even in the running for FTF. One took me a year and a half to complete, the other nearly a year. Edward

Off topic, I don't like that brochure because of the emphasis on "treasure". No matter how much it explains later, putting "treasure" in the headline leads some people to think something of value is being sought, and that leads to various misunderstandings. On topic, the closest I've had to an encounter was returning to my car after a long hike and finding a note saying "if you are in trouble/broken down, call xxx-xxx-xxxx" from the highway patrol. I appreciated that. There was plenty of traffic on the road, but the trail -- although popular -- is unofficial, and so is the parking. Once after a non-geocaching hike I pulled over to the side of the road when I got back to cell phone reception to leave a message, and an LEO pulled up beside and asked if I were OK. IOW, in both cases they were protecting me. Edward

With a user ID# of 3991, Kilroy must have actually joined in 2000. My guess is that in those days, the "date joined" was a user input rather than being taken automatically from the registration date, much as the "cached placed" date is even today. In fact it's obvious that in the Early Days , even the concept of registration was pretty loose -- I think no email address verification, maybe even no email address required. And perhaps someone can say when paid memberships were introduced, which would have required a more formal membership process. (I know of one cache placed by a still-active user in those Early Days which he is not able to modify because he forgot the password and doesn't even remember what email address he was using then. [yeah, he could get a reviewer to fix it, but he somehow managed to PO the local reviewer, I don't understand how that happened because he isn't the kind to PO people and the reviewer isn't easily PO-ed, but whatever.] And I know of one cache -- GC1ED -- whose owner account never logged a find, yet I've read find logs under two other account names where he wrote about the fact that this was his cache. So it doesn't seem that the concept of an enduring account for a person was as strongly embedded in the site then, though of course the latter case may have been just this person's style. [A lot of cachers would like to contact this person, and we even know his full name because he signed it in the cache he placed, but it doesn't seem to match any of the nearby phone book listings under that name.]) OK, end of digression, the other possibility is that Kilroy was an invention of the GS staff, who of course could change any date in the database to anything they wanted ... Edward

I don't want to see your stinkin' DNF notifications, and it's far too much trouble to log them myself. Not only that, but this forum is clogged up with talk about logging DNFs. Furthermore, the acronym is DID Not Find and yet the email notification that goes out says COULD Not Find, so no matter what you say it really is an insult to my ability and character and other kinds of prowess. GS should just get rid of the DNF log type and save all of us a lot of trouble. (There. Too much unanimity in this thread. That'll never do in the GS forums! Needed to restore some balance.) Edward

It seems I disagree with the majority here. I think a business card is great compared with 90% of the crap I've seen in caches. I haven't yet seen a business card that interested me in the business, but partly that's me -- I respond to advertising very weakly compared with most of the population. My tendency is probably magnified by the fact that I don't watch TV. But I have seen business cards in caches which let me know a little bit about cachers whose names I'd seen in online logs. (Obviously in these cases there was something that enabled me to link the card to the gc.com ID, though often that's easier than you might expect -- doesn't always require that the gc.com ID actually be on the card.) And a card takes up a minuscule amount of space compared with a plush toy, a videotape, etc. The only times I've left my card have been when I could not sign the log or for some other reason was going to take the log with me (owner request, etc). In the latter case, the card itself could serve as a temporary micro-log. I've seen peak registers with a lot of business cards when the logs had overflowed. Once on Arc Dome I copied down an interesting-looking email address and had a short correspondence with a biologist who had preceded me up there. Maybe the recommendation should be to leave cards only in a 3x5" plastic bag with a note that others are welcome to add there cards. Sort of an alternative log. Edward

I like the idea too, but I'm pretty sure it is NOT simple. Oh, I'd also like an option to show my DNFs on my public profile. But that gets me to thinking about how it's probably implemented. Thing is, at present, "I DNF-ed this cache" is not even a concept in the system. A DNF is just another log type, not distinguished form a note except by the log type and icon. It doesn't mean anything to gc.com. There's probably a table of finds, keyed by cache code and user ID. And a similar table for ownership. Or possibly that's just one table, the evidence being that gc.com generally doesn't recognize that you may have found a cache and also own it. (Since multiple finds on a cache are counted, and a find on an owned cache is counted, the find counts probably come from a different source.) So the difficult part of toz's algorithm is else if cache has a DNF log by me then because it's not a simple table lookup -- instead it requires possibly examining all the logs for the cache (or all the DNF logs attached to the user's profile). All the other tests in the algorithm involve only either testing a flag in the cache record, or doing a straight table lookup. So adding this would probably require adding a new "DNF" table, or perhaps another status "not found" in the "found table". This table would have to be updated based on DNF logs and modifications and deletions. Likely a lot of code would have to be checked, since it's a new concept. The implementation would probably be trailed by a lot of loose threads that didn't get picked up on the first pass. The cost could escalate. How much do we want to pay for it? I'm certain it would cost thousands of dollars, and quite likely tens of thousands, just for implementation, plus a small increment to ongoing costs for servers and release verification. I still like the idea, but I think it's more likely to happen if it's considered as part of a larger redesign rather than as a feature on its own. Edward

I'd like to remind posters in this thread who have seen the message, that it's been requested that you post what browser you are using and whether you have any add-ons or scripts in use. Also some browsers have built-in pre-fetch options; if you have enabled any such options, this would be a good thing to point out. (I know that Opera has such an option, but it's always struck me as too dangerous to enable.) I don't know if it's been stated clearly, but my strong impression is that the main reason for throttling is to avoid performance degradation. If the site slows down because robots are hitting it too hard, we'll certainly complain and ask GS to do something about it. Which AFAIK is what this is all about. Edward

Really? Are you sure of that? Hnn? You have a reason to doubt it? The "my finds" PQ also gives archived caches, though that's not of general use unless you're willing to log fake finds just to get PQs. ISTR I came up with a third way but I can't remember what it was now ... maybe it was just another way of looking for archived caches rather than a way of getting PQs on them. Edward

Hi, Jim, as has been said, it ain't gonna happen, so save your energy. It's a matter of image: if they tell a land owner or manager that a cache has been pulled, they can pull up a map and say see the cache isn't there, then run a PQ and say see the cache isn't there and there's no option to search for it. As you say, those who really want to see the pages for archived caches can find them. I've even posted strategies for doing do several times here. And note that if you're aware of an archived cache and you want to continue getting PQs on it, just put it on a bookmark list and PQ the bookmark list. Now go back in your cave and answer that email I sent you a few weeks ago. Edward (who just might go back in his cave too)

Move to California, where they have rocks. Real ones. Edward

I've seen the same thing. Sometimes I wonder if perhaps they left a gc.com page open and it keeps reloading, but most people don't use browsers that re-instate sessions after a reboot. It's also far too common to be explained by someone following a TB as suggested. I've never reported it because I've never seen a specific case where I can be sure -- after all, if I'm unable to contact the user, then I won't be able to verify their absence! But statistically, I believe that I see this far too often. When a recent "last visit" is shown but other evidence is that the player is long gone, I don't trust the "last visit" date -- but I can't say for sure that it's wrong. Most of the time it seems to be correct, but I don't trust it. Edward