WascoZooKeeper

I got 101 results for this route as well. Raine seems to think it has something to do with the route not following an actual road and going off into the water. Does Jholly's route deliver? That's possible, I suppose, but the question is, did you change something between 6/19 and 6/26 that would cause that to matter? Jholly's route is close but still seems to have some discrepancies. I'm fooling around with some alternative routes that will provide the right coverage.

I've made my original route public, too -- it's named just "Whidbey Island". Creating a PQ on that route with a distance of 5 miles on either side returns a total of 101 caches, which is what I've been getting in my weekly PQ since 6/26. Others can see if they get the same result.

Here are the locations of the 71 caches that are missing from the query result. (The count may be off by just a few depending on any new or archived caches since 6/19).

Results by a cacher I know in another forum:

No, I don't have any GreaseMonkey scripts loaded. I also logged in under another account that I have, using Internet Explorer instead of Firefox, and encountered the very same problem there.

OTOH, would 10km from your home even reach outside BC at all? If not, don't even bother to specify BC as a requirement.

gc.com used to use TidyHTML to "clean up" code and suppress certain tags which they did not want to allow. As far as I know, they still do this. This process will reformat your code and make changes to some of it. It can be very frustrating, but there's not much you can do except learn to live with what it changes.

First of all, when you delete a query, it will appear crossed out, but then it will disappear from your list after 24 hours or so. That gives you a chance to grab a copy of it if you deleted it by mistake. I don't think you can "undelete" it, but you can use the "copy" selection to copy it over as "Copy of <query name>". When you get zero caches in your result, a very likely cause is that you specified mutually exclusive parameters. For example, some people will check off both "I haven't found" and "I have found", thinking that this will give them all the caches they haven't found PLUS all the caches they have found. But that's not how that section works. You have to consider each of the checked conditions as applying simultaneously to EACH of the caches that might be a candidate for your results. It's impossible for any given cache to be BOTH "found" and "not found", so if you check both of those boxes you will always get zero results. Without knowing your home coordinates, I couldn't tell you how many you should be receiving. But when I ran a PQ with the conditions you specified, but using postal code V0S 1N0 as the center point, I received 32 caches in the result.

No, the preview also only gave me 101 caches. Here's some more info. My original query, with the original route, worked fine until 6/19/09, and returned about 280 +/- caches. Sometime during the next seven days, something went wrong, because the next time the query ran on 6/26, it returned only about 101 caches. Ever since then, the original query has returned only about 101 caches -- it may have varied a few in either direction with new/archived caches. This morning I created a new route, using the gc.com route tool, and added some zig-zags in to make sure I got complete coverage. These two pictures give you a pretty complete view of the route -- it's called "Whidbey/Fidalgo", and I made it public. A query built on that route now gives me 194 caches -- better, but still not complete. So I took my three query results and mapped them out with Microsoft Streets & Trips. In the following picture, the blue squares are caches that were returned by my original query on 6/19, the white circles are those returned since 6/26, and the red dots are those returned by the new query I built on the new route this morning. Pretty much all the points ought to show a red dot on a white circle on a blue square. A blue square all by itself means that my original query returned that cache on 6/19 and earlier, but neither my original query nor my new one returns that cache now. Some of those are outliers in my original query -- over on the Olympic Peninsula and Camano Island -- so I'm not worried about them not showing up in my new query. But they all ought to have both a blue square and a white circle. The lone blue square just to the NE of the "d" in "Puget Sound" is GC1HA23, which is temporarily disabled -- so it ought to show up, since I'm not filtering out disabled caches. The lone blue square due west of "Swinomish I.R." is GCNR2G, which is also disabled. The lone blue square just SW of "Swinomish I.R." is GCQQB7, another disabled cache -- so maybe that gives you a hint. But there's also that huge cluster of blue squares at the very north end -- those are not all disabled caches. The blue squares with red dots mean they were returned my original query on 6/19, and are also returned by my new query, but are not presently being returned by my original query. There's a huge cluster of those due west of Coupeville, and another cluster at the north end of the islands, and then a large number scattered around at the southeast end of the islands. And then there are the blue squares with white circles. Those are ones that were returned by my original query on 6/19 and are still returned by that query today -- but are not returned by my new query. The ones that are outliers don't concern me -- over by Port Townsend Bay and at the south end of Swinomish I.R. But there are quite a few on Fidalgo Island itself which ought to be showing up with red dots. And here's one more interesting case. This picture shows two locations at the southeast end of Whidbey where the new query (red dots) is missing caches even though it's returning other caches very near by. GC1NQKH is disabled, but GC1MGA8 is not.

I know I saw a thread about this some time back, but couldn't locate it now when I searched. So, my apologies if this is a duplicate, and the mods are welcome to merge this into another thread or point to the right place and lock this if appropriate. I am trying to get a PQ of all the caches on Whidbey Island and Fidalgo Island in Washington. So I built a route that looks like this: I know there are somewhere in the vicinity of 270 +/- caches on those two islands, but the PQ is only returning 101 caches. On the following map, the red dots are the caches returned by the query; the yellow dots are caches that have previously been identified, but are currently not returned by the PQ. For the benefit of the lackeys, the query I'm running is named "WA-Whidbey Island". FYI, I deleted the query of that name, which had been giving me the abbreviated results, and recreated it using the same route, just in case there was a problem with the query. But after re-creating it, I got the same result.

Mournful lament about how the sport of geocaching is being ruined by people who don't adhere to my particular standards. Gratuitous swipe at Jeremy and the lackey reviewers for selling out to commercialism instead of upholding the integrity of the game. Vague hint of geocide.

Entering personal information on an unsecured web page??? :laughing: No, I don't think so . . . .

Can you say, "TOS Violation?"

Well, I guess that's kind of my point. If a note had been sent to the coin owner (me) and/or the cache owner, they might have learned something new -- namely, that they are able to mark a trackable item as "missing". If a reviewer just does it themselves, then obviously the same end result occurs, but without the potential "learning opportunity". I already knew about that, as I noted, so I was mainly wondering whether this was a new task the reviewers were taking on more generally. Maybe there have been a lot of complaints about cache owners and trackable owners NOT marking items as missing, even after having been notified? So the reviewers are being even nicer guys (and gals) than usual (note blatant reviewer suck-up ) and helping people avoid wild-goose chases?

So, is this something new that reviewers are doing? I'm not complaining about the coin be marked as missing; if I'd known about it, I would have done so myself, but the last log I got on the coin was when it was dropped in the cache in August. Every now and then I check up on all my trackables that haven't moved in six months or so, and if I find logs on the cache pages that say they're not where they're supposed to be, I mark them missing. And there's only a single log that reports the coin as missing, so it's not like there's been a steady stream of logs mentioning a missing coin. And that single log was made just a few days after the coin was dropped. Since I'm not watching that cache, I wouldn't have received that log. It just seems weird that a reviewer would do that based on a single, 3-month-old log. I'm assuming someone contacted him or her, but I would have thought that the reviewer would have either told that person to contact the cache owner and/or coin owner, or the reviewer would have forwarded the information to me and/or the cache owner. Just curious. Maybe I'll drop a note to the reviewer, too -- not to complain, but just to satisfy my curiosity as to what prompted this.

Wow, not exactly the best attitude if you want them to work with you to resolve any issues and get your caches listed.

You can't do it yourself, but send a PM to a moderator asking nicely and they'll probably help you out.

A picture of a person's face at the cache site only proves that somebody was at that location sometime. How do you know it's me, if you've never met me? Even if you know it's me, how do you know it's not a picture from my vacation three years ago? If a picture is a requirement, then it should be clearly stated on the cache page, and if there are specific requirements for what should be in the picture, you should state that, too. And if you intend to delete logs without pictures, then your enforcement should be in days or weeks, not months or years. The whole log deletion game seems silly to me, anyway, for just about any cache. If someone wants to claim they went to a place they really didn't go, why should I care? The only exceptions I might make would be if the log were in bad taste (offensive, vulgar, crude, threatening), or if the presence or content of the log might somehow be misleading to other cachers.

Mournful lament about how the sport of geocaching is being ruined by people who don't adhere to my particular standards. Gratuitous swipe at Jeremy and the lackey reviewers for selling out to commercialism instead of upholding the integrity of the game. Vague hint of geocide.

Welcome to PilotMike's Forum!! <note: insert tongue firmly in cheek before reading> (Note: NO OFFENSE INTENDED. I was just having some fun with the blog analogy. If you'd like your logs presented in a different order, you have as much right to ask for it as I have to say it's OK as is.)

I'm quite happy with it the way it is. It's just like reading a blog -- the most current day is at the top of the page, the least current day is at the end of the page. Within each day, you read from the top down. If I want to use the "My Account" page to review what I did on one of the past thirty days, I find it MUCH easier to find the date in question and then read down the page, just like I would read anything else. If anything, I'd vote for a blank line on a date break -- but that's so trivial, I'm sure I could come up with at least a dozen other things I'd rather see first.

I can't imagine why anyone would upload My Finds more than once a week, since they can't get a new one more frequently. It's not hard to add entries to the file.

I wouldn't mind seeing some kind of throttling mechanism, much like the "My Finds" PQ which you can only run once a week. Maybe limit the stats to once a week, too. I'd be curious to see some kind of figures as to how frequently some of them get updated. I'd bet the 80-20 rule applies -- 80% of the load is generated by 20% of the users.

Briansnat feels so strongly about this, he took time out from his presidential campaign to post.