Urubu

On a public profile, look under [statistics], then [Maps].

There's this pair of ferry caches in the Seattle area: Ferry Cache I - Seattle to Bremerton Ferry Cache II - Bremerton to Seattle On the ride between Seattle and Bremerton (and reverse) at specific coordinates, you need to get information to determine the coordinate of the final cache at the end of the ferry ride. This is a nice "moving" cache on a ferry, illustrating the Heisenberg Uncertainty Principle (you can measure the cache's position, or its velocity, but not both!): http://coord.info/GCKEBC .

Noooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.

Yet another option is a Wiki . There are several free Wiki sites. I've used http://www.wikidot.com , for example.

Carry a clipboard. It's a license to inspect anything.

MD, this was extremely confusing (to me, at least). It sounds like you're talking about a hypothetical, as-yet-nonexistent Send KML button that could be added to the site to send Map It results straight to Google Earth ??? If so, that's a nice idea. It wouldn't make browsing for caches and routes as easy as with the Google Earth KML add-in, but it would help.

I won't say that it's anywhere near as easy as with GE, but you don't have to do steps 3 or 4. As soon as you create the PQ (even if you don't ask for it by email), there's a one-click "Preview in Google Maps" icon right next to it. Please do not construe this as a vote against the live KML feature: I loved it and I'd like it back!

I'm sure you'll be treated to other suggestions, but... You don't need a KML...a GPX route is fine. I use Google Maps to create a route of up to 25 stops and then GMapToGPX to create a GPX file from that. (But I don't want to minimize your loss...if all of the 200 didn't post we couldn't have judged how [in]valid that number was.) Thanks for this tip about GMapToGPX . It doesn't solve all of the problems and worries mentioned in this thread, but it's a very useful tool that I hadn't heard of before. One big advantage of using Google Maps (rather than GE) to build a route is the ability to manually change the route by dragging the line around. For example, if you want to go from Orlando to Miami via Tampa (which is not the direct route), you can just use the mouse to drag the suggested route so that it goes through Tampa. Then use GMapToGPX to save the altered route and use that as the basis for your PQ.

Your assumption is that 'everybody' or even 'a lot' of people use GE...I think that is a mistaken idea. Careful. I didn't write either of the words that you placed quotes around, and those aren't really my assumptions. What I meant to emphasize was something technical that might be important. For anyone who ever clicked the option on the profile page to use the KML add-in, the add-in became one of the saved "my places" in GE. So after that first time, many of those users were using the add-in and the database every time that they ran GE, whether they were using it consciously or not. It's pretty easy to believe that could cause a heavy load on the database, but it's hard for me to believe that it was only 200 people/day. [edited 2nd sentence for clarity]

Portugal is 1000x more important than that -- in fact about 10 million (not 10K) inhabitants. So maybe it has lots more than 200 KML GE users? On the main question, the 200 figure seemed absurdly low to me too. Especially since, after selecting the option once, many people would be using this feature every single time that they use GE.

I notice that you didn't write the TB description in German?? Depending on your browser, this might work: create a new bookmark with this in place of a URL: java script:var%20t=((window.getSelection&&window.getSelection())||(document.getSelection&&document.getSelection())||(document.selection%20&&document.selection.createRange&&document.selection.createRange().text));var%20e=(document.charset||document.characterSet);if(t!=''){location.href='http://translate.google.com/translate_t?text='+t+'&hl=en&langpair=de|en&tbb=1&ie='+e;}else{location.href='http://translate.google.com/translate?u='+escape(location.href)+'&hl=en&langpair=de|en&tbb=1&ie='+e;}; [important note: the bulletin board software seems to always insert a space after the 4th letter of the code, between 'java' and 'script', no matter how I format it here. That must be a single 10-letter word, 'javascript', when you create the bookmark.] Clicking that bookmark should then translate the entire web page (probably quite comically...) from German to English. For example, on your Gator Bug page it produces logs like: In order for the Gator bug gets no claustrophobia, we put him out of the box much too small free :-).

Thanks, Corey. It's funny how you can look at something hundreds of times and still miss an important detail until someone else points it out. The View Map link is very similar to what I was suggesting... I just hadn't seen it because it's not up in the Options box with View in Google Earth. On the second point, I was merely trying to give an example of how the feature would look if implemented, not actually suggesting the download/upload procedure to anyone else.

A small suggestion: How about an option to view TB paths in Google Maps (GM), rather than Google Earth (GE)? Could there be a [View in Google Maps] link on the TB page? Unlike GE, a GM link doesn't require any extra software download. It also opens much more quickly because there's no new program to run. This option would make the TB pages consistent with the cache pages, which now use GM. The GM view looks pretty good, because the text of the TB description is visible in the left-hand window. Here's an example. I just saved the GE version of a travel bug's path into a .kmz file and then re-opened it in GM. There might be better choices for colors, sorting, etc. but it looks nice to me.

Nobody made that claim. Right. All I meant was that I don't believe that all cache pages are equally important to read.

Your "cache globally" signature line makes an interesting combination with your admonition that one should always read the cache page. There are lots of global cache pages that I can't read, which is part of why I made the suggestion. I agree: when possible, it's always a good idea to read the cache page before a hunt. I also completely agree that if trouble ensues from failure to read the cache page, that's entirely the seeker's fault. But I don't believe that all cache pages are equally important to read. Giving seekers the ability to filter out from PQs caches that truly require careful reading (because of special local rules, promises that the hider made to someone granting permission, special equipment needed by seekers, etc.) could be a net benefit. Edit: What about a "Special Requirements" attribute? Maybe that's a middle ground that would signal that it's particularly important to read the cache description, without implying that it's OK to search without reading?

Thanks, but of course I already knew about that filter . Try it on this cache page or this one. It might be nice to know whether one does or doesn't have a chance of finding these from the PQ coordinates only, because that the only information some cachers would have. Edit: Sorry, Prime Suspect, I didn't read your post carefully enough. My worry includes the fact that even on traditionals there is sometimes important extra information that is vital for the search -- either for finding the cache, or for searching safely and appropriately. If I will be searching only from the PQ coordinates or other cryptic information, I might want to filter those out of a PQ.

Using it for filtering PQs is exactly what I meant, although maybe that wasn't very clear. Say you're traveling in an unfamiliar spot. Maybe you don't even speak the local language, so that looking at cache listings for warnings and such isn't really very helpful anyway. You would run a PQ and filter out all the caches with this new "You really & truly have to look at the cache page" attribute. Hopefully that would keep you having fun and out of trouble.

I know what you mean, but it's just a fact of life that lots of people aren't reading cache listings. That sometimes leads to frustration or even danger. I agree that it's completely my fault when there's a problem because I haven't read the listing, but having an attribute like this might make those problems less frequent.

Many people search from PQs without ever looking at cache listings. That creates at least two kinds of problems: Sometimes seekers can't find the cache with only the PQ information. That's true for most puzzles, of course. But there are also many traditional caches with vital extra information in the Short or Long descriptions. Occasionally after a long hunt for an unfamiliar cache that I loaded from a PQ, I learn that there was something on the cache page that I really needed to know. Sometimes hiders want to add important information for which there isn't a standard attribute. For example, 'Do not enter from Hwy 18. You must use the park entrance,' or 'The property owner gave permission to hunt this only 8am-5pm', or 'After publication, I moved the cache to a safer spot 100' NNE of the posted coordinates', or 'Beware of the [insert special danger here...]'. This isn't a fully worked-out idea, but I wonder if we could have an attribute for "Vital Information on Cache Page", maybe with an exclamation point as the icon. That would allow filtering and flagging of these kinds of caches, and maybe increase the fun and safety of caching in general.

Adding another: If you don't like folks finding your puzzles & multis without going thru the same steps you did, don't hide them. Once a puzzle or multi has been found/solved by a single person, it's possible to have your final found by methods outside your control. The most productive thing we as cache owners can do decide how we're going to feel about it. We can be "outraged", if we wish. I've been outraged in the past, and it's not an emotion I care to feel again, if I don't have to. Post script: Flask, I love the ESP ALR idea. CR, you're absolutely right. I am slightly less outraged already, and calming down fast. ...it's just a game...it's just a game...it's just a game...

If you don't like long hikes, don't seek caches that involve long hikes. If you don't like boats, don't seek caches that require boats. If you don't like solving puzzles at home, don't seek puzzle caches that you have to solve at home. A geocacher has no more right to find all the puzzle caches in their area than they do all the boat/scuba/ski/caving/snowmobile/whatever caches. The fact that it's easy to cheat on this one kind doesn't make it ok.

Three very different caching experiences: FLORIDA (Bear of a Crossing, west of Tallahassee) GERMANY (Errinerung an die Jahrhundertflut 2002, on a bridge in Dresden) MONTANA (Holland Falls, Swan River Valley north of Missoula)

To break the tension, how about a _robot vs. ROBOT cache, like this?

I use a lot, just for irony. (I live in Florida.)

Aha! That's a good clue. I was having upload trouble with a KML file created from Google Maps. (the procedure is: get directions; modify route manually; add &output=kml to the end of the URL; save resulting file). I just did an experiment with a route from the White House to Gettysburg. Here is KML file M, straight from Google Maps. Here is KML file E, which I got by opening file M in Google Earth and then doing a "Save as KML". That is, E is just a version of M that I filtered through Google Earth. If I browse and select file M, absolutely nothing happens when I click [upload]. On the other hand, if I browse and select file E, everything works normally and I can build the PQ. I don't know what subtle difference is causing the two very similar KML files to behave differently, but maybe this is a good clue about the problems that some folks are having.