Bob Blaylock

I had an experience with this myself. Being in the area where I had hidden the second and final stage to my Seeking After Signs cache, I decided to go and check on it. I didn't find it. It wasn't a very good hiding place anyway, and I figured it'd fallen victim to muggles. I scouted out a much better hiding place, and put together a new container, which I put in the new hiding place, and updated my cache listing to reflect the change. Having done all this, I heard from someone who, later in that same day, did successfully find my original second stage. Based on additional information from this finder, I went back and found my original cache sitting almost out in the open, in a pile of leaves perhaps six feet or so from where I had originally hidden it. I guess there's a lesson in here somewhere. I was too quick to assume that my original cache was gone. No tragedy, though. The original hiding place wasn't very good, and if it had stayed there, I'm sure it eventually would have fallen prey to muggles. The new hiding place is much better, and I used a much better container for it.

Gesundheit!

I'm running MacOS X 10.2.8 on a beige Power Macintosh G3, and I have my eTrex (the basic yellow model) connected thereto via an RS–232/RS–422 serial connection. (The beige G3 was the last Macintosh to include built-in RS–422 serial ports.) I have had good results using Mac SimpleGPS with this combination. It works quite well with .LOC and .GPX files, and with transferring waypoints back and forth between my Macintosh and my GPS. USB may be a problem. I gather from some other threads that Garmin's implementation of USB is badly–broken, in a manner that Windoze is able to cope with, but which causes problems for some other systems. I am also given to understand that MacOS X 10.3.8 includes a workaround in its USB driver, specifically to cope with Garmin's broken USB implementation. I don't have any firsthand knowledge on this issue, as my GPS doesn't have a USB port, and my computer won't run anything later than MacOS X 10.2.x. Since Mac SimpleGPS is free, you don't have anything much to lose by hooking up your GPS and giving it a try. If it doesn't work, then you may need to get the necessary cables and adaptors to connect your GPS via its serial port rather than its USB port.

As long as that loin cloth was cut with a flint rock and sewed with a bone needle! Cutting and sewing, and in fact, any use of — or creation of — tools, is technology.

Amid the flurry of new threads about virtual caches, I've had a thought that seems to not quite fit in any of the existing threads. I have hidden my first, and so far only two caches within the last few weeks. Each of these caches was inspired by something that I randomly came across (actually, it was my wife who found that which is the basis for Seeking After Signs…), that I wanted to show to my fellow geocachers. If I could have submitted them as virtual caches, and had them approved, I probably would have, since in each case, the thing for me was to have others see what I had found. Since I am quite sure that neither would have been approved as a virtual cache, I made each into the first stage of a two-stage puzzle/multi cache; using information to be found at each of these places to calculate the position for an otherwise–unremarkable physical cache. It seems to me that a virtual cache, as it currently is defined, isn't really a geocache at all. Perhaps that's the problem — we treat it as if it is a geocache, subject to the same rules, restrictions, and such as a real geocache. I don't know what ideas Jeremy is currently working on with regard to virtuals and locationless caches, but perhaps a good idea to add would be to treat these (along with the recently-defined Earthcache type) as something entirely different than a geocache. The term “geocache” could be solidified as referring only to an actual, physical container or object placed by the hider; with another category, counted separately, for “really neat things that I want other geocachers to see”. This latter category would be treated separately from geocaches, as benchmarks are now treated as separate from geocaches. As such, I propose that these should not count as cache finds, and should not be subject to the 1/10–mile restriction. Any thoughts?

In place of all those steps between MacGPSBabel and GPS Connect, I suggest you give MacSimpleGPS a try. It reads .LOC files directly, (.GPX too) and transfers them to the GPSr without all that back and forth.

Good solution for the paranoid: Just give your coordinates to the nearest or last minute. That's accurate enough to give people the general area, but not enough to pinpoint exactly where you are. A minute of latitude is a nautical mile of distance; a minute of longitude somewhat less, depending on your latitude. With that in mind, here's my location, to the nearest minute each way: N 38° 34' W 121° 29'

One time, when my wife and I were out caching, we spotted a couple who we suspected of being cachers as well. What seemed to me to be a “dead givaway” was when the female part of the other couple held an object that was very obviously a GPS up and started talking into it as if it was a cell phone. I suppose this ruse might be useful for fooling muggles who are sufficiently ignorant as to not be able to tell the difference; but to me, and my wife, it was very clearly obvious that the “cell phone” was a GPS.

I can't speak for others, but for me, I paid the thirty bux because I get a lot of enjoyment out of geocaching, because I know that it costs a lot of money and manpower to run this site, and because I felt I should do my part to support it. That I get some improved functionality out of the site as a result of being a paid member is a nice bonus.

Speak for yourself. I was terribly disappointed when the NeXT failed to catch on; and delighted to find it reincarnated in the form of MacOS X. The Unix-based underpinnings are exactly what MacOS needed to bring it up to date. “Classic” MacOS was great in its time — when the competetion was MS–DOS and WIndows 3.1, but it desperately needed a major revamp to keep up with Windows NT/200/XP, and MacOS X is exactly what it needed to become. I guess that's the point. With MacOS X, you don't need “…tools and ability to keep their machines running and keep them safe from Internet pests.” MacOS X simply doesn't have the gaping security holes and vulnerabilities that allow all the sorts of abuses that are happening to Windows systems.

Changed it. Thanks for finding the issue and recommending a fix! Fortunately I had some forethought and only had to change it in a couple places. Whew! Thanks, Jeremy. Much better! It's definitely my favorite browser. I think what I like most about it is that it gives me a great deal of control over what sites are allowed to do what to me. It lets me specify (using GREP patterns to match on URLs) what any given site, or any given part of any site, is allowed to do regarding cookies, Java, Javashi^H^H^Hcript, embedded objects, and such. I don't think I've ever seen any other browser that offers such fine and detailed control of such things. It's also one of the faster and smaller browsers available for the Macintosh. Its downside is that it can be very picky, some times, and if any browser is going to break because a web site wasn't done exactly right, iCab is probably the one that'll break. It's less tolerant of bad HTML than most other browsers are. It's for this reason that I earlier said something to the effect that if you can get a web page to render correctly on iCab, and if it shows a green smiley face (meaning that it believes there are no errors in the HTML) then it will probably render correctly on just about any browser.

Jeremy, I do not know if you've been reading this thread, wherein I discussed problems that the new look has caused with pages being displayed under iCab. In short, extended unicode characters are not being displayed correctly. For example: The problem, it turns out, is in this tag: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> It needs to be changed to this: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Would you please fix this some time soon?

Exactly correct. The regular page has this near the top: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> The printer-friendly page has no content type specified. While developing the latest version of Spinner (in beta test now), I have determined the most effective setting is: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> This is an international sport, and thus a lot of international characters end up in the cache description. Specifying a US character set, such as the cache page now does, causes problems for international users. I highly recommend specifying the UTF-8 content type. That seems to be exactly the problem. If save the source to my hard drive, and change the type to UTF-8, and load it in my browser, it displays correctly. If I remove that tag entirely, it displays incorrectly until I manually tell my browser to display it using UTF-8 encoding. Apparently, iCab will allow you to manually specify what encoding to use if the page doesn't specify, but if the page specifies an encoding, then iCab will not override that. Jeremy, are you reading this thread? In all the “new look” pages, please change this tag… <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> …to this… <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> This will apparently correct the display problems that I am having with iCab.

I have just discovered that the “Printer Friendly” version of a cache page displays correctly under iCab, even though the non–“Printer Friendly” version does not. I've spent a bit of time trying to figure out what the difference is, and have yet to come to any useful conclusion. I did determine that the same two bytes are sent in each version for a degree symbol [C2 B0] which correctly display on the printer-friendly page as a degree symbol, but which display on the non-printer-friendly page as a  followed by a degree symbol. I'll have to try some other things later. It's probably something elsewhere in the page that tells the browser what character encoding to use.

I own a mac and it looked fine. Hmm... Jeremy, if you have a Macintosh, please go to http://www.icab.de/ and download and install the iCab browser, and use it to view various things on the site. This is the browser that I use. It tends to be rather picky about some things. If you can get everything to render correctly in iCab, and if there's a green smily face near the upper right, then you can be quite confident that the page will render correctly on any browser. If there's a purple frowning face, or a brown neutral face, clicking on it will bring up a list of things that iCab thinks is wrong with the page. With the current “New Look”, iCab is having issues correctly displaying extended Unicode characters; these displayed just fine under the “Old Look”. More coverage at this thread.

It appears that your “New Look” is doing something incorrect with unicode characters. Netscape and Safari (on the Macintosh) apparently are able to work around whatever is wrong, but my preferred browser, iCab, does not. As a result, wherever characters beyond the basic ASCII set are used, they nearly always are displayed incorrectly by iCab. This all worked correctly under the “Old Look”. Here's an example: This is from my own cache, Metered Access. Where I used proper & entities to define characters in my own HTML code, those displayed correctly, but where I included the extended characters directly, they did not. It's really a better practice to use & entities wherever possible, anyway, and I have edited my own HTML in this listing to use them everywhere that I had previously inserted such characters directly. However, it wouldn't let me use &NBSP; (non-breaking space) in the encrypted clues; it encrypted them before sending them on, so they displayed as “&AOFC;”. The formatting of the listed coordinates in the upper left corner are outside of my control, however, and it appears that the degree symbol is being sent directly, and is being corrupted in the manner that I have described. There also appear to be major errors in HTML syntax throughout the site. Here's what BBEdit's HTML checking feature has to say about the home page at http://www.geocaching.com/:

Having read the article, and having lightly browsed the site where it appears, I must say that it looks like Mr. Donnelly and others responsible for that site could really stand to benefit from the information that is to be found here.

It's IE, and it's from Microsoft. What more explanation that that could possibly be needed to answer the question?

One of the stronger guidlines is no food in caches. Other items that have smells that might attract animals are similarly discouraged. The reasoning behind this seems sound to me. It has occurred to me that it is common to use containers for caches that formerly contained food. Plastics tend to hold, for quite some time, the smells of whatever was in them. Might this be a concern?

Give MacSimpleGPS a try.

I'm sure that there are many instances (my recently-approved first and so-far only hide being one) where a major part of the purpose of the cache is to show seekers something the hider thought was neat, and which, in earlier days, might have stood alone as a virtual. In the case of my cache if you had the final coordinates and just went directly to the cache, skipping the first stage, you'd find a fairly unremarkable cache; just a container hidden in some ivy, with the usual trinkets. It's only the first stage that makes this cache any better or any more interesting than the blandest of traditional caches. I'm working on a second cache for which this will probably hold true as well. I've found something neat, that I want to show my fellow cachers; but I have yet to figure out where I am going to hide the actual cache.

My brother recently moved to Laredo, Texas. There are, as of this time, only thirteen caches listed within a hundred miles of him.

One thing I learned the hard way some years back is that Tyvek DOES NOT go through a laser printer. It melts when it hits the fuser, making a terrible mess. The same thing would almost certainly happen with most photocopiers.

http://www.geocaching.com/seek/log.aspx?LU...5a-b28b490bdc5b

I suppose things like this are why we have so many “guidlines” instead of “rules”, with the approvers given some discretion as to what to allow, and what to deny, on a case-by-case basis. Just today, I found a cache which had a name suggesting that it might be connected with an eating establishment. It came up on a search of caches near somewhere I had business to conduct, and I decided that if it was an eating establishment, and the prices and offerings were to my liking, I was gonna have lunch there. (As it happens, the cache was at an eating establishment, which is apparently connected with the company under discussion with regard to the OP's “on-hold” cache.) Was this cache consistent with the guidlines? Apparently, a local approver decided it was. In this instance, it did end up (probably not by intent, but as an obvious effect) providing a bit of advertising for the restaurant. If this cache wasn't there, I would probably not have eaten there today. In Buelton, a small town not far from where I used to live, there's a much more blatant cache — a virtual that makes reference to a very famous restaurant in the area, and encourages seekers to eat at that restaurant. I suppose there's a point where advertising would detract from the enjoyment of geocaching. In spite of the two examples that I just mentioned, I do not think it's yet come close to that point. I guess the purpose ofthis particular guidline is to make sure it doesn't.