PQ Splitter exceeds 1000 caches in each PQ

Question

When I use the PQ Splitter to give me a PQ for all caches in Troms og Finnmark, the PQ Splitter says that the first PQ should have 989 caches in it.  But when I set the PQ up and run it on geocaching.com it says that the PQ exceeds 1000 caches.  The PQ splitter has worked great before, but now it don't.  Is anyone else seeing this problem and can it be fixed?

Comments

What are you're actual settings for the PQ splitter-tool and the PQ itself? There's been a couple of bug reports for this tool where the error has been that the user didn't use the exact same settings in the splitter tool and the PQ. Sometimes a small difference can be hard to find so it might help that somebody else takes a look at it. :)

Edit: Converting this to a comment since this doesn't seem to be the issue.

---

In the splitter tool I ask for PQ's for Troms og Finnmark (state/provinces colum), no filter added.  So it should give me all caches and events in Troms og Finnmark.

In my PQ at geocaching.com I ask it to get caches from Troms og Finnmark (in the States / Provinces  setting) I ask for any type and any container. I have Within a Radius of to 100 mi and the date for the first PQ is set to August 10 2001 to May 7 2013 as the PQ splitter says.  

The PQ splitter says the PQ should contain 989 caches, but the PQ at geocaching.com says it has 1000 caches.

---

Hrm, interesting. I tried to find the mismatch with some searches but I came up empty. So I can reproduce your issue, but it annoys me that I can't figure out what the PQ-splitter is missing. :) I'll leave my searches here to make it easier to trouble shoot this.

Geocaching.com search for Troms og Finnmark, caches placed before 2013-05-07 gives 1001 caches.
Project-GCs MapCompare for Troms og Finnmark, caches placed before 2013-05-07 including disabled gives 1003 caches.

So, looks like 2 caches have been archived that Project-GC doesn't know about yet. None of this explains why the PQ splitter would say there's 989 caches in that span tho. I assumed the issue would be that a CO have selected the wrong region on a series of caches (common issue), but I can't find any cache that supports that. I can't find that any of the caches have been archived and unarchived.

Checking the numbers for the whole area the PQ-splitter says 8468 caches, Project-GC's Caches Per Area says 8504, Geocaching.com says 8504. That's a bit to big of a difference to make sense. It's also not that newer caches have not been picked up yet because running a search for caches placed after 3 November 2020 gives 630 caches on Geocaching.com, same number as the last PQ in the PQ-splitter.

Now I'm curious about the issue so I hope it can be looked into. :)

---

Thank you for looking in to it.  Crossing my fingers that someone can look into this and find a solution for this.

Answer 1

For some reason there are quite a few geocaches in Norway that has changed region lately. GCXKXW is such example. It's an interesting example since the CO hasn't been logged in for 10 years. But Project-GC's data says that Geocaching.com had it in Nordland, though it's now in Troms og Finnmark on Geocaching.com as well. Project-GC's data is out of sync, which is natural on such old geocaches when they don't receive any logs. This is one of the reasons PGC creates date intervals with <= 990 and not =1000.

This is a complete list of gc-codes that differed between Project-GC's PQ splitter and the Pocket query tool:

• -GC1FY0V
• +GC3G138
• +GC3R224
• -GC3VC5C
• +GC481DD
• +GCXDRZ
• +GCXHP6
• +GCXHP8
• +GCXHPB
• +GCXHPD
• +GCXKXW
• +GCXKY3
• +GCXKY9
• +GCXP74
• +GCXZ1Y

Prefixed with plus sign matches with PQ only, prefixed with minus matches with Project-GC's PQ splitter only.

Since the first mentioned geocache has changed without CO being active we can only assume HQ has done something here. We'll update data for all Norwegian geocaches to counter this. It will probably take a day or two.

Comments

Thank you for looking into this and finding the problem.  
I will try a new PQ in a few days to see if the problem is fixed then.

Thanks again :)

---

Over 10% of the refreshing of data is already done, in ~30 minutes. So might work as it should tomorrow morning actually.

---

Thanks for the information.  I can try it again tomorrow then and if it doesn't work tomorrow, I'll try on Tuesday