marnen

I believe you're thinking of burdock.

Again, so what? If we've got rules, they should be enforced without regard to "friends". If we do not do this, there is no point in having the rules in the first place, in which case the rules should just be ditched for everyone's continued sanity.

Who cares how many finds the hider has? If it violates the rules, then it violates the rules, no matter the number of smilies after the hider's name.

Site is completely down as I write this.

Very likely not. According to its specs, the Z22 does not come with a Web browser. However, if you install a browser (or AvantGo, which incorporates a Web browser), I would guess that you will be able to read HTML files on your Palm with no problem. I have a T|X, which has a Web browser, but I've never tried to do this, because I convert everything to PDF and then use PalmPDF to view it instead.

Since I'm not a premium member yet, I use the Google Maps feature on the Advanced Search page. It works beautifully, although it might be too much work for routes of more than 200 miles or so.

What BRTango said. Poison ivy isn't true ivy (see http://en.wikipedia.org/wiki/Poison_ivy ), and contains an irritant (urushiol) that many people are sensitive to. I didn't realize it wasn't found in the UK. (True) English ivy, on the other hand, is no problem at all, and we've got lots of that here too.

I wouldn't put a cache in the middle of poison ivy (unless that's supposed to be the challenge!), but when I'm looking for a cache, I don't worry about it. I'm not sensitive to it, and neither is my fiancée, so it's not an issue.

There is another way, if you don't need automation or aren't a premium member. On the advanced search page, there is an option to search with Google Maps. Since the map is draggable, you can go along the precise route you plan to take and see what caches are there. I do this fairly frequently.

May I suggest spending some quality time with your GPSr's manual? If you didn't get a paper copy with the unit, you can find a PDF file at http://www.garmin.com/manuals/eTrexVistaCx_OwnersManual.pdf . Yeah, that happens -- typical GPS accuracy is only about 20-30 ft. It may be helpful to display the accuracy as one of the data fields on the screen (the manual should explain how to do this).

GSAK has no Mac version, but MacCaching does many things that GSAK does. CacheMate is usable with a Mac; see the website for details. For myself, I just print the cache description to a PDF file (which Mac OS X can do with no additional software) and view it on my Palm with PalmPDF.

Premium fuel probably doesn't make a heck of a lot of difference to mileage, so I doubt very much that this is the reason. That said, it's not true that no car requires premium fuel. Some cars do have engines that will knock on lower grades. But it is true that you can safely use the lowest grade of gasoline that won't cause knocking -- those people who tell you to always use premium fuel in any car are simply telling you to waste money. Now onto the topic: I have a 2006 Scion xB (with 69,000 miles on it already!) I love that baby.

I would recommend that if you have "no special reason" for your preference of operating system, you might want to consider dropping that preference, particularly if you're on a tight budget. You can probably find a nice used Palm Tungsten C, E, or possibly E2 or T|X in your price range... EDIT: I thought you were the OP at first. I now see that you're not. Your price range would suggest Palm even more strongly -- I think some of the Zire and Z-series models sell for only about $99 new, so used should be even less!

And to answer your questions about how the conversions are done, it's just simple arithmetic. 30° 0.500' = 30° 00' 30" = 30.00833°. (Yes, I did all that in my head.)

Alternatively, while GC.com won't accept this sort of thing, TerraCaching or Navicache might.

The local managers have discretion to ignore the NPS's general ban? What a weird system.

Neat idea! You might also be able to achieve the same effect by printing in mirror image on the reverse side of transparency film, then spray-painting a background color over the ink.

Exactly -- and that's why they should always be marked.

Well, that's perhaps outside the scope of my original feature request (because at the time I didn't realize that it was possible, and so did not address it), but you'll note that I already answered that question in this post. My feature request is certainly less urgent in this case, but it would still be preferable to have a unique filename, as I explained in the post cited above. No, even in this case, it would be a near-trivial fix -- particularly if the filename need only be unique, not meaningful. Do you speak for Raine and Jeremy, then? That's good to know.

It's not simply the fact that it was done differently than I would have done it -- everyone will do things slightly differently, and I have no problem with that. What makes me characterize this feature as "broken" is that, for no obvious reason, it is implemented in such a way as to make the user's life (almost) maximally difficult, when an almost trivial enhancement would result in a significant gain in ease of use. There is no good reason at all that I can see to justify this aspect of the current implementation.

I hope that post wasn't meant to be as condescending as it seems. I believe I have stated that I am currently doing this. I just don't believe I should have to. I take the opposite approach: when I write a Web application, I never ask the user to do something that the app can easily do. That's just not good UI design. After all, the purpose of a well-designed application is to help the user, not to burden the user with extra administrative tasks ("excise tasks", in UI jargon). Generating a meaningful, or at least unique, filename is something that the app can easily do, but is nothing but extra work for the user.

Pocket Queries are irrelevant to my current feature request. I'm asking for a simple enhancement to .LOC files, which have nothing at all to do with Pocket Queries. In my opinion, this "enhancement" (such as it is) should have been incorporated in the first place. If you don't like .LOC files, you don't have to use them, but there are those of us who do use them, and I believe it's not out of order for us to ask that .LOC download should work a little better. In other words: I believe that part of GC.com's .LOC download functionality is broken. There are workarounds, to be sure, and I am using them for the moment, but it would be better if what was broken was actually fixed.

I write applications that do things like this all the time. It's not complicated in the least. The search form has access to the criteria I searched on, so actually a name like SearchZip12601.loc would be extremely easy to construct. But if that's too much stress on the servers (which I doubt), even just using the process ID or other meaningless unique ID -- such as Search123454321.loc -- would be preferable to calling everything geocaching.loc .

Don't do that. Nobody is going to bother to open up a suspicious-looking unmarked container -- or at least, no one should be that stupid. I believe relatively strongly that all geocaches should have some sort of mark on the outside stating that they're geocaches. Many state park authorities require this.

The calculation should be pretty simple. Working it out in my head, I think it goes as follows (someone please correct me if I'm wrong): 1. Change the latitude to the other hemisphere, so that north becomes south and vice versa. 2. Add or subtract 180° to or from the longitude. Voilà, you should have your antipodal coordinates.