Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Posts posted by shunra

  1. Two new Google Map features have been added. This is the place to discuss the new features. I'll follow up with a larger announcement in the announcements section of the forums.


    Sali. i finges eh [removed].... die nöie chartä si eh für nüt......

    entweder mapquest oder de lasches besser la si! laschi lusche!

    me seit, oder nid.....


    Ja los jitz also emal... das isch aber a sehr uhn"uanci"arti meinig, nid?

    (eggsg"usi, i han ekei umlaut uf dem kompjuter)

  2. The Barnabirdy(s) and I recently toured the Olympic Peninsula. The northwestern tip - including Neah Bay and Cape Flattery - is on the Makah Indian Reservation, and entry requires a $10 Recreational Use Permit.


    The Permit is good for all of 2006, but we are unlikely to need it again, so Mr Birdy suggested I make it available to any local cachers who might plan to visit that area, to save you the cost. Isn't he nice?


    So, if you'd like to borrow it, email me and we can arrange a hand-off. It's a loaner, so you'll need to return it to me so I have it available for the next person. We are also 'logging' the back side of it, just for fun.


    Hey, why don't you turn it into a Travel bug, with explicit instructions that it is supposed to stay in that area?

  3. I like the interactivity of the maps on the cache page a lot, but I haven't found the map you get to when you click on it very useful for trip-planning purposes. I hope the Google Maps won't replace the GeoMicro maps on the geocaching.com maps page before the functionality of GeoMicro is achieved or exceeded.


    The randomness is very annoying: I keep seeing caches I found years ago, but not some of the ones I haven't found yet.


    Also, those pins are huge, and obscure big parts of the map. I'd like to see them reduced to little boxes, like on the GeoMicro maps.

  4. Two comments:


    1 - Earth caches don't show. They appear in the list of caches on the side, and on the map you can see the shadow of the pin, but the pin that casts that shadow isn't there. Spooky!


    2 - I love the fact that you can click any point in the map, and then drag the cursor all across the screen even beyond the limit of the map, and see the map shifting along.


    I liked the old maps better as such, but I appreciate the interactive functionality of the Google maps. Thanks!



  5. When two caches are in the same area and if I haven't yet found either of them, I don't see the point of a PQ showing only one of those caches, just because it is new.

    Just because it doesn't benefit you, doesn't mean it isn't beneficial. As the forum regulars are very fond of saying, everybody plays this game differently.


    If you are a FTF nut, there's the insta-notify.

    If you are looking for a FTF on a cache that no one else has found, you are correct - there is a function of "has not been found" in the PQ.


    But neither of these are what was being addressed by the original post. The OP goes to the State page and sees the caches on that list that are "newest" and wants to see if they are close. My suggestion was that instead of looking at the newest caches in the state and trying to see if it was close to you, set up a pocket query to grab caches that are close to you and show you the newest. It seems like semantics, but it's not. It's a more efficient way of querying the database, and getting precisely the results you like.


    Consider these two images:



    On the method to the left, you're actually getting the results of ALL of the caches in the state, and then (if there were the direction and distance from home mark) deciding if the cache is near your home or not. Whereas the one on the right, the database is determining that the caches in your result are not only near you, but also new, and therefore giving you PRECISELY what you are looking for.


    Couple that with the fact that if you don't like Multi-stage caches or Puzzles, or don't want to find micros, you can eliminate those with the Pocket Query. Also - if you have more than one "home" coordinate (office, vacation home, etc.), you can set up multiple Pocket Queries to get information from the database.


    But many people think that PQs are just for getting information mailed to them. They miss the fact that you can set up the criteria and NEVER run the query, but instead use the Preview function.


    Let's make sure that everyone understands this:

    4leafclover's profile says s/he lives in Cincinnati, OH. Right there, there's a problem. Cincinnati is on the border with Ohio, Kentucky and Indiana. If 4leafclover uses the state method, s/he would first have to pull up each state separate, disregard future event caches, and then start looking at each individual cache to determine if it is near his one set of home coordinates. If 4leafclover also works in Oxford, OH, - some 30 northwest, s/he's out of luck, as the state result would only show the distance from the one set of home coordiantes.


    Using the PQ method, 4leafclover could set a PQ for all 500 caches placed within the last week centered around 39.40506, -87.5042 for a range of say 50 miles. Then all s/he would have to do is


    that to get a list of new caches that are in Ohio, Kentucky and Indiana. If s/he wanted to do the same thing with Oxford, OH, just use 39.51044, -84.74242 as the center. If 4leafclover doesn't like puzzle caches and micros, eliminate them from the PQ. Events don't have to show up either.


    The point of this long rant is that while it would be NICE to have the distance and direction on the state result page, the pocket query method is much more efficient for finding the newest caches near your home coordinates.


    I'm not sure what you're disagreeing with, Markwell... of course everybody place the game in a different way!

    And yes, I have the previews of the 3 GC-PQs I like to look at bookmarked in my browser.

  6. Pretty cool idea. Since the coding is there already for some of the other results, this shouldn't be TOO hard to implement.


    Of course, since you are a premium member, you can set up a Pocket Query for new caches in your state ("placed in the last week") or else build a radius and get new caches placed in the last week. Then you can preview that query any time you want and get the right search.


    When two caches are in the same area and if I haven't yet found either of them, I don't see the point of a PQ showing only one of those caches, just because it is new.


    However, I have an "FTF Wannabees" PQ bookmarked, which lists any caches that NOBODY has found yet. New caches stay on it for a few hours, if they are hard puzzles they might last a few days, and if they are up in the mountains or require a boat, weeks or even months.


    I live beyond the end of nowhere on the tip of a peninsula, so I hardly get to dash off to one of those new caches and claim an FTF, but I enjoy watching the competition :-)

  7. In addition to the problems mentioned by others (which I have too):


    When I look at a bookmark list, and set it to show me 50 results, and then I do a manipulation (edit or delete an entry), not only will the page afterwards show me the 10 first results only (requiring me to switch back to 50 and then move to the correct page), but it will SAY that it is showing me 50 results, when it is showing me only 10. It is then impossible for me to click on 50 and go to the 50 result view, but I have to select another quantity first (25, or 10), and only THEN I can go to the 50 result page again, which I had never waqnted to leave in the first place.


    I can understand that the limit to 50 result vies max serves some purpose, perhaps, but the inability to show the list properly can serve no purpose whatsoever, and is clearly a bug.


    I'd be happy to have only one display option: the entire bookmark list at once.

  8. I often look for caches along my route when I trave in the state map pages. I zoom into the route, find a cache, and identify it. I then click on the link for that cache below to go to the cache page and print it if I have not found it. I am having a hard time keeping track of the ones I have found. Is there a way to know if I have done this cache without scrolling down to see my log or going back to the search for cache page and seeing my check mark next to the cache in the list? It would be nice if that check mark that shows that I have done a cache showed up when I open the cache listing.


    On the cache page, click on "Nearby caches that I haven't found". If the cache you were looking a appears at the top of the list, you haven't found it yet. :blink:

  9. We are taking about replacing the current "FROM ORIGIN" area of the Pocket Query engine I assume.

    I think the suggestions in that direction are impractical, for various reasons. And they involve a far more significant change than necessary.


    The PQs can stay as they are, with the existing 'from origin' options. No need for change at all. The only addition would be the possibility - not a requirement - to limit the results in one or several directions. Nothing more.


    Personally, I am not sure I would use that option in order to create boxes, but I might. I would, however, use it in order to stop using different queries for "caching grounds" to the NE, SE, S and W of me, but just use this one query from my home coords, limiting the results this way or that way (and automatically expanding the search radius in the desired direction), as the case may be.

  10. I have that problem too.


    I was working on a route I am doing saturday and when I tried to check on gc.com/maps it wasn't showing any caches.


    It was working fine the day before that but yesterday when I tried to see the caches....nothing.


    Same here. The red checkmarks are updated after 17 days, and now the other caches are invisible...

  11. I think my suggestion was very intuitive. Just add these fields to the PQ form:


    [ ] do not include caches North of ______

    [ ] do not include caches South of ______

    [ ] do not include caches East of ______

    [ ] do not include caches West of ______



    Personally I find the 'do not include caches...' a bit backwards, I would rather see:


    [ ] only include caches North of ______

    [ ] only include caches South of ______

    [ ] only include caches East of ______

    [ ] only include caches West of ______


    Maybe something like:




    You're right about the backward thing, but I phrased it that way because it would be in line with similar phrasings in the PQs, such as: "I do not own" and "I have not found". But I don't feel strongly about that either way.


    I reject a key element of your graphic suggestion, though. The way you represent it requires that a user make a choice between a center of a radius (GC####, center of ZIP, or coords) and a rectangle. Moreover, it forces one to actually choose a rectangle, and doesn't allow for the option to ignore only caches North of a certain latitude, for instance, but accept caches radially in other directions. Third: it does not allow for choosing a focal point, for the event that the chosen rectangle would contain more than 500 caches.


    All these consequences of your design would be too far-reaching. A focal point or center of radius (GC####, center of ZIP, or coords) will always be necessary, and limitations in various directions would be additional optional enhancements, whereby choosing any or all of them would not go at the expense of anything that we have today, including focal points.

  12. The PQ code can already do this internally. If anyone has any ideas for making the insertion of these points intuitive on the PQ page, let me know.




    I think my suggestion was very intuitive. Just add these fields to the PQ form:


    [ ] do not include caches North of ______

    [ ] do not include caches South of ______

    [ ] do not include caches East of ______

    [ ] do not include caches West of ______


    I don't know much about programming, but this should not be difficult to implement, I think...


    Any and/or all of these four lines could be used or ignored.


    It is true that a box can be defined by its diagonal points as well, but that would be less intuitive, AND limit searches to true boxes only.


    Thanks for considering!

  13. It has never been instantaneous, for all I know, but it used to be once every 24 hours, and when it occasionally didn't happen, Jeremy would apologize for the server hiccup, and fix it right away. That was good enough for me.


    Updating the maps is important not only because of the checkmarks, but also because archived caches still appear, and new caches don't.


    Jeremy, it's been two weeks again... Could you update the maps, either manually or by programming a computer to do it for you? :-)



  14. Blue Q,


    No intent to argue on my part, but the addition of the simple option in the PQ form would allow for round, box, or combined results, and should technically be very simple to implement.


    Nobody will need to second-guess what users might want, since users will just get what they themselves want.

  15. While being able to set up PQs to use a grid instead of a circle would certainly facilitate finding caches along a route, the main thing (to me, at least) is that it allows you to cover an area without overlap.

    I discuss the various options in this post. It's not quite as simple as just making a bounding box, because Jeremy has said that he always wants to be able to limit the total number of caches returned in a PQ. Your idea is the "rectangular" query, which, even though it could lose caches at the corners if the rectangle is too big, is still far more efficient than a circular query. It looks like this:




    I think it would be a great option.


    Fizzy, I think that is an excellent idea. I suppose that all it would require would be 4 check boxes in the PQ field:

    [ ] do not include caches North of ______

    [ ] do not include caches South of ______

    [ ] do not include caches East of ______

    [ ] do not include caches West of ______


    Those could be optional boxes, so people who don't want to use it wouldn't need to. However, because it eliminates overlap, it would reduce stress on Groundspeak servers.

  • Create New...