jon & miki

Assuming ;your images are now appearing, you can set an exception for img.geocaching.com and recheck the box if you like.

Check the Tools/Options dialog under the Content tab. Is "Load Images" checked? Is "for the originating website only" unchecked? There are some GreaseMonkey scripts to further refine the image loading behavior - any of those installed?

Call TVNav.com. They're very knowledgeable about the status of all Garmin products and if they don't know the answer, they will go find out. A search of their website shows several remanufactured GPS's being sold with R&R, but you'll need to talk with them to find out if they have it packaged separately. Also, I saw a copy in a local sporting goods store about 6 months ago, so you might try Walmart and any of the bigger sporting goods stores in your area.

Ummm, a state legislature would have no standing in the matter. They could not prescribe whether or not a cache could be hidden (or found) on private land. On the contrary, private land can and does overlap with areas of government interest such as cemeteries, historical and archeological areas and our state government can and does restrict what landowners can do with their own land.

The b&w legend is a good unit for a beginner, at least if you are not concerned about maps (which often won't have the level of detail you need for geocaching anyway). The built-in compass is helpful for a beginner trying to get to the right area, but not absolutely necessary. The screen visibility in sunlight could be better (for that I would recommend the color units), but I've used my Vista for geocaching almost since we started geocaching and been very happy with it. I'll probably upgrade to a color unit when my Vista finally packs it in though.

Or consider a Garmin eTrex yellow. You should be able to find it under $100 at various stores - Walmart in our area stocks 'em. It's a basic unit without maps, but you'll be over your budget anyway if you need to buy a gps and maps. And it makes a great backup unit - I use my yellow when I'm out kayaking and keep the more-features gps for dryer pastimes. If your brother-in-law decides he wants a "better" gps later, he'll probably want to look at the various features that are important to the way he actually is using the gps and of course, the costs for everything including maps. In the meantime, a yellow will work perfectly well for geocaching or for marking hunting or fishing spots.

Miki and I would like to thank all of you who voted for us in the recent El Diablo hiking stick award contest. Neither Miki nor I had even noticed the thread until Saturday morning, so the nomination was a considerable (and very pleasant) surprise when we saw the post on the SE national forum that we were in the final 5. Actually receiving the most votes was completely unexpected! TandS' nomination "speech" was touching and we appreciated it and the votes as much as we will enjoy using and showing off the hiking sticks themselves. It must be remembered that there were many involved in the fight against H3777, and many of those same individuals also participated in the Camp New Horizons geocaching activity with the kids. Certainly TandS' essay could easily have been a good description of Travis & Stephanie themselves, and would also have fit Sissy n' CR, Llatnek, Hologram21, or ScienceNerd with few if any changes to the text other than a few more accolades for their work. And many other geocachers have given community service in a variety of areas. Any credit that Miki and I received ought to have been shared with many others! Again, thank you for the nomination and the votes. We will treasure both while we work on putting a few miles on those sticks. Jon & Miki

Thought so, but glad to have it confirmed.

A new exploit has been reported that allows a malicious web page on a trusted site to gather remembered passwords from Firefox and Internet Explorer browsers - see this article for details, a demonstration and a workaround (disable automatic remembering of passwords). Do the geocaching.com website HTML filters prevent this type of form from being posted in cache pages and profiles?

The initial cache that started the SC legislation was placed in a cemetery on private land without permission. The locals wanted to know what cachers were doing in "their" cemetery. If the locals had been contacted before placement, the issue probably would not have started up. And alone, that cache would have been a minor issue, but the representative who chose to make a case of it took the position that a lot of caches were being placed without permission and without due respect to the historical significance of the areas and was able to amass considerable evidence to support her position (at least as far as permission was concerned, there was little evidence to support the purported disrespect). That's why the proposed legislation (in all its various drafts) focused on requiring written permission to place a cache in many areas of the state. Some versions went further, but every version required written specific permission to place a cache in large ill-defined areas. The proponents of the legislation used a "shotgun" approach, accusing geocachers of every sin they could think of. Nearly all the accusations leveled against the hobby could be refuted by simple reference to the actual facts except the permission issue. Placement of caches on private land without permission was a major part of her "evidence" and the most difficult to refute since many of the facts supported her position. (I should add she also listed placements on public land that had rules and regulations that restricted games or geocaching specifically as part of her evidence - it wasn't purely a private land issue). Of the 40 or so caches in two cemetery series that were explicitly mentioned in the representative's presentations, I was unable to find even one that had been placed with any sort of permission or even awareness of the cemetery managers. That made it far more difficult to defend geocaching as a legitimate activity respectful of land owner rights since caches were being clearly placed on private land without permission in spite of specific guidelines on the geocaching.com website to the contrary. (and yes, there were placements on public land that she construed to be in violation of NPS and National Cemetery regulations as well and used as "evidence"). I did not intend to hijack this thread, so I'll shut up now. My point was only that the "ask forgiveness later" approach can backfire badly on others, not just the original cache hider. I've seen it more than once and not just in the SC legislature.

Hmm, I was under the delusion that I lived in Columbia SC and had actually met with the representatives sponsoring the bill, spoken directly with them, and even seen their presentations. Heck, I even thought I was one of the folks involved in the "successful effort" to stop the bill in the Senate. My delusions included the observation that a lack of "adequate permission" was a major force behind the bill and it was one of the items that made our defense MUCH more difficult. Thanks for straightening me out.

Yep, lots easier for the original hider. Especially since he or she is probably not the one who has to ask for forgiveness later. Lots harder for the person who has to follow him/her after the land managers discover that they've got 15 caches on their land and that not one was placed with any kind of notification to the land managers. It's a little hard to convince land managers of how concerned we are about the land and how sensitive we are to land manager's needs when we take that attitude. I believe the "forgiveness" approach is exactly how geocaching has gotten banned in some parks - the land manager didn't feel "forgiving" or their first reaction was "get the &$%^#%^# things out of here". The "ask forgiveness" approach certainly provided a great deal of ammunition to the South Carolina legislature when they tried to pass a law requiring written permission for many cache placements in our state. Actually, I have a hard time understanding how a cacher can even claim to know whether there are or are not policies regarding geocaching in a given area without talking to someone responsible for the land. I think the constant use of the word "permission" is part of the problem though. Too much angst from our teenage years perhaps? Maybe it would be better to think of it as notifying the land manager that you've placed a cache on the property they are responsible for? At least the land managers ought to be made aware in advance of why folks are rooting around in the bushes in a certain area and have any concerns about cache placement taken into account. Just let 'em know what you're up to, is that so hard?

All I can say is that's what I'm seeing too. The boxes did not occur with the old email-bot, they do now. The boxes are always associated with new lines in my case, so perhaps there's an extra character involved (lf and cr maybe instead of just a cr)?

A simple copy/paste does it, but it might be nice to have a link to save a step or two.

We got today's weekly notification OK, although the formatting in the Eudora mail client is kinda weird. Lots of square boxes etc. It's readable, just not very pretty. Although Eudora's HTML renderer is, shall we say, sort of "imperfect", I guess I'd like to see a user option for HTML-formattted email with the expectation that it would be a minimalist kind of html, not so much fancy formatting as to confuse Eudora, just enough to make it readable.

I think there have been more than one case, but here's one that was mentioned in the forums a while back.

Sorry, looked at the wrong calendar or something. Saturday, October 28th is the date of the geocaching activity. I don't see any way to correct the title - can the moderator do it?

A while back the SCGA was contacted regarding starting a geocaching-based team building exercise for the summer camps that the Palmetto Health Cancer Center runs for kids in South Carolina. Palmetto Health runs several camps for kids and families. Camp Kemo is one, it's a week-long camp for kids with cancer or their siblings. Camp New Horizons is a weekend camp for kids who have lost a sibling to help them handle bereavement. There are several other camps, but I don't know much about those yet. The trial run of geocaching as a camp activity will be happening on the morning of Saturday, October 29th at Camp New Horizons near Batesburg/Leesville. If the exercise works well, geocaching activities will be included as part of the other camp's activities. There will be 6 groups in all making cache runs this time, so I'm hoping to have 6 geocachers to provide tech support to the counsellors with each group - you know, making sure the kids are pointing at the right cache, changing batteries, stuff like that. We've provided some training to the camp counsellors already, but they will still will need some support until they get some real-world experience. I know many of the readers of this forum are located too far away from the camp to help, but I thought I'd ask here anyway. We've already got 3 geocachers helping out for sure so far, but I'm looking for 3 more so assistance can be close at hand for each group if there are any problems. If you can spare the morning to help out, please email me and I'll fill you in on the rest of the details. Thanks Jon

Nope, I don't think they've gone anti-mac. I browsed the forums this morning with Firefox and MacOSX 10.3.9 with no problems. Since you see the problem on OSX and OS9 on different Mac's, it would seem like the problem lies upstream (unless you've got 3rd party firewall software on OS9). I would try connecting one of the mac's directly to your cable or dsl modem and see if the problem persists. If it does, you can probably declare your router innocent. My next troubleshooting step would be to use an alternate DNS service (OpenDNS is quite good) to see if your ISP's DNS services are the problem (I'm presuming you'd use a different DNS server at work). At that point, I'd be out of ideas. Let us know what you find out? Jon BTW it just occured to me that you might only be talking about difficulty with the cache pages. Do you have the same problem accessing the forums or just the cache pages?

Yet another approach, one I at least would find a little more user-friendly, would be to put a limit on the number of times queries could be run instead of using a time limit. That limit could be applied on a per query basis or against the total number of query runs made. On a per query basis, allowing 26 runs (for example) before the PQ had to be re-ticked would allow the folks who run a weekly query to go 6 months or so before rescheduling while making folks who generate higher loads reschedule on roughly a monthly basis. If the limit was set up to be based on how many runs could be made for ALL pocket queries before rescheduling, the effect would be to favor those who did not overload the system with pocket queries. With say 300 runs allowed, someone running 10 pocket queries on a daily basis would have to reschedule monthly while someone running just one a week would probably never have to reschedule. This approach in effect allows each cacher a limited amount of server usage before rescheduling rather than setting an arbitrary time limit. I hope gc.com will consider these proposals along with any offered by others as a better long term strategy than the currently implemented one.

I'm sure everyone has different requirements and methods for using PQ's. In my case however, I use PQ's so I can have as complete and up-to-date information as possible about a cache on hand when I go to hunt it. We travel for a variety of reasons (not just caching) and do not typically plan out our hunts in advance - weather, proximity, mood, energy levels, available time & daylight all play a role in selecting the caches we go for and most of of that information isn't available until we're in the area. (I should add that we usually don't have web or wap access while we're travelling, we rely on Cachemate for a static picture of the available caches) I do understand the need to somehow cull out PQ's that are not being used. No matter how big the server(s), an ever-increasing load can eventually overcome any conceivable upgrades. I for one would be willing to give up scheduled PQ's entirely if I could have a single query with the following caches included in the results file: all caches that had their description changed since the last time the query was run all caches that had their coordinates updated since the last time the query was run all caches that have been logged since the last time the query was run along with the "new" logs entered since the last time the query was run (not limited to 5 or 20 logs. If a cacher wants to have the logs in hand for a new cache in our area, they pretty much have to run a "new caches" query daily; with a 5 log limit, they may still miss some logs that would have been invaluable for finding the cache.) no 500 cache limit (perhaps a file size limit of <10mb might be applied though or limit results to a couple of states could be used to prevent hijacking the master database) only the cache GC# plus an archived flag for all caches that have been archived since the last time the query was run To my thinking, the complete cache information should be included for caches under criteria 1-4 and only minimal information provided for archived caches (no coordinates, description, logs etc). Since older caches get logged/changed/updated much less frequently, I believe the results file size might actually get smaller with this sort of query. If scheduled queries could be superceded this way, the whole issue of "deadwood" queries could be made to go away. And the number of queries needed to cover an area (like the UK or one's normal hunting range) would be reduced as well, with the side effect of removing duplicate results before they are sent out as PQ files. With this kind of query, I could simply ask for the results when I'm getting ready to travel or go on a hunt. In my case anyway, we would no longer need scheduled queries at all, we'd just ask for the updated results whenever we were ready to go on a hunt. If we were travelling, I would do what I do today, schedule a one-shot PQ for the area or route we plan to hunt along.

We are set up exactly the same way as Potato Finder. We do read all the emails that come to the address we set up for geocaching communications, but the PQ account is reserved just for PQ's. It probably would have been better to send an email to the address we supplied for communicating with Groundspeak rather than the PQ account. I probably would have not detected the change for a few weeks when PQ's stopped coming in, but at least the forums brought it to my attention sooner. edited for clarity

No need to submit another query. Go to your pocket query summary page The leftmost icon on the line with the problem PQ will trigger a preview of your query right in your web browser (no waiting for email or working within the scheduling constraints). Then you can test and debug your PQ as much as you need to before you finalize it and schedule your email. Once you've got the PQ working the way you want it to, then schedule an email of the query and see what happens with the file you get then.

The best place to start is on the GSAK forums - I'd repost your question there. The folks hanging around the GSAK forum are very knowledgeable and usually respond very quickly to questions. Besides the advice, you'll also find some tutorials and helpful macros on the website.

Well, one or maybe two things seem to be wrong with you PQ, but then you already knew that. The first thing I'd suggest looking at would to get to the PQ page and run/preview the PQ manually. Are the "extra" "long distance" caches showing up in the preview run? Are the "missing" caches still missing? Are you at the maximum 500 caches that the PQ can include? If the problems persist in the manual run, the problem is in the query and you need to post the settings (you may be able to provide just the URL of the query - I think I read somewhere that anyone can see the query terms if they have the URL). The GSAK problem may become irrelevant if you can solve the PQ problem. Still, if you want to tackle the GSAK problem now, I can tell you that I've used the approach of loading GPX files into a folder then importing them into GSAK with good success before, so what you're doing should have worked. Instead of dragging the folder onto GSAK , you might try importing the GPX files from within GSAK via the menu. Don't forget to check the box to download all files in the folder. Also I'd check on my import settings (I believe they'll be used as the default if you drag a folder in) - some settings will clear the database before loading a new file or disregard some data or overwrite it, so check those settings carefully and (make sure you're set to import a folder when you start the import).