Release Notes (Website: Pocket Query API) - October 18, 2022

[+little-leggs]

The LAST FOUND , function seems to not be working as I would like , or as I used to use it ,its only showing two un found cache's ones and even and the other a trad ,
searching via the search a cache I see there a lot more than the tow shoeing in My PQ

[+Bl4ckH4wkGER]

20 hours ago, Pe_Bo said:

The "PQ preview distance column is empty" fix is probably causing a much more serious problem.

If the PQ has "From Origin -> None Selected" set (or it is a User Route PQ or Bookmark PQ which do not contain the "From Origin" option), a preview page returns "Error 500".

 

We have deployed a hot fix for this. The issue was caused by not all PQs populating the distance column. 

To clarify, PQs created with the following don't do so - both in the old and in the new experience (we verified this against the old code in a sandbox):

• PQs with "From Origin -> None Selected"
• PQs created from Lists
• PQs for caches along a route

16 hours ago, mbooda said:

The latest fix seems to have cured all the problems except one: regardless of the day of the week I pick to generate the PQ, it is generated immediately upon submission.

 

Thank you for the additional details. I was able to reproduce the issue and have created a bug ticket for us to fix.

 

1 hour ago, little-leggs said:

The LAST FOUND , function seems to not be working as I would like , or as I used to use it ,its only showing two un found cache's ones and even and the other a trad ,
searching via the search a cache I see there a lot more than the tow shoeing in My PQ

 

I'm sorry, I am unable to follow what you're describing. Please compare your report to the other reports in this thread and try again. I'd be happy to help once we have a complete report.

[+Pe_Bo]

Thank you, distance column is back :-)

But I found other problems:

 

1) I've created a small PQ that includes caches with a TB, however the cache without TB is listed, see

https://www.geocaching.com/seek/nearest.aspx?pq=dedbc71c-7d66-4fd4-931b-4ec704f01375

 

2) Weird behavior of distance column if I switch PQ's "From Origin" from some location to "My Home Location"

- when I change home location, first page show old results, but switch to another page and back to first show new results!

PQ created with "My Home Location" from beginning seems OK.

see https://www.geocaching.com/seek/nearest.aspx?pq=92825900-b25c-4c17-bd41-21453fed6864

 

[+Bl4ckH4wkGER]

6 minutes ago, Pe_Bo said:

Thank you, distance column is back :-)

But I found other problems:

 

1) I've created a small PQ that includes caches with a TB, however the cache without TB is listed, see

https://www.geocaching.com/seek/nearest.aspx?pq=dedbc71c-7d66-4fd4-931b-4ec704f01375

 

I can't reproduce this so far. If I create a new standard PQ against my home coords and just check the "Has Trackables" filter, all works as expected: I only see caches that have TBs.

 

I will need additional details of what other filter you have selected and ideally screenshots, not just the PQ-id link.

 

6 minutes ago, Pe_Bo said:

2) Weird behavior of distance column if I switch PQ's "From Origin" from some location to "My Home Location"

- when I change home location, first page show old results, but switch to another page and back to first show new results!

PQ created with "My Home Location" from beginning seems OK.

see https://www.geocaching.com/seek/nearest.aspx?pq=92825900-b25c-4c17-bd41-21453fed6864

 

 

The PQ preview code is based on the old seek/nearest search, which frankly is a mess and long overdue to be retired. Amongst other things, it uses a bunch of client & server caching that may interfere with how the data you're seeing is presented.

 

That said, I cannot follow your description quite, yet. I'm also unclear of what you consider "old results" and "new results".

 

Again, please provide step-by-step instructions and screenshots.

 

[+Pe_Bo]

9 hours ago, Bl4ckH4wkGER said:

9 hours ago, Pe_Bo said:

1) I've created a small PQ that includes caches with a TB, however the cache without TB is listed, see

https://www.geocaching.com/seek/nearest.aspx?pq=dedbc71c-7d66-4fd4-931b-4ec704f01375

 

I can't reproduce this so far. If I create a new standard PQ against my home coords and just check the "Has Trackables" filter, all works as expected: I only see caches that have TBs.

 

I will need additional details of what other filter you have selected and ideally screenshots, not just the PQ-id link.

 

I created a PQ with these parameters:

 

* "Have Travel Bugs" checked

* From Origin - By Coordinates - N 48 53.800 E 14 30.500

* Within a Radius of 5 km

* the rest remained default

 

The preview contains the cache GC4YNCN which has no any TB.

Interesting discovery - the map does not contain this cache...

 

Edited November 4, 2022 by Pe_Bo

[+Pe_Bo]

10 hours ago, Bl4ckH4wkGER said:

10 hours ago, Pe_Bo said:

2) Weird behavior of distance column if I switch PQ's "From Origin" from some location to "My Home Location"

- when I change home location, first page show old results, but switch to another page and back to first show new results!

PQ created with "My Home Location" from beginning seems OK.

see https://www.geocaching.com/seek/nearest.aspx?pq=92825900-b25c-4c17-bd41-21453fed6864

 

 

The PQ preview code is based on the old seek/nearest search, which frankly is a mess and long overdue to be retired. Amongst other things, it uses a bunch of client & server caching that may interfere with how the data you're seeing is presented.

 

That said, I cannot follow your description quite, yet. I'm also unclear of what you consider "old results" and "new results".

 

Again, please provide step-by-step instructions and screenshots.

 

1) My Home Location is set to Location 1 (my real home, I can send you my coordinates)

2) I created a PQ with these parameters:

    * Caches Total 1000

    * From Origin - My Home Location

    * Within a Radius of 10 km

    * the rest remained default

3) The preview seem OK, I can switch pages and I get good results with correct distance

4) Now I set My Home Location to Location 2

5) The preview seem OK, the results correspond to the new home coordinates, distance and sorting is OK

6) Now I set My Home Location back to Location 1

7) The preview seem OK, the results correspond to the previous home coordinates, distance and sorting is OK (as in point 3)

8) Now I change this PQ by setting From Origin - GC Code GCA1KEE

9) The preview seem OK, the results correspond to the around of GCA1KEE cache, distance and sorting is OK (based on GCA1KEE cache)

10) Now I change this PQ by setting back to From Origin - My Home Location

11) Although the number of caches is correct (and the list seems to contain the correct caches, as in point 3), the preview is bad:

    * distance is not calculated from Home Location but (probably) from GCA1KEE cache

    * the first page contains different caches than as in point 3

    * when I switch to page 3, now I get correct page 3 (as in point 3)

    * when I switch back to page 1, now I get correct page 1 (as in point 3)  

    * when I the preview page close and open again, I can reproduce this behavior again (wrong first page etc.)

12) Now I set My Home Location to Location 2

13) Although the number of caches is correct (and the list seems to contain the correct caches, as in point 5), the preview is bad, in the same way as in point 11

 

Conclusion:

* List of caches seems to be OK in all cases (matches the current PQ settings and current Home Location, if applicable)

* distance and sorting is OK only if PQ has set "From Origin - My Home Location" from start, not later

 

 

[+Bl4ckH4wkGER]

9 hours ago, Pe_Bo said:

 

I created a PQ with these parameters:

 

* "Have Travel Bugs" checked

* From Origin - By Coordinates - N 48 53.800 E 14 30.500

* Within a Radius of 5 km

* the rest remained default

 

The preview contains the cache GC4YNCN which has no any TB.

Interesting discovery - the map does not contain this cache...

 

 

Thank you for the additional details. I can reproduce the issue with these repro steps.

I will create a ticket to get this addressed  

 

[+mbooda]

My “premature generation” problem appears to have been fixed. Thanks😄!

[+Bl4ckH4wkGER]

8 hours ago, Pe_Bo said:

 

1) My Home Location is set to Location 1 (my real home, I can send you my coordinates)

2) I created a PQ with these parameters:

    * Caches Total 1000

    * From Origin - My Home Location

    * Within a Radius of 10 km

    * the rest remained default

3) The preview seem OK, I can switch pages and I get good results with correct distance

4) Now I set My Home Location to Location 2

5) The preview seem OK, the results correspond to the new home coordinates, distance and sorting is OK

6) Now I set My Home Location back to Location 1

7) The preview seem OK, the results correspond to the previous home coordinates, distance and sorting is OK (as in point 3)

8) Now I change this PQ by setting From Origin - GC Code GCA1KEE

9) The preview seem OK, the results correspond to the around of GCA1KEE cache, distance and sorting is OK (based on GCA1KEE cache)

10) Now I change this PQ by setting back to From Origin - My Home Location

11) Although the number of caches is correct (and the list seems to contain the correct caches, as in point 3), the preview is bad:

    * distance is not calculated from Home Location but (probably) from GCA1KEE cache

    * the first page contains different caches than as in point 3

    * when I switch to page 3, now I get correct page 3 (as in point 3)

    * when I switch back to page 1, now I get correct page 1 (as in point 3)  

    * when I the preview page close and open again, I can reproduce this behavior again (wrong first page etc.)

12) Now I set My Home Location to Location 2

13) Although the number of caches is correct (and the list seems to contain the correct caches, as in point 5), the preview is bad, in the same way as in point 11

 

Conclusion:

* List of caches seems to be OK in all cases (matches the current PQ settings and current Home Location, if applicable)

* distance and sorting is OK only if PQ has set "From Origin - My Home Location" from start, not later

 

 

 

Thanks for the additional details. Frankly they still make my head hurt due to the sheer number of steps and back and forth needed to get things to break.

While I will pass it on, I'm not going to make promises that we will fix this one as it is a bit of an edge case. The time may be better spent on migrating PQ previews to the new search results - which will be the goal down the road anyway.

 

In the meantime, it would be easier if you set up individual PQs for your three scenarios instead of all the switching around of reference points.

 

 

[+Pe_Bo]

2 minutes ago, Bl4ckH4wkGER said:

Thanks for the additional details. Frankly they still make my head hurt due to the sheer number of steps and back and forth needed to get things to break.

While I will pass it on, I'm not going to make promises that we will fix this one as it is a bit of an edge case. The time may be better spent on migrating PQ previews to the new search results - which will be the goal down the road anyway.

 

In the meantime, it would be easier if you set up individual PQs for your three scenarios instead of all the switching around of reference points.

 

Unfortunately, the "new search" does not offer the same rich options as the good old PQs. PQs were working fine until the migration.

 

Using the "Home Location" just saves me from having to define new and new PQs.

And as shown, the problem is probably that changing back to the "Home Location" doesn't re-initialize some of the settings that were initialized when the PQ was first established.

 

These bugs shows the poor quality of the current code and poor testing.

 

[+Bl4ckH4wkGER]

20 minutes ago, Pe_Bo said:

 

Unfortunately, the "new search" does not offer the same rich options as the good old PQs. PQs were working fine until the migration.

 

Please read my comment again. I'm not saying anything about PQs going away.

I'm explicitly saying to migrate the PQ preview from the old buggy seek/nearest platform to the modern next.js search results.

 

20 minutes ago, Pe_Bo said:

Using the "Home Location" just saves me from having to define new and new PQs.

And as shown, the problem is probably that changing back to the "Home Location" doesn't re-initialize some of the settings that were initialized when the PQ was first established.

 

Knowing the mess that is the old seek/nearest code-base, I doubt it's that simple.

 

20 minutes ago, Pe_Bo said:

These bugs shows the poor quality of the current code and poor testing.

 

I responded to similar claims here before: 

 

Yes it was working before when two ancient ca 2005 code bases were working together. Some of these issues are side-effects of trying to get a 2005 and a vastly different and advanced 2022 version to talk to each other.

 

The best course of action would be to get two modern systems that are much more compatible to work together.  That is the next step.

 

For the present issue, while I understand your frustration, I offered you a clear workaround.  

 

If instead of continuing to have a productive conversation like we did up until this point , you'd rather point fingers and speak poorly about the people who are trying to help you, let me know and we can be done here.

 

And to those who say "don't take it personal" - thanks, I'll stand up for my developers and QA engineers any day because I know how hard they work every day within the constraints of our systems.

[+Viajero Perdido]

Speaking as someone who's had to maintain ~2005-era code myself and keep it running while integrating with newer stuff, I see where you're coming from, and know it needs to be done.

 

And while I'll miss some of those special 2005-era bookmarks that I still use, I'll consider that a small price I don't mind paying.  That which does not kill us, makes the code stronger.

[+RCH65]

Just wanted to let you know that Mystery Caches changed from 

<type>Geocache|Unknown Cache</type>

to 

<type>Geocache|Unknown (Mystery) Cache</type>

 

One of my scripts suddenly started ignoring Mystery Caches.

Edited November 7, 2022 by RCH65

[+Bl4ckH4wkGER]

@RCH65

Thanks for bringing that up.

 

This is one of several cache type related changes and is intentional. Some Event types also got updated to newer more accurate names.

 

Overall, the names now more closely align with what you see on your Profile, Statistics, etc.

 

Let me know if there are any questions.

[+HHL]

Unfortunately, some standard PQs do NOT respect some attributes any more. Namely, tree climbing, wading, special tools needed, significant hike etc pp.

Some of my PQs from last Thursday, Friday and today were fetching caches that were attributed with those unwanted, and excluded attributes.

This results in getting roughly 100 caches that I  wanted to exclude.

The PQs are:

https://www.geocaching.com/seek/nearest.aspx?pq=cd1e3ad4-c605-4983-8cce-8f0a3b731258

https://www.geocaching.com/seek/nearest.aspx?pq=8d382f6b-1502-4a5e-913e-717f79bf295c

https://www.geocaching.com/seek/nearest.aspx?pq=1bb5565d-7b4c-47b1-9b6c-2a2a3b2dff47

https://www.geocaching.com/seek/nearest.aspx?pq=3b66f99c-c55b-415c-a190-480bd015dcb7

 

Hans

[+little-leggs]

On 11/3/2022 at 6:20 PM, Bl4ckH4wkGER said:

I'm sorry, I am unable to follow what you're describing. Please compare your report to the other reports in this thread and try again. I'd be happy to help once we have a complete report.

Hi Bl4ckH4wkGER

 

LAST FOUND , option 

I used to be able to use this option to find ( UN FOUND ) new cache's by clicking it not once not twice but by clicking it three times ,

when I do this now it only shows me ( currently four cache's ) three trads and an event ,

but it used to show me a lot more , 

I know there is a lot more than its showing me , evens up until the new year 2023

my question is why can't I see them like I used to , when clicking Las Found three times . 

 

[+HHL]

And again. The PQs deliver caches that shouldn't be part of the PQ.

 

 

535 caches are added that are flagged with unwanted (excluded) attributes.

Today this PQ fails with excluding Attributes accordingly:

https://www.geocaching.com/pocket/gcquery.aspx?guid=dd00d9c7-0c7d-451c-8274-3af3aa05db04

 

 

 

PQs are pretty worthless without the correct excluding of attributes. Actually (besides limiting D and T) that's all I'm after. And it had worked pretty well the last 18 years until last week. My uneducated guess is that the AND/OR logic seems to be confused (by what ever).

 

Hans

Edited November 7, 2022 by HHL

[+pwgo]

Hi Bl4ckH4wkGER !

Is it aything I can do to participate in the investigations around "Caches along a route"?

 

I have a couple of PQs using that function. Among them a PQ normally giving 90-something caches, but now 41. Ampng the 41 is at least one cache that is far away from the 1 km setting.

[+HHL]

I checked the Swedish PQs to be run tomorrow. Last week, they were created by excluding attributes correctly.

 

 

Today I saw 5 of seven running against the 1000 limit. That way, wanted caches are thrown off the PQ because the PQ circle shrinks by adding unwanted to be excluded caches.

Unfortunately, PQs behaving that way are not beneficial any longer.

 

Hans

Edited November 7, 2022 by HHL

[+Bl4ckH4wkGER]

@HHL

Thanks for your report and the extensive documentation.

It appears that while we fixed things with the "include all" aspect of attributes, there is still something amiss with the "exclude all" aspect.

 

 

@little-leggs

 

Unfortunately you're still not including screenshots so my best guess is that you're talking about the PQ preview in old seek/nearest:

 

Without knowing exactly what PQ you're looking at or whether you're actually looking at an actual PQ vs just some other search results, it's hard to troubleshoot.

 

That said, clicking on "Last Found" would always sort the results on the "Last Found" date in either ascending or descending order. If there were unfound caches, you'd see them at the top when sorting in ascending order. Based on my tests that still works as expected.

 

I can't speak for how many clicks it used to take vs does take but am not aware of us having changed this part of the behavior. As noted above, the sorting still works.

 

 

@pwgo

 

As noted in my post from November 2, we've identified the issue, so no further help is needed at this point.

 

A fix will require rebuilding the polygon service that creates the coverage along the route. This is a larger ask and hence this one is taking a little longer.

 

 

[+newbie52]

I  have many Route Queries that have run weekly unchanged for years.  Since mid-Octuber they *all* return significanly fewer caches than they used to.  By design they hug parts of interstates and return caches that are close to the particular interstate. As needed, I defined extra control points that I then dragged on top of particularly curvy interstates. (For example I didn't want the route from Pougkeepsie, NY to Buffalo, NY  to go in a straight line. I needed it to follow the NYS Thruway through Albany, Syracuse, Rochester, etc.)

     
 As another example, I made a Route Query "Atlanta to Montgomery and Beyond" which is based on route "Atlanta to Montgomery and Beyond" along Int 85. The query itself specifies: Search Radius(.99mi), Either Side(500 caches), Any Cache Type, Any Container Type, Terrain(<=1.5), Difficulty (<=1.5), Placed(Any Time), Format(GPS Exchange Fmt). Sorry, I can't figure out how to make existing the Routes and Queries public; so, they are all under my ID (Newbie52).  They are not hard to recreate. Running this particula query used to return over 300 caches. It now returns about 125.

      
So was it over-performing in the past or is it under-performing now? Either way, the output has changed for all of my Route Queries.

 

[+Bl4ckH4wkGER]

@newbie52

 

Please see my last comment in the post above yours. It's a known issue with the current system. We're working on a fix.

[+little-leggs]

6 hours ago, Bl4ckH4wkGER said:

@HHL

Thanks for your report and the extensive documentation.

It appears that while we fixed things with the "include all" aspect of attributes, there is still something amiss with the "exclude all" aspect.

 

 

@little-leggs

 

Unfortunately you're still not including screenshots so my best guess is that you're talking about the PQ preview in old seek/nearest:

 

Without knowing exactly what PQ you're looking at or whether you're actually looking at an actual PQ vs just some other search results, it's hard to troubleshoot.

 

That said, clicking on "Last Found" would always sort the results on the "Last Found" date in either ascending or descending order. If there were unfound caches, you'd see them at the top when sorting in ascending order. Based on my tests that still works as expected.

 

I can't speak for how many clicks it used to take vs does take but am not aware of us having changed this part of the behavior. As noted above, the sorting still works.

 

 

@pwgo

 

As noted in my post from November 2, we've identified the issue, so no further help is needed at this point.

 

A fix will require rebuilding the polygon service that creates the coverage along the route. This is a larger ask and hence this one is taking a little longer.

 

 

 

 

 

two search's for un-found cache's 
one using PQ which shows just four cache's
second search using search tab filtering out , not owned by me , no found by me , see how many more cache's there are un-found near me 

should they not be the same ?

[+Bl4ckH4wkGER]

5 hours ago, little-leggs said:

should they not be the same ?

 

That highly depends on whether you've set them up for the same search radius around your home coordinates.

Your PQ is limited to 40 miles around your home coordinates.

 

Can you confirm that the same is true for the regular search? (By default it runs a global search that would yield a lot more results.)

 

Even if you run the original search based on the same 40 mile radius, there are almost 15000 caches in that radius.

PQs will always pick the first 1000 by distance around the reference point. This is finite and cannot be modified further - PQs are a snapshot in time.

 

Search, depending on how you filter it, will return the 1000 that is most relevant to your additional filtering. So you may get a different set of 1000 from the 15k total if you filter additionally on Last Found vs Distance. That is the benefit of Search being dynamic vs a finite snapshot by distance.

 

I don't see anything wrong here.

[+Team Canary]

Sort by any column reorders the list as expected. e.g. Date Last Found

 

But, only on Page 1!?!

 

Page 2 onwards is back to the default sort by distance.

[+HHL]

21 hours ago, HHL said:

I checked the Swedish PQs to be run tomorrow. Last week, they were created by excluding attributes correctly.

 

 

Today I saw 5 of seven running against the 1000 limit. That way, wanted caches are thrown off the PQ because the PQ circle shrinks by adding unwanted to be excluded caches.

Unfortunately, PQs behaving that way are not beneficial any longer.

 

Hans

And this is today's unacceptable result:

 

 

[+little-leggs]

13 hours ago, Bl4ckH4wkGER said:

 

That highly depends on whether you've set them up for the same search radius around your home coordinates.

Your PQ is limited to 40 miles around your home coordinates.

 

Can you confirm that the same is true for the regular search? (By default it runs a global search that would yield a lot more results.)

 

Even if you run the original search based on the same 40 mile radius, there are almost 15000 caches in that radius.

PQs will always pick the first 1000 by distance around the reference point. This is finite and cannot be modified further - PQs are a snapshot in time.

 

Search, depending on how you filter it, will return the 1000 that is most relevant to your additional filtering. So you may get a different set of 1000 from the 15k total if you filter additionally on Last Found vs Distance. That is the benefit of Search being dynamic vs a finite snapshot by distance.

 

I don't see anything wrong here.

From where I'm viewing there is a problem ,
both the PQ and the search are set with the same criteria ,
 

40 mile radius
not owned by me 
not found by me 

why are the two searches so different , when they used to be the same ,  only changed since 

Release Notes (Website: Pocket Query API) - October 18, 2022


 

[+Bl4ckH4wkGER]

18 hours ago, Team Canary said:

Sort by any column reorders the list as expected. e.g. Date Last Found

 

But, only on Page 1!?!

 

Page 2 onwards is back to the default sort by distance.

 

Yeah I can reproduce that.

As noted in my earlier post here, the seek/nearest page is very brittle. Some more context:

 

With every page change or sorting, the whole page and data reloads. Some things are stored in memory, some things are cached on a server. Yet, every time the page reloads it's basically a roll of the dice whether you get the same server again and things continue or whether things reset.

 

Based on all that, I won't continue the game of whack-a-mole and continue holding together seek/nearest with duct tape and zip ties. We'll spend the time to migrate PQ previews to the new search results instead as that is the more scalable long-term solution.

 

Thanks for your understanding.

 

 

 

@HHL

Thanks for the additional examples.

We've identified the issue and a fix is in progress.

 

No need for further examples at this point.

 

Thank you for your patience.

 

 

@little-leggs

 

I confirmed that they used to behave the same before as they do now.

 

Both PQs and the regular old search use the seek/nearest pages with similar URLs and the same user interface. It's easy to confuse the two.

 

Are you sure you weren't viewing a regular old search for those purposes before? Those would have access to the full 15000 results in your home zone also and yield different results - ones more in line with the new search interface.

 

In an attempt to clarify once more:

• Your 40 mile home zone has 15000 caches in it.
• When taking taking your home coordinates as a reference point, any search will initially return the same 1000 caches - the 1000 closest to your home coordinates.
• Now, PQs save the above (1000 closest to home coords) as a snapshot
• If you then sort across the PQ snapshot, it only has access to said 1000 caches. Any secondary sorting, e.g last found, can still only look at the 1000 caches.
• Search will actively adapt the 1000 cache sub-selection of the 15000 total based on your secondary sorting. The default 1000 by distance will match the PQ. If you then switch your sorting to any other reference, it may select a different subset of 1000, leading to results different to the PQ snapshot.

[+HHL]

6 minutes ago, Bl4ckH4wkGER said:

Thank you for your patience.

That's a piece of cake.

Thanks for all your efforts.

 

Hans

[+Ahtenga]

It is still not possible to exclude attributes in an pocket query as in the past. 

When will this be fixed? Pocket queries as they are now are totally useless for me. 

 

[+RCH65]

On 11/6/2022 at 2:00 AM, Bl4ckH4wkGER said:

This is one of several cache type related changes and is intentional. Some Event types also got updated to newer more accurate names.

Overall, the names now more closely align with what you see on your Profile, Statistics, etc.

 

Wherigo type changed from

<type>Geocache|Wherigo Cache</type>

to

<type>Geocache|Wherigo Caches</type>

 

Looks like a typo...(?)

 

[+Bl4ckH4wkGER]

10 hours ago, Ahtenga said:

It is still not possible to exclude attributes in an pocket query as in the past. 

When will this be fixed? Pocket queries as they are now are totally useless for me. 

 

The next sprint release will be Wednesday, November 16. It will also include a fix for the bug you're mentioning.

Thank you for your patience.

[+steben6]

On 10/24/2022 at 8:08 AM, Bl4ckH4wkGER said:

Thank you all for the reports over the weekend.

I have filed bug reports for the following issues:

• Sorting columns on PQ preview refreshes the page but doesn't actually sort
• Distance column on PQ preview remains empty if PQ is relative to home coordinates
• Attribute filters return caches with EITHER attribute instead of BOTH attributes
• User route PQs don't contain all expected results
• User route PQs remain empty if "Found within 7 days" is checked

 

This is a limitation of the new system that we won't be able to rectify. It results from Pocket Queries no longer running straight against the database but instead against a data cache. The latter contains the last 5 years of data (that's when it was implemented) and will continue to populate going forward.

 

I understand that it may be inconvenient in your area, and apologize for the inconvenience. 

 

Overall, the number of caches that haven't been found in 5 years is very small. We hence consider this tradeoff as manageable, if it improves performance for all players at scale.

 

 

Please take a moment to compare the bug reports from other players in this thread and your own. Unfortunately, it is missing crucial information.

I'd be happy to help you once you provide some screenshots & the Pocket Query ID for troubleshooting.

 

I am pretty dumb about computer stuff.  I don't even know what that means.

[+Bl4ckH4wkGER]

Today we released a number of bug fixes:

• User route PQs should include the expected number of results again
• PQs should no longer run immediately vs on the selected days
• They no longer include Events when Events are not selected as a cache type
• PQs limited to caches with TBs no longer contain caches without TBs
• They exclude caches with ANY of the selected attributes
• PQs no longer include caches from the ignore list
• A Wherigo Cache is no called that in the <type> tag

[+pwgo]

9 hours ago, Bl4ckH4wkGER said:

Today we released a number of bug fixes:

• User route PQs should include the expected number of results again
• PQs should no longer run immediately vs on the selected days
• They no longer include Events when Events are not selected as a cache type
• PQs limited to caches with TBs no longer contain caches without TBs
• They exclude caches with ANY of the selected attributes
• PQs no longer include caches from the ignore list
• A Wherigo Cache is no called that in the <type> tag

I can confirm User route to work as expected, but I guess that is no surprise. :-)

Thanks for the effort!

[+pwgo]

8 hours ago, pwgo said:

I can confirm User route to work as expected, but I guess that is no surprise. :-)

Thanks for the effort!

Sorry to rain on the parade, but there is still misalign between the PQ and what you see in the preview map.

Caches are both present on the map and missing in the PQ and the other way around.

 

Guid for PQ: ?guid=00fce57e-71e0-4cf0-b3d9-828485e24aba

 

Edit: The preview list is showing a third result unfortunately.

 

Edit (again): It looks like the caches missing in the PQ are the ones farthest away from the road, making me think that the distance valiable is different between the cases. I have choosed to have 1 km as distance, but it looks like caches beyond approx. 400 meters are missing.

 

In the case where caches are missing on the map, but are present in the PQ, they (2) are just before the beginning of the route. Might be someting similar there with distance variables,

Edited November 17, 2022 by pwgo
More findings.

[+Pe_Bo]

18 hours ago, Bl4ckH4wkGER said:

Today we released a number of bug fixes:

...

• PQs limited to caches with TBs no longer contain caches without TBs

 

Unfortunately, this error still occurs, see PQ with TB around GC98H0D cache.

 

18 hours ago, Bl4ckH4wkGER said:

User route PQs should include the expected number of results again

 

I tried a PQ along the route and the preview contains some caches twice and some caches are missing. My PQ contains around 800 caches so it's quite big, I'll try to simplify it to show the problem.

 

[+Bl4ckH4wkGER]

31 minutes ago, Pe_Bo said:

 

Unfortunately, this error still occurs, see PQ with TB around GC98H0D cache.

 

For context - your previous issue was no issue in the PQ API - that part was functioning as expected.

The issue was that the data for GC4YNCN in Elasticsearch (queried by the PQ API) was out of sync with what shows straight from the DB in other places on the website.

 

Chances are 99% that the same is true for this new cache you found. While we will look into reindexing TB information in Elasticsearch, a lot of these issues will resolve themselves naturally over time.

 

It's not scalable for us to manually reindex individual caches every time an odd-one-out is found.

 

31 minutes ago, Pe_Bo said:

I tried a PQ along the route and the preview contains some caches twice and some caches are missing. My PQ contains around 800 caches so it's quite big, I'll try to simplify it to show the problem.

 

I'd consider it more crucial whether the PQ file contains duplicated. If so, that'd indeed by an issue, but not anything that showed in our tests. If you have cases where that is the case, it'd be great to get repro steps for those.

 

Also note that as we had to completely rebuild how the route polygons are handled, there may by nature be slight deviations, especially toward the outside edges of the polygons. We may not be able to replicate the old implementation 100% but the current solution is very very close and actually provided better coverage in several areas. If that does not apply for your particular route that may be a case specific issue.

Lastly, to my previous comments in this thread, the old seek/nearest implementation is quite brittle. Hence resources spend on fixing it vs. spending that time on migrating these elements to the new pages will be limited.

 

Edited November 17, 2022 by Bl4ckH4wkGER

[+Bl4ckH4wkGER]

As a separate announcement for this thread:

The original release happened on October 18 and we're now on November 17. The month-long warranty period where bugs in this release were prioritized higher has ended.

 

With that and the various upcoming holidays, any further bugs, unless deemed critical in priority, may hence take longer to fix.

Thank you for your understanding.

[+Pe_Bo]

26 minutes ago, Bl4ckH4wkGER said:

I'd consider it more crucial whether the PQ file contains duplicated. If so, that'd indeed by an issue, but not anything that showed in our tests. If you have cases where that is the case, it'd be great to get repro steps for those.

 

The PQ file does not contain duplicates.

 

The problem with the preview is similar to the one already described in the post https://forums.geocaching.com/GC/index.php?/topic/382502-release-notes-website-pocket-query-api-october-18-2022 /&do=findComment&comment=6041975

point 11.

 

The first page displayed (after opening the preview link) has a different (wrong) cache than when I switch to the second page and then back again (not back in the browser or reload the URL, but by clicking "1" in the records navigation).

 

This problem occurs for all PQs that do not have a distance column (PQs along the path never have this column).

 

 

[+pwgo]

4 hours ago, Bl4ckH4wkGER said:

As a separate announcement for this thread:

The original release happened on October 18 and we're now on November 17. The month-long warranty period where bugs in this release were prioritized higher has ended.

 

With that and the various upcoming holidays, any further bugs, unless deemed critical in priority, may hence take longer to fix.

Thank you for your understanding.

How critical is the difference between the PQ file and the preview on the map deemed? Is there a rough ETA?

To me, warranty period ending without having the found problems fixed feels strange.

 

After all, we are paying for these functions in te premium subscription, can we expect some compensation for these problems?

 

Was my input above to any value?

 

[+pwgo]

Caches along a route

I have done some digging in this now.

 

First, what @Pe_Bo writes above seems to apply. If I turn to page 2 and then turn to page 1, the list corresponds exactly to the contents of the PQ file.

 

I have a PQ configured to include caches 1.100 meters from the route and made some estimations (ruler on the PC screen).

* The preview map, seems to be more or less correct when measuring from the purple route line. Caches 1.100 meter from the line are included.

* The PQ file (and preview list), seems to include caches about half the configured distance from the route, in my case, caches 600 meters from the route are included, while caches 700 meters from the route are not. 

 

I hope these findings can be of any help. To me, this is a way to get forward in the meantime, while corrections are made.

 

 

 

 

Edited November 18, 2022 by pwgo

[+mbooda]

https://www.geocaching.com/seek/nearest.aspx?pq=9c990fcc-289c-4f51-9d10-96a7731e9aa2
 

When I select “placed”, the first page displays just fine, but all subsequent pages revert to “nearest”. Selecting “”placed” on any subsequent page reverts to the first page.

[+Bl4ckH4wkGER]

@pwgo
Thank for the additional details. We'll take another look and I will circle back once we have insights. No, I don't have a timeline at this point.

 

@mbooda

Thanks for the report. As noted before, resources we will spend on fixing the old seek/nearest based PQ preview will be limited vs the migration to the new search results. I hence don't know whether we will address this.

[+FreizeitRunner]

I notice that for a couple of days the geocaches on my ignore list are no longer included in the downloaded pocket query. They were included before.

 

I looked into the settings for my pocket query (which I haven't touched for years), and I see that nothing has changed, especially the option
[ ] Are not on my ignore list
is still NOT checked, so the caches on my ignore list should be included in the downloaded pocket query. Is this a bug, or is the option to include/exclude caches from the ignore-list intentionally not working anymore?

I hope I have made my problem clear, I'm not a native english speaker.

[+Bl4ckH4wkGER]

Today, we deployed two bug fixes:

 

The PQ-setting for "Are not on my ignore list" is now respected

When checked, ignored caches will NOT be part of the PQ file. When unchecked, ignored caches will be part of the PQ file.

 

Please note that there is a pre-existing bug with ignored caches being removed in the old seek/nearest PQ preview regardless of the player setting. This will be fixed when we migrate the PQ preview to the new search results. We will do no further work on the existing PQ preview.

 

We did some more fine tuning on caches along a route PocketQueries.

Previously the search distance from the route could get a narrower than expected in corner sections, so routes with many corners could see less results than before. We've now ensured that the search distance never falls under the distance set by the player.

 

This exhausts the fine tuning we will do for the new route based queries. Please note that this is a new and different implementation and by nature results may differ slightly. That said, especially with the last changes, the queries are more accurate and we will not continue tweaking them back to the less accurate queries from before.

[+Pe_Bo]

7 hours ago, Bl4ckH4wkGER said:

We did some more fine tuning on caches along a route PocketQueries.

Previously the search distance from the route could get a narrower than expected in corner sections, so routes with many corners could see less results than before. We've now ensured that the search distance never falls under the distance set by the player.

 

This exhausts the fine tuning we will do for the new route based queries. Please note that this is a new and different implementation and by nature results may differ slightly. That said, especially with the last changes, the queries are more accurate and we will not continue tweaking them back to the less accurate queries from before.

 

Thanks for the fix, the results are much better now. Unfortunately, the problem with the preview, described earlier, still persists.

 

 

[+Bl4ckH4wkGER]

7 hours ago, Pe_Bo said:

 

Thanks for the fix, the results are much better now. Unfortunately, the problem with the preview, described earlier, still persists.

 

 

Please see my previous posts for a comprehensive explanation for why we won't be doing further work on the old PQ preview.

 

Thank you for your consideration and apologies for any inconveniences caused.

[+pwgo]

On 12/15/2022 at 12:47 AM, Bl4ckH4wkGER said:

We did some more fine tuning on caches along a route PocketQueries.

Previously the search distance from the route could get a narrower than expected in corner sections, so routes with many corners could see less results than before. We've now ensured that the search distance never falls under the distance set by the player.

 

This exhausts the fine tuning we will do for the new route based queries. Please note that this is a new and different implementation and by nature results may differ slightly. That said, especially with the last changes, the queries are more accurate and we will not continue tweaking them back to the less accurate queries from before.

Sounds good!

So I understand correctly:

I have tested by creating a new PQ on an existing route and get exactly the same result as before, caches about half the configured distance is included, not more.

But! Do I have to create also a new route, not only a new PQ, to get benefit from the "fine tuning"?

 

I actually can live with the "flaw", now when I know what is happening and how to get round it.

[+Geo Chief]

Unfortunately, creating a route with a time restriction does not work yet. Could you please check and fix this bug?

 

 

 

Thanks!