Wishlist: Different approach to query for "rare" cache types

[GoogleCodeExporter]

Currently, queries are performed without pre-selecting cache types, and results 
are filtered accordingly.
For rare cache types, like CITO or WherIGo, this produces a lot of unnecessary 
load on GC servers - it takes tens to hundreds of search pages to collect all 
WIGs within 100 km around my home location.

GC offers the tx parameter to nearest.aspx searches. E.g., a WIG search uses
http://www.geocaching.com/seek/nearest.aspx?tx=0544fa55-772d-4e5c-96a9-36a51ebcf
5c9&dist=...&lat=...&lng=...

tx values I've been able to extract (list may be incomplete):
32bc9333-5e52-4957-b0f6-5a2c8fc7b257 Traditional Cache
a5f6d0ad-d2f2-4011-8c14-940a9ebf3c74 Multi-cache
294d4360-ac86-4c83-84dd-8113ef678d7e Virtual Cache
4bdd8fb2-d7bc-453f-a9c5-968563b15d24 Letterbox Hybrid
69eb8534-b718-4b35-ae3c-a856a55b0874 Event Cache
40861821-1835-4e11-b666-8d41064d03fe Unknown Cache
2555690d-b2bc-4b55-b5ac-0cb704c0b768 Project APE Cache
31d2ae3c-c358-4b5f-8dcd-2185bf472d3d Webcam Cache
8f6dd7bc-ff39-4997-bd2e-225a0d2adf9d Locationless (Reverse) Cache
57150806-bc1a-42d6-9cf0-538d171a2d22 Cache In Trash Out Event
c66f5cf3-9523-4549-b8dd-759cd2f18db8 Earthcache
69eb8535-b718-4b35-ae3c-a856a55b0874 Mega-Event Cache
0544fa55-772d-4e5c-96a9-36a51ebcf5c9 Wherigo Cache
3ea6533d-bb52-42fe-b2d2-79a3424d4728 Lost and Found Event Cache
416f2494-dc17-4b6a-9bab-1a29dd292d8c Groundspeak HQ
af820035-787a-47af-b52b-becc8b0c0c88 Groundspeak Lost and Found Celebration
72e69af2-7986-4990-afd9-bc16cbbb4ce3 GPS Adventures Exhibit

To my knowledge, tx= can be added to lat/lng searches as well as state (and 
probably country) searches, as well as "owner" (u=) and "finder" (ul=) ones 
(the latter may shortcut the corresponding selections but will produce another 
set of cached nearest.aspx files).

If only one cache type is specified on the command line or in the TUI, in 
particular for rare cache types, adding tx=... to the search URL may speed up 
things a lot. I'm not sure about the effect for multiple selections though - 
perhaps it's easier to fallback to previous behaviour in that case.

Original issue reported on code.google.com by Steve8x8 on 21 Mar 2012 at 9:16

[GoogleCodeExporter]

A patch has been committed to the devel branch.
If (and only if!) one cacheType is selected, the tx=... parameter will be 
submitted to the gc query. No modification will be made to ex/include users 
(which means if you use to exclude your own finds, the cached "ul" files will 
be used as before).
This speeds up searches for "special" types considerably (for earthcaches, 
citos, wherigos the list size is reduced to about 1%); it has almost no effect 
for "common" types though.
For multiple cacheTypes, the old approach (get list of _all_ caches around, 
then filter) will be used. This may be re-worked in the future, and I'm open 
for discussion.

Original comment by Steve8x8 on 23 Mar 2012 at 8:57

• Changed state: Started

[GoogleCodeExporter]

Interesting observation: 
If one searches with tx=69eb8534-b718-4b35-ae3c-a856a55b0874 (code for "Event 
Cache"), one gets not only "event" caches, but also "cito" ones (which have a 
separate tx code). This means some of the tx categories include others, and 
indeed, if you look for found caches of one of the celebrities, you see the 
explanation.
There is no separate tx code for "Event Cache"s whch are not cito, mega, or 
lost+found, and a similar situation holds for "Unknown Cache"s (which include 
"Groundspeak HQ").
As a consequence, a tx search will probably return more caches than desired 
*but* the subsequent cacheType filtering will fix this. No need to change the 
patch now.

Original comment by Steve8x8 on 27 Mar 2012 at 1:28

[GoogleCodeExporter]

Backported from branch 3.17.0 after more than 3 months of testing, believed to 
be stable.

Original comment by Steve8x8 on 28 Sep 2012 at 11:25

• Changed state: Fixed