Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Posts posted by Urubu

  1. Here is a cache on a ferry. You have about four minutes to find the cache, sign the log, and replace the cache before getting to the other side of the river.


    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 .

  2. So, I've noticed that these days most logs are copy and paste or "Found it TFTC" So let's put an end to this! How about logs must be at least 250 characters, and you can't write the same log twice in one day.



  3. Okay folks, I think I've figured something out. Tolerate my thinking here if you will.


    [...a detailed set of instructions for searching using the existing Map It feature over and over with different searches]


    In conclusion, on the last list you pulled up, just below the "Map It" box, using a red pencil, write the words "Send KML"




    Now, if you press that little red "Send KML" box, it will open all those caches in Google Earth on your computer.



    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.

  4. I'm heading out to a bookstore, preferably Chapters. I'd like to grab a cache or two in the neighbourhood. So I fire up GE, search on Chapters (immediate results) and, with the GC KML loaded, look at the neighbourhood caches deciding which to target. Elapsed time to cache perusal: less than 1 minute.


    Can anybody tell me how I'll do this once I can no longer see all the caches in GE?


    Surely you won't say this:

    1. Determine the address of ONE POSSIBLE book store
    2. Create a PQ based on that address
    3. Wait, sometimes 2-3 hours, for the PQ results to be emailed
    4. Load the PQ into GE
    5. Repeat for other candidate bookstores


    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! :D

  5. :sad:

    why is the "Caches along a route" feature still active?

    You need to use a KML file to create a route to find caches while traveling.

    You can't expect us to just use already created routes with such descriptive names as "My home to the cabin".


    Is there any other way to find caches while traveling except downloading an entire state (or states) and using GSAK?


    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.


    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.

    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]

  7. Only 200 users?


    I beg your pardon, but I strongly believe that here in Portugal, an "insignificant" country with "just" 10k inhabitants, there may be more than those pesky 200 kml GE users.



    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? :unsure:


    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.

  8. 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 :-).


  9. Two easier ways to view the path in Google Maps:
    • Use the View Map link (after the words "Tracking History") from the Travel Bug's page.
      This gives you an embedded map, and cache names will be shown as title text when you mouseover the numbered icons.
    • No need to download and re-upload the KML file, just copy the link and paste that into the Google Maps search box, like this.


    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.

  10. 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.

  11. Nearly every cache page has vital, interesting or necessary information.

    If you choose not to read, you do so at your own peril.

    Adding an icon or attribute will not teach the lesson that is needed.


    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?


    Only with Traditional caches can one assume that no other information is needed to find it. With any other type, you are expected to read the cache page. There's your filter.


    Thanks, but of course I already knew about that filter :unsure: . 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.

  13. It may be the set up I'm using,? but I don't see attributes coming with the .gpx anyway?

    I dump files into GSAK, and then create .gpx for Garmin, .upt for a Magi and a .pdb file for Cachemate. Attributes don't seem to be in any of those.


    As I say, this may be my ignorance.


    A "you should read page attribute" might be used by some pure numbers runners to filter out caches in the PQ itself. I always filter for NO stealth when I run any 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.

  14. I'm not trying to flame here, but if someone has trouble with a cache because they neglected to read the description, I'd say they brought it upon themselves. :yikes:


    I'd put this attribute on ALL of my caches, because I think it's important to always take a look at the description first. Often when I haven't done so, I later wished that I had.


    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.

  15. Many people search from PQs without ever looking at cache listings. That creates at least two kinds of problems:

    1. 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.
    2. 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.

    • 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.

    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. :laughing:


    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... :laughing:

    • 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.

  16. I still have the problem if I use a .kml file created by anything other than Google Eart or Mapsource.


    If I use one of those, I can upload with no problem. Not sure why nothing else works.


    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.

  • Create New...