paleolith
-
Posts
964 -
Joined
-
Last visited
Posts posted by paleolith
-
-
I've read a lot of posts complaining about a perceived intent to restrict cache placement by new guidelines on safety. I think this concern is misplaced for at least two reasons.
First, the best suggestion made has been to facilitate user-to-user communication via a safety forum. This would be explicitly for the purpose of educating and helping one another on safety issues, not (at least as I perceive it) to advocate for rules.
Second, I find it highly unlikely that GS would implement any safety rules. Ironically, such rules could expose them to more liability. As it stands, GS says that the CO owns the cache and is fully responsible for it. If GS added safety rules, they could be liable for any lapse in the application of those rules.
I'vw read a lot of posts about how an alert cacher (often the writer) would have foreseen the danger in this cache. Yet all of these constitute 20/20 hindsight. In fact the CO and thirty-some seekers didn't foresee the danger. These included cachers with a lot of experience.
Why the discrepancy? Is it totally being misled by hindsight? That's a strong phenomenon, but it's also true that some people have a much better ability to predict what's up ahead, some naturally, some by training, some both.
How do those with that ability share it with others? How do we persuade others to listen, and then what techniques do we use to share those abilities?
How do we turn hindsight into foresight? The experience of safety experts says that's a very difficult task.
Those complex sorts of questions are why I continue to think Snoogans' proposal is worth a shot. It's a proposal for an open and cooperative system, based on education and sharing rather than on rules and guidelines. Discussion can involve talk about trade-offs: what risks do we take to enjoy life, and why? I've taken many risks, the most serious involving being alone in isolated places. What were the risks? What were the benefits? Benefits can include having fun, better health, less stress, and probably others that I haven't thought of. Discussion safety involves discussing risks, benefits, probabilities, trade-offs, balancing of risks.
Safety begins at home. Safety begins with the individual understanding the nature of risks and benefits. Rules don't convey that understanding. Communication is the only way to get there. Communication, personal knowledge, and understanding do help decrease danger while increasing benefits at the same time.
Edward
-
So sad.
I do like Snoogans' idea of a place to discuss safety. Would it attain critical mass -- enough to keep discussions snowballing instead of dying out? I don't know, but it seems worth a try. (And Snoogans has made some of the most cogent and informed posts in this thread.)
I'm far more leery of t3.5 urban caches than of t3.5 backwoods caches, because the t3.5 tends to mean something different. I've found many t3.5+ caches, and only a couple had any exposure at all. One of them I probably shouldn't have done, at least not by the direct route. Even that one probably wouldn't have killed me if I'd fallen, unless I'd hit my head on a rock, of which there were plenty.
Backwoods t3.5+ caches are usually rated thus because reaching them requires a strenuous hike. (Or in the case of 4x4 caches, a difficult drive.) Urban t3.5+ caches either require a short but difficult move, or include exposure. This one at first appeared to be in the last category, though the images posted later indicate that there wasn't really much exposure except for the missing piece of grille which one was supposed to stop short of, and that quite possibly it was overrated at t3.5 -- and yet the exposure was significant because of the missing grille.
I could suggest a separate attribure or rating for exposure. But for the reasons other have presented, I don't think it would add much. I think a cache with significant exposure should make that very clear in the description, and I have to say that I don't think the description of this cache made that clear. But would that have made any difference? Would it have made this death any less likely? I don't know. Can't say. Still, I do think the CO should have described the exposure, since the terrain rating alone isn't that specific, but I'm not willing to say the lack of that description contributed to the tragic death.
It would be great if coordinates were only revealed to those who understand any dangers involved. I don't see any way to do that, nor do I think it would have much effect. And where would you draw the line? Would risk of contracting poison ivy/oak count? Only risk of death? If so, would risk of death from heart attack on a strenuous hike count?
Recently someone posted about being attacked by yellowjackets while seeking one of my caches. I added a boldface note at the top of the description. I suppose I could have disabled it for a while, but yellowjackets are fickle and may never attack again.
Some twelve years ago, I took several hikes in the Arc Dome Wilderness. After that trip, I wrote
Soon I reach the edge of the plateau and I'm met by one of those snow banks. For someone with basic snow travel skills, this would be no big deal. But I take a couple of steps and realize that not only do I not know how far I can trust the snow, but also the bank becomes steeper and from the top I can't tell what the worst will be. I look for a way around. To the north it seems to go on interminably. I walk south, but soon I'm blocked by the vertical dropoff into a large cirque. There's one spot where a few steps on the snow would take me to solid ground below, but it's right at the edge of the cirque. I slip, I die. It's tempting but not that tempting. I move a few feet north to where a slip would only hurt, not kill, and pick my way.Suppose I'd made the wrong choice, and suppose I'd slipped. And suppose I'd been geocaching ... in fact, the spot I describe is only a few meters from the Arc Dome cache. Would that have been called a death while geocaching? I need to go back and find that cache ...
new log type is a few programmer hours for GroundspeakThis seriously understates the effort required. A few hours of analysis and more than a few hours locating everything that's affected, which includes page layouts as well as database code. A few hours of coding. At least a few dozen hours of testing. Notifying the developers of all geocaching applications, most of which have to be modified -- with additional time from all those developers. (Some time ago GS tried to change "Found it" to "Found It" and had to back off because it broke so many things.) Then manage that coordination and track progress until it's deemed OK to implement the change. Write documentation and monitor comments on the forum. Monitor results after implementation. All in all you are talking a few hundred hours. I express no opinion on whether it should be done or is worth the cost, but this comment very seriously underestimates the cost.
Edward
-
It's totally up to you. Two people finding a cache together and logging it separately does not look "fake" in any way. Happens constantly, both with couples and friends. It sounds like the two of you enjoy writing your own logs, as do many couples, so go with the two accounts (as I see you've decided to do).
The cases where it's appropriate to use a single account is when two people (whether a couple or not) always cache together -- neither ever finds a cache without the other -- and at least one doesn't enjoy the logging part and would rather leave it to the other. There are couples who find a few caches separately and log them all in the joint account, which is also totally OK.
You already said it's not about the cost, but those who worry about the cost but still want two accounts can have one premium and one regular account. The premium account does the PQs and other things requiring PM status. They find caches together and log them separately. There's a GS-approved workaround for non-premium members to log PMO caches.
Edward
-
GSAK offers a number of printing options. Before I got a PDA, I used the "condensed HTML" output from GSAK. No photos, but a lot less paper than just carrying the cache page printouts. I haven't printed anything in quite a while, so I'm not sure what GSAK offers in the way of printouts with photos.
Edward
-
Also note that there are many kinds of puzzle caches. Clearly what you are looking for is something you can work out at your desk. Many of these are just the traditional kinds of puzzles you'll find in puzzle books or cryptography games. Others involve information hidden on the web page or in images. Still others require you to work them out in the field.
Why does "he" want you to provide him with the coordinates after you solve the puzzle? (Is he by any chance having trouble solving this puzzle himself?
)If geocaching is what you're interested in, the usual way to start is by finding some traditional caches rather than puzzle caches. To log a find on a puzzle cache, you still have to find the physical cache and sign the log after solving the puzzle.
Edward
-
I do see a distinct difference between one find and zero finds.
I'm been preaching this for some time: yes, there should be a minimum number of finds to hide, but the minimum number should be one. Someone who has found even one cache is a lot more likely to have figured out what a geocache is. (And per examples given in this thread, there should be a way to appeal to the reviewer for a zero-find hide, in cases such as experienced cachers hiding under/behind a group account. If someone knows the process well enough to appeal to the reviewer, let them hide.)
One find, to me, would indicate a newbie. Zero finds makes me suspect some alterior motiveI don't know that it needs to be ascribed to ulterior motives. It's just that someone who hasn't found a cache sometimes doesn't understand what a cache is. They have an idea for hiding something and they bend their understand of a geocache to their preconceived notion instead of the other way around. I've seen a three-part cache listed as a multi by a no-find hider. (On NPS land, but a one-find rule would not stop that.) Coordinates in the middle of a beach or in thick chaparral -- a one-find rule would not eliminate that but would cut way down on the ones I've seen. Hiders who never check back with gc.com and apparently gave spurious or one-time-use email addresses -- far more common with zero-find hiders than with single-digit-find hiders.
It's not perfect but it would cut down on a certain type of problem. I agree that there's no good reason to believe that a minimum larger than one would help on the average.
Edward
-
One reason this is a conflict is because gc.com has no way to distinguish hider from current owner, much less to keep links to all historical owners. (I know of one cache which is on its fourth owner, although in that case all adopters found it before adopting it.) So you hide a cache, it's a good one and a lot of people like it, you move and have someone else adopt it. It no longer shows up in your profile -- if you let it be archived then it's still in your profile, but if you try to keep it going by adopting it out then you lose all links to it!
So one way logging a find is a way to keep a link from your record to a cache which you hid.
Edward
-
Nalgene bottles are polycarbonate (PC), which will hold up in sunlight. Some others, like the Fuel Belt pictured in one of the posts, are low density polyethylene (LDPE) and will deteriorate in sunlight. The caps on Nalgene bottles are PE but seem to be very high density PE and appear to hold up.
Only use bottles with a screw top AND a flexible gasket. (OK, a wire bail and a gasket, like ammo cans have, is OK too but I've never seen a water bottle with that feature. Good old Triomphe jar! Too bad no one makes Triomphe-style jars in PC ... they would be great containers.) Without pressure on the gasket, changing air pressure and temperature forces air in and out, and enough moisture gets in that the cache ends up wet inside.
I think that all metal water bottles are rust-proof -- either stainless steel or aluminum.
Edward
-
Even most PMs are still capable of learning.
Changing the page layout based on something like PM status is confusing. In IT jargon, it's modal. So you'd get things like you try to help someone else and describe something on the screen, like the third tab from the left, and it's not the same on your screen as on theirs. Or someone new decides immediately to sign up for PM status (after all, $30 is just dinner for a lot of people), and the Learn tab disappears just when they need it most. Or you start to get annoyed that the learn tab has reappeared and it takes you a while to figure out that's because you aren't logged in -- the problem there being only the annoyance.
So I don't think it should be dropped based on PM status. Perhaps there's a better way to organize the tabs, but making it modal isn't a good idea.
Edward
-
After a recent release, I posted the custom style sheet I use to condense the logs. In the latest release, GS decided to double-space everything -- well, 1-1/2 space, but lots of wasted space. I've updated my style sheet.
This version overrides the extra spacing. It also makes text default to black instead of gray. See comments in the code for details.
With Opera, you can specify the style sheet as a site preference. In Chrome, you save it in a specific location; it applies to all sites. For the most part the names used by GS mean it will cause no conflicts on other sites. However, the code to make text default to black instead of gray will affect all sites. But if you don't like gray text on gc.com, you probably don't like it anywhere.
You can probably do this in FF and IE but I can't tell you how.
Edward
# CSS for geocaching.com /* Make avatars on logs just totally vanish. I don't know whether this prevents the download. */ .logOwnerAvatar {display:none !important} /* Tighten up the spacing in the log. Readability is not reduced at all, due to the alternating background colors and the bold log type. */ .LogDisplayRight .LogText {min-height: 0 !important; padding-top: 0 !important; margin-bottom: 0 !important} /* Try to stop the View Log from taking up a whole line all for itself. This occasionally (perhaps 1 log in 10) causes the View Log to overlap a bit of the log text. If this bothers you, remove this line. The only cost of removing it is a bit of extra space at the bottom of most logs. */ .LogText + .AlignRight {margin-top: -20px !important} /* I also don't care whether the logger is a premium member, and showing that sometimes forces an extra line in the log entry, so don't show it. This is optional and independent of the other specs. */ .logOwnerBadge {display:none !important} /* All the smily faces in the left column confuse me because it's the same image as for the Found It log, so don't show it. But then the counts need to be bolder. This is optional and independent of the other specs. */ .logOwnerStats img {display:none !important} .logOwnerStats {font-weight: bold !important; color:#000000 !important} /* All the following adjustments to text size and color are optional and independent of the other specs. */ /* Make the log date display larger and bolder. */ .LogDate {font-weight: bold !important; font-size: 100% !important; color: #000000 !important} /* Move the log date closer to the log type. */ .LogType {width:20% !important} .LogType + div {width:76% !important; text-align:left !important} /* Well, now it's obvious that the log type is not black either. I'm a man, I can fix that. http://emmanuelfonte.posterous.com/im-a-man-i-can-fix-that */ .LogType {color: #000000 !important} /* and the log text too ... */ .LogText {color: black !important} /* In Dec 2011, gc.com decided to double-space everything. Just say no. */ body {line-height:normal !important} /* Make the text black everywhere a color isn't needed, and especially in short and long description and hint. The fashionable gray text now found all over the web is hard on aging eyes. */ body {color:black !important} -
I am also having a problem - my image is resized from 595px wide to 300px wide and the EXIF tags are stripped out. [
]The EXIF tags are needed to solve the puzzle ....
The solution for you is to host the image somewhere else, where you can control exactly what is stored and served. This means not on gc.com, not on Flickr, not on any free service or any place whose primary purpose is to present photos. Your ISP may provide you with a small amount of web space; this would be a good place.
While serving your particular image exactly as-is might be reasonable, in general GS has to deal with a huge variety of images, and in the majority of cases the uploader knows little or nothing about optimizing the image for the web. And at least 99.99% of the time, sending the EXIF data to the browser is a waste of bandwidth. So I expect GS to continuing modifying images automatically.
Edward
-
I recently rode my bicycle 70 miles to find one cache. Yeah, that was a good way to run up big numbers. The numbers would be even larger if the US went metric.
Edward
-
You should have upgraded to GSAK v8. Five clicks total would have uploaded the entire list to your bookmark list.
Edward
-
I'm currently #19 in found log length on mygeocachingprofile.com, yet I very seldom run into the log length limit. One reason is that I tend to write the story of a day, and I can shift elements from one cache to another.
No one has ever complained that my logs are too long. Of course, by saying that, I'm inviting complaints ...
If it's an easy change and wouldn't cause any problems, I'd say do it. But if it's going to take a significant effort, or if there are related problems, I'm happy to continue as is.
Edward
-
The same applies to photos attached to the cache description. At one time it was possible to write the cache description to use lightbox, but that was eliminated in an HTML control cleanup. GS should provide us a better way to view all the images attached to the description. (And even better, a way to specify no link to the image if it's embedded in the HTML description. There are ways to do this -- attach the images to a log on an inactive cache -- but those workarounds are much more difficult.)
Edward
-
you do know that FF is at v.8, right?
While this is technically correct, v3.5 is only about 8 months out of date. The intervening releases were not really major releases -- it was just a version jump to bring it more nearly in line with other browsers.
Edward
-
The huge problem with such polls is that the responders are self-selected. A self-selected poll means nothing. And I do not use the word "nothing" lightly: it means nothing. Reid's Second Law of Statistics: Never Underestimate the Power of Selection.
I much prefer the way GS is doing it now. They appear to be listening to the informed voices who post here with information and ideas. But we cannot speak for the 99% who never participate in the forums, and who are almost certainly quite different from us in many ways. The very fact of posting here, even reading here, makes us unrepresentative of the community. And the community did not elect us to speak for them.
As a result, using polls here would actually make geocaching less democratic. Not that it's ever been democratic, but still.
So I prefer that GS continue listening to us and attempting to decide what's best for the entire community. They won't always be right, not by a long shot, and I'll be here helping to hold their feet to the fire. But they'll be right more often than our votes would be.
Edward
-
Definitely a great idea. Another aspect is that, while there are good reasons not to send bounces to messages sent to the noreply address, those reasons would not apply to the disposable address. So if someone replies after the time limit has expired, they'll know the message didn't go through. If the disposable addresses start getting on spam lists, the bounce could be disabled after a few months.
Edward
-
I don't believe there has been any change to the way the logs display in this November release.
I'm not completely certain, but I *think* that last month the logs only started loading when you paged (or scrolled) down. You could open the cache page and hit End and you'd see the end of the description with no logs. If you do that today, you'll see the 25th log at the bottom of the page (by my quick count). But in any case, yes, it's definitely faster now than it was last week.
Edward
-
Leader carries loppers and pruning saw. Don't need them? You're not seriously in the woods.
Edward
-
TeamPumpJack,
If you are doing enough geocaching to need a map, then you need GSAK. As mentioned earlier in the thread, download the PQ into GSAK, then use the macro Google_Map_V3.gsk. It displays a map of exactly what you want to see, and in addition does clustering. Extremely useful.
Edward
-
Right, but do it for BBCode too. Last time I looked (no, I didn't look today) there wasn't even a clear statement that BBCode was supported in cache descriptions. Despite the similarities, I think the BBCode is enough easier to be worth describing how it's supported.
Edward
-
I agree, this is needed. With modifications and additional design of course -- I'm sure the OP would not disagree.
- Require 3 (or perhaps more) reports to mark a TB missing. Ignore the passage of time.
- Use a text marker, perhaps "(reported missing)", for easy comprehension.
- Do NOT use Yet Another Icon whose meaning we have to remember. Too many already.
- Do NOT use gray text. It's bad enough that GS is already using freaking gray text in the fashionable manner of thirty-something web designers who have not yet experienced the joy of lessened contrast perception that comes with age.
- The CO or TO should be able to clear "missing" reports with a new log type.
- Possibly the TB should remain in the inventory indefinitely on the main cache page, as an indication that proper maintenance is not taking place, but be ignored in other contexts.
Edward
- Require 3 (or perhaps more) reports to mark a TB missing. Ignore the passage of time.
-
Definitely ... though it isn't a huge deal, I've often wanted to do this.
It's become easier with the latest GSAK: load a PQ of the bookmark list into a new database, and do geocaching.com access -> add to bookmark list. That's still going around my elbow to get to my mouth. And it should be a relatively easy thing to implement, since the function to add a list of GC#s to a list is already present.
Edward
)
]
Forum restructure
in General geocaching topics
Posted
All sounds like good moves at first glance. I'd still be interested in hearing a bit more of the reasons.
Edward