Jump to content

marking a cache so it does not show on 'nearest' list


sbell111

Recommended Posts

I like the way cache's that I have found go to the bottom of the page, but it should go beyond that. I would prefer an option to take them completely OFF.

 

It should be the 25 closest cache's that I can actually find. Ones I have already found should be on a separate list or page - I see no reason for having them on the same one.

 

I see no reason to list unavailable caches at all. What's the point?

Link to comment

There are many reasons, but one is that some benchmarks near me are in really bad neighborhoods. I'd love to be able to selectively hide them from lists.

 

--

"The government inspection department Stash Hunt is open for everyone with a government inspection department and something sense for adventures."

Link to comment

Great Idea, highly in favor of it being for Charter Memebers, anything that improves productivity is great to use as an incentive.

 

Where we live (Mid Vancouver Island), within 100 miles we have, Not quite the end of the Island to the North, the South tip of the Island, The Lower Mainland (a $100 Round trip ferry ride), Northern Washington State (also a $100 Ferry Round trip with a border crossing), Some North Mainland stuff that's very difficult to get there.

 

We need to be able "ignore", but then if we are going on a trip to the Mainland or Washington, have the ability to turn them on (like show archived on the my cache page)

 

A drop down list may work even better, with a choice to ignore, hunt (moves to top of list) and any other option you all can think of...cause I know you can...

 

Keep yer sail 'igh, 'nd move swiftly,

:smile: Captain No Beard and the Pi Rats

Link to comment

Rest assured, Mitsuko, this site and our fine friends at Groundspeak aren't going anywhere. Even if they did, you would no doubt get a pro-rated refund.

 

The yearly rate saves you $6, so go ahead and pony it up - you won't be sorry.

 

-

Link to comment

I think this is a very good suggestion to revive again. I cast my vote for an

-ignore- option on one’s nearest cache list. In my local area there are those that I will never do. Not knocking them (biting tongue)….just not my type. Problem is they are starting to outnumber the closer caches that I would consider doing. Not having to wade through them….would be a blessing. Perhaps it could be done in a similar manner as the -My Cache Watch List- only of course, would be -My Cache Ignore List-.

 

Please chime in on this one if you agree. Perhaps the -Powers That Be- will make it so.

 

Imagine a world….where every cache on your Nearest Cache List is one you are interested in……..imagine…..

Link to comment

I guess this thread started before Pocket Queries were available (not sure of the history there), but now they are available (to Charter members).

 

So, you can say to find nearest caches in an area that you haven't found already, and it works just dandy.

 

I love pocket queries, I think it was nicely done. Bravo, and all that.

Link to comment

The point is not just to show the caches nearest that you haven't found. There are some caches that people haven't found that they don't CHOOSE to find (for example: a locationless cache that has coordinates 3 miles from your house). In that case, even though the cacher hasn't found the cache, they don't want it to show up on the nearest cache query.

 

Sounds reasonable given the nature of the the database already having a profile for each member.

 

Markwell

Chicago Geocaching

Link to comment

quote:
Originally posted by PuzzleBug:

I guess this thread started before Pocket Queries were available (not sure of the history there), but now they are available (to Charter members).

 

So, you can say to find nearest caches in an area that you haven't found already, and it works just dandy.

 

I love pocket queries, I think it was nicely done. Bravo, and all that.


 

If the Pocket Queries could be done REAL TIME, like the "Nearest Geocaches" page, they would be a LOT more useful.

 

I also wish we had an "ignore" button.

 

25021_1200.gif

Link to comment

quote:
Originally posted by datum:

Those being in their own separated area (i.e. Benchmarks) would do a lot to cut down on the clutter. This would not eliminate the need for an ignore feature but might help cutting down some of the chaff.


 

All caches should be listed by their own category (traditional, multi, locationless, virtual, event, webcam etc.) which is selectable by a pull down menu.

"All" should be one of the choices in the menu as well.

Link to comment

quote:
Originally posted by dinoprophet:

I'm probably a rare case, but I keep two accounts -- one for my solo finds and one for my family. I'd like it if each with account, I could ignore caches found under the other.


 

I've heard of a number of people that do this. One person even has an account for the dog.

 

Also, this would be handy if you hid a cache in partnership with another cacher.

Link to comment

Putting in my $0.02 worth just to get this back to the top of the list. I'm all for an ignore option.

 

I'm starting to get caches from across Lake Erie popping up my nearest list. No offense to my friends in Ontario, but it's a real pain to cache there from here. Now if the US and Canadian authorities could ever get their acts together and establish regular ferry service, we'd be in business. I can reach several dozen caches in West Virginia for a much shorter drive.

 

I've also got a few others that I've chosen not to go after, for various reasons.

 

Set it up like the watch list. Then I can selectively add or remove caches from the ignore list.

 

Now where did I park my car??????? monkes.gif

Link to comment

I'm pretty sure you can do the above with the Pocket Queries. It gives incentive to active cachers to pay for a charter account by NOT making the 'Nearest Geocache(s)' search very robust.

 

You can select not to have caches show up from Canada. If you need to have the query done immediately a little trick is to select today as the day to run the query and save it. It will fire off the report *immediately*. And if you already have the waypoints in your GPS you don't need to run the query repeatedly (saves time). If you only want the new ones in the area, again Pocket Queries can do it.

 

For the most part you can get rid of (ignore) cache classes, but you cannot specify a specific cache (GC_XYZ) to ignore. For a vast majority of the users I think this is quite adequate.

 

I also don't see Groundspeak changing the 'Nearest Geocache(s)' page anytime soon since it gives people incentives to register.

Link to comment

quote:
Originally posted by RoscoP:

I also don't see Groundspeak changing the 'Nearest Geocache(s)' page anytime soon since it gives people incentives to register.


This isn't the issue. The issue is more technical than anything else. The nearest cache page is already relatively complex and places a heavy load on our database. To add this feature would mean we'd have to link to another database table that contains the cache IDs a user wants excluded. Right now, adding that additional link to an already complex query would be devastating to the performance of the nearest_cache page as well as the rest of the site.

 

I happen to think the idea of a "cache killfile" (for lack of a better term) is pretty cool. But there's no way we can add it until we develop better caching algorithms for the site to make it scalable.

 

-Elias

Link to comment

Now, I don't consider myself to be an SQL expert by any means, but I don't understand why the nearest caches query is so complex. Using the stats database, I ran the query:

 

select id,title,lat,lon,69.16*acos(((sin(3.14*lat/180))*(sin(3.14*39.18/180)))+((cos(lat*3.14/180))*(cos(3.14*39.18/180))*cos((lon+84.34)*3.14/180)))*180/3.14 as val from caches order by val limit 5g

 

which gave me:

 

| id | title | lat | lon | val |

+-------+------------------------------+-----------+------------+------------+

| 13051 | Above The Falls II | 39.1695 | -84.337633 | 0.73719160 |

| 12639 | Target #1: Madeira | 39.182717 | -84.360717 | 1.12671885 |

| 11711 | Joe "Garage"iola 2 | 39.201033 | -84.370483 | 2.18799560 |

| 13173 | Save the Universe: Air | 39.21045 | -84.3098 | 2.65641235 |

| 15749 | Stewart's Stash | 39.183117 | -84.393833 | 2.89479859 |

+-------+------------------------------+-----------+------------+------------+

 

That query may seem complex, but that's just a bit of sining and cosining in there - I wouldn't think that it would cause too much strain on things. And using proper indices and such should make it even easier.

 

But like I said, I'm not really a database expert - so if you tell me that's how you run it and that causes DB strain then I'll believe you.

 

Anyway this topic is one that interests me so I thought I'd share my 2 cents.

Link to comment

Would it be difficult to set it up so that you could go to the cache page click on log a visit but instead of logging it as found have an ignore button there? Leaving no message on the cache page, but moving it to the found list on your local cache search or by your placed caches list.

The cache would still be visible but would not be in your list of caches you haven't found in your nearest cache search.

Link to comment

quote:
Originally posted by regoarrarr:

That query may seem complex, but that's just a bit of sining and cosining in there - I wouldn't think that it would cause too much strain on things. And using proper indices and such should make it even easier.

 

But like I said, I'm not really a database expert - so if you tell me that's how you run it and that causes DB strain then I'll believe you.


You're kidding, right? Have you actually looked at the data provided on the nearest_cache page? icon_confused.gif

 

In order to provide the travelbug icon, we have to link to the travelbug table to see if any bugs are in a particular cache.

 

In order to provide the "last found" date, we link to the log table to find the date the cache was last logged.

 

If you're logged in, we also add to the query logic to find out what caches you've found so they get sorted differently on the page.

 

That's not all, either. And yes, all our tables are properly indexed.

 

In addition, the nearest_cache page is the second most popular page on the site, second only to the cache_detail page. It gets queried an average of more than 1200 times an hour - that's more than 20 times per minute just for that one page alone. And with an average result set of over 500 caches per query....

 

I've admitted in the past that part of our problem is inefficient code. We never thought about caching nor did we worry much about scalability. We're working hard to rebuild the site to improve its performance. Please be patient and trust us that we know what the problems are and how to fix them.

 

-Elias

Link to comment

quote:
Originally posted by regoarrarr:

That query may seem complex, but that's just a bit of sining and cosining in there - I wouldn't think that it would cause too much strain on things. And using proper indices and such should make it even easier.

 

But like I said, I'm not really a database expert - so if you tell me that's how you run it and that causes DB strain then I'll believe you.


You're kidding, right? Have you actually looked at the data provided on the nearest_cache page? icon_confused.gif

 

In order to provide the travelbug icon, we have to link to the travelbug table to see if any bugs are in a particular cache.

 

In order to provide the "last found" date, we link to the log table to find the date the cache was last logged.

 

If you're logged in, we also add to the query logic to find out what caches you've found so they get sorted differently on the page.

 

That's not all, either. And yes, all our tables are properly indexed.

 

In addition, the nearest_cache page is the second most popular page on the site, second only to the cache_detail page. It gets queried an average of more than 1200 times an hour - that's more than 20 times per minute just for that one page alone. And with an average result set of over 500 caches per query....

 

I've admitted in the past that part of our problem is inefficient code. We never thought about caching nor did we worry much about scalability. We're working hard to rebuild the site to improve its performance. Please be patient and trust us that we know what the problems are and how to fix them.

 

-Elias

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...