Keyword search feature

[+salmondan]

Would be nice to have a search feature that could handle more than one clue on the keywords- specifically to narrow down with state as well as whatever keyword you remember.

[+Cheminer Will]

I have found that a lot of forums, including this one, have search engines that don't allow me to find what I am looking for. What I do that seems to work better is to use an outside search engine like Google and limit the domain searched to this forum. I seem to get much more accurate results.

 

on edit: I see I read too fast and you are talking about the search on the geocaching.com find a cache page. Sorry. I agree with your request on that, though. I'll leave my original response here anyway as it might help someone looking for a way to get better results searching the forums.

Edited December 6, 2006 by Cheminer Will

[kablooey]

Would be nice to have a search feature that could handle more than one clue on the keywords- specifically to narrow down with state as well as whatever keyword you remember.

 

The site used to support SQL "LIKE" queries, but I notice that has changed recently. Probably to reduce the query load on the Sql server. Of course, it would probably be smarter to notice the Sql % wildcard and just use LIKE in those cases. Unfortunately, now it's really hard to search for certain cache names when you can't remember exactly how the title is worded, especially when the site sometimes allows people to inadvertantly name their caches with accidental doubled spaces, for example.

[+The Leprechauns]

The Google Custom Search bar on the front page of Geocaching.com is a helpful recent addition. Try running a part of a cache name and its state and hider name through that tool.

[+ksmvav]

I played with the Google search and still didn't get the results that I was really looking for. When looking at the Seek a Cache section, I would like to be able to choose whether a keyword is trying to find results in the cache title or cache description, or both. Then, be able to combine the keyword with a location search - zip, state, country or local state page.

 

Combining keyword with area code search would also be useful.

 

On the search by local state page, it would be helpful to allow us to filter out those caches we have already found or show all.

 

While we are on the subject of searches and pocket queries - it would be nice to have the pocket query allow us to enter keywords in as well, either by cache title or cache description.

 

Thanks for the forum.

[Ranger Fox]

I, too, noticed the '%' wildcard had been "removed" from use on the seek page (or, really, the percent literal was being used and not the percent wildcard). I was making use of that quite a lot because I could remember bits and pieces of the cache title (or didn't know if the title was plural), but not the entire thing. Perhaps this removal was due to SQL injection concerns?

 

If it was removed due to performance concerns, I'm at a loss for a faster way to compare strings while using wildcards. It's either using LIKE with the full user's string or CHARINDEX within an array of search terms (split by wildcard because you don't know how many wildcards will be used before runtime). You're still comparing against strings, so I really can't see too much of a performance gain from transforming the percent wildcard to a percent literal.

 

Even with a form that would have the AND and OR operands available to users with which to use to seek caches by title, you would still have to come up with a way to use wildcards in the stored proc nonetheless. So, really, no help there and I'm at a loss for how else to do that via the stored proc. As I said, if LIKE was out due to performance, CHARINDEX is most assuredly out by the same coin--and I don't know what's left. It's much faster and efficient to do string comparison via the database than it is under .Net. You also don't have as much network use when sending the dataset to .Net from SQL Server.

 

If the wildcard "removal" was due to SQL injection concerns, a simple programmatic test could have been applied before the string would be used. This would detect any other sort of misuse while allowing the wildcard to pass.

 

Well, anyway, this is what I have pondered thus far. After all, this is my field, too.