Improved Search function

[+Pioneer Poodle]

I asked about this a year ago, and got no response from geocaching.com.

 

When I am searching for a geocache, it would be helpful to be able to Search with more than one parameter or attribute at the same time. The technical term for this is a Boolean search, and it is commonly available on most search engines.

 

For example, one of my caching buddies mentioned a new cache just up the street, named "Field of Dreams". When I did a Search on [Cache Name = Field of Dreams], I got 252 hits - that's 13 pages! What a pain! If I had been able to search on [Cache Name = Field of Dreams] AND [Cache Location = Arizona], I would have had two hits, and been able to pick out the desired one instantly. At times in the past, doing similar searches, I have gotten over 1000 hits, a result which is useless.

 

An alternative would be a button labelled "Search Within These Results". In other words, I can search with one parameter (in this case, Cache Name), get the list of hits, and then search just those those hits with a second parameter (in this case, Location).

 

What say you?

 

Bill

Edited January 4, 2012 by Pioneer Poodle

[+Bhob]

that strikes me as a handy addition to the searching capability

 

some searches do allow some limited multiple criteria

pocket queries let you do distance, type and ratings, for example

and the online search allows you to specify a distance for searches centered on a point (coordinates, zipcode, etc) - in fact, a "nearby" search centered on a geocache defaults to fifty miles (which I believe can be changed on your profile page, to a different distance [eg 100] or to a different unit of measure [eg kilometers])

 

but pocket queries don't appear to have the ability to search by name

and name queries don't appear to have any additional selection criteria at all

 

probably the easiest way for Groundspeak to implement what you need is to add name searchas to pocket queries and/or add the possibility of a distance restriction on name queries

 

but I would be all for enhancing searches as much as possible

for eaxmple, I'd like to see "hidden by" and "found by" added to pocket queries

and the ability to select more than one geocache type in an online search

(right now, you can ask for "traditional" or "multi", but not both in the same search)

 

your best bet is to submit it as an "enhancement" request

 

also -

there are plenty of sophisticated selection capabilities in some of the third party tools

(GSAK, for example)

but since they typically work on pocket query results, and pocket queries do not do name searches, that is probably not a viable option for your current dilema

Edited January 4, 2012 by Bhob

[+lysernix]

that strikes me as a handy addition to the searching capability

 

some searches do allow some limited multiple criteria

pocket queries let you do distance, type and ratings, for example

and the online search allows you to specify a distance for searches centered on a point (coordinates, zipcode, etc) - in fact, a "nearby" search centered on a geocache defaults to fifty miles (which I believe can be changed on your profile page, to a different distance [eg 100] or to a different unit of measure [eg kilometers])

 

but pocket queries don't appear to have the ability to search by name

and name queries don't appear to have any additional selection criteria at all

 

probably the easiest way for Groundspeak to implement what you need is to add name searchas to pocket queries and/or add the possibility of a distance restriction on name queries

 

but I would be all for enhancing searches as much as possible

for eaxmple, I'd like to see "hidden by" and "found by" added to pocket queries

and the ability to select more than one geocache type in an online search

(right now, you can ask for "traditional" or "multi", but not both in the same search)

 

your best bet is to submit it as an "enhancement" request

 

also -

there are plenty of sophisticated selection capabilities in some of the third party tools

(GSAK, for example)

but since they typically work on pocket query results, and pocket queries do not do name searches, that is probably not a viable option for your current dilema

 

I came here looking for the answer of this question... how to do it... looked all over, and at least am glad to see that I didn't miss it somewhere. This is a grevious oversight in my opinion and seems like it would be something that could be easily added. There are a couple of situations I wanted to use this:

 

Situation A:

Kansas City has a "battleship series" in which a 10x10 grid has been constructed overlaying the Kansas City Metro area and in each 1x1 block there is a cache that contains a hit or miss, and you sink the ships etc. It's actually a lot more complicated than that and an absolute wonder of a series... but that's not the point. I basically was trying to get them all on the map so that I could, if I was in a certain area of Kansas City easily identify when two (or more) of the Battleship series were in close proximity. If I had just been able to search by name within a certain radius I could have created this in one fell swoop - either via pocket query or by how I basically handled it as a workaround:

 

I manually added all 107 of the caches by hand to a bookmark/list. Once the list was created I was able to create a pocket query against that list... then when looking in map view I could add the pocket query filter and uncheck everything else... (as you probably imagine the KC area is littered with caches!). In this way I'm easily able to view the entire series and can identify situations where if I'm in very close proximity to some grid blocks while at others its advantageous to grab them all then.

 

Ok so that one's solved! But could have been a lot easier - they are all named A1: KC Battleship, C5: KC Battleship etc... so the text match on Battleship would have returned all the results I needed... (then could have easily picked out any strays).

 

Situation B:

I don't have a workaround for this one (yet!). Some caches / challenges in this area require you to find certain other caches.

Specific Example: http://www.geocaching.com/seek/cache_details.aspx?wp=GC3A9Z9

The cache requires:

 

"2) Find FOUR other caches with the following

words that STAND ALONE in the Title of them:

1) WILD

2) BLUEBERRY (You may do 2 caches for

this word--one with Blue in a Cache Title

and one with Berry in a Cache Title

3) RIDES

4) AGAIN"

 

I would like to do this really without it having to be a pocket query. It's not complicated. I simply want 2 criteria: name & location/proximity. I can search for any one of those words and receive thousands of results from around the world... but of course I'm really only interested in those 100mi from me... or in Kansas or Missouri... or in an area code... whatever's easiest. It would even be serviceable if I could simply sort the results by proximity to home location but that doesn't appear to be a sortable column.

 

If it needs to be a pocket query that's fine too. If anyone knows of a workaround for this let me know!

 

And Pioneer Poodle... perhaps my "situation A workaround" might help you in certain situations!

 

And Bhob... yes enhanced all around would be nice... particularly "Placed By: X" "Favorited By: Y" etc... I believe searching by name of cache - which is an option now (and it does do partial matches) is an absolutely essential piece missing from PQ and/or should simply be added to "advanced search".

Edited January 19, 2012 by lysernix

[+kantear]

i'd give this a few thousand votes ... but i'm only one.

[+Ambrosia]

I've wanted this ever since I started caching. So, almost 10 years, now.

[+dfx]

YES!

[+Hynr]

I've wanted this ever since I started caching. So, almost 10 years, now.

Yes, indeed. I believe I also requested this back in 2004 or 2005 before I realized that... oh, nevermind.

[+mstark71]

I've wanted this ever since I started caching. So, almost 10 years, now.

Yes, indeed. I believe I also requested this back in 2004 or 2005 before I realized that... oh, nevermind.

 

I also feel like there is room for huge improvement in search functions.

[+Nesshawk]

I totally agree!

 

A lot of people create Mystery/Puzzle caches that are "challenges" without posting them as actual challenges on the website. When I click on the taskbar's "Find Challenges", there are none in my area. However, I know they exist as mystery caches. I have been trying to find these with a keyword search, but I got over 8000 hits! (I don't need hits in Gambia and Sweden, at least not yet! ) I have been looking at bookmark lists from other users, but it would be so fantastic to search by two parameters: i.e. keyword "challenge", 200 miles from such-and-such city. This would also help with some of those actual challenges. Need challenges with the word "night"? Do a search by keyword AND location.

 

Actually, the only place this search function IS available, to my knowledge, is the Geocaching App on iPhone. The advanced search function on the app allows for this. You can search by location and keyword, also by a whole lot of other parameters as well. If it exists on the app, why can't it be on the website, too?

 

Thanks, all, for your comments!

 

nesshawk

Edited June 28, 2012 by Nesshawk

[+NYPaddleCacher]

Using boolean searching is just one way to do this.

 

I implemented a search mechanism a few years ago using a Searching API called Lucene. Lucene is quit common and has implementations in many different languages. In addition to providing boolean searches it provides field level searching. For example, would return all results with the work "Challenge" in the title (but not results which had Challenge in the description.

 

title:Challenge

 

Combine fields with a boolean search to return everything with Challenge in the title and "New York" in the state field.

 

title:Challenge AND state:"New York"

 

It also supports ranges in fields. For example, to find all caches owned by me with a difficulty between 2 and 4.5 (inclusive):

 

owner:NYPaddleCacher AND difficulty:[2 TO 4.5]

 

It also support wildcards

 

title:E.T.* - matches any title which starts with E.T.

title:"E.T. 9?" - matches titles such as E.T 91, E.T. 92, but not E.T. 911.

 

All of this and more comes built in with it's standard query parser. The trick is to create the searchable index from fields in the database, and then document what fields can be searched. It's pretty easy to work with and can create a really powerful search mechanism.

[BlueRajah]

While at it...

 

Can the search page have the most heavily used functions at the top? I would think the title, and GC code are two of the most used, yet they are at the bottom of the page.