Incorporating location into search

+1 The separation of Location search from main search is one of the primary weaknesses in what I would consider a very strong module.

Senarios:
- Search taxonomy term and location (gyms within 5 miles of this lat/lon, poet jams within 10 kilometers of this address)
- Search nodes and location (wiki travel booklets about San Mateo, CA)
- Search free tag (just taxonomy) plus free tag (another term) and location (education, kids in San Jose, CA)

I would like to also have the searching at a finer grain (feet, meters) which complements the better GPS equitpment. Bosted local GPS can even be finer grained.

Well seeing as this is a feature I rather require for a project I'm working on, I guess I'll bite.

First question, then, is how, from a UI perspective, should it be implemented?

- Add a "Near ZIP code" field to the content search page, basically moving the form from the current location search page here.

- Add a keyword field to the location search page.

- Add a "near ZIP" select box to the default search block. This is probably possible now with Forms API (yay!). It would need some default definition of "near" in order to avoid making the block too cluttered.

Thoughts?

the gsearch module does this for 4.6:

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/gojoingo/modu...

I think the way to do this would probably be with the new Forms API. I think this is exactly one of the purposes we have the new API: it allows us to use a hook_form_alter() to sneak in location related parameters into the search form and gives us the ability to validate and do certain things upon a submit. hook_db_rewrite_sql() can even allow us to modify the final query directly by adding in the "location" table to the JOIN and all the horrifying SQL in the WHERE clause that is involved with querying for matching latitude/longitudes in the location table.

I've written queries for that do both the location related stuff in the current search function as well as the stuff in gsearch. I'd be more than happy to assist whoever is trying to put the pieces together.

-Ankur

Awesome, Ankur. I'll see about grabbing you in IRC at some point so that we can touch base again on this. I need the forms API practice anyway, as I'm still not fully fluent in it. :-) Or you can email what you've got to me at larry at garfieldtech period com. Thanks.

Just to follow-up on this, I have some skeleton code checked into my sandbox for this now:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/webchick/buyb...

What it does is add a location box to the advanced search box native to Drupal 4.7. On the settings page, you can specify which fields to allow users to search by, and there is an added permission to let people search for users by location (since I know this has come up before as a possible privacy issue).

What's missing is the actual "searching" ;) I think that a lot of this could be pulled from gsearch module though, but have not had a chance yet to sit down and do it.

Thank you for posting the code for the search form. I scanned the code and i did not see a field for lat/long. I would encourage you to consider including Lat/Long as a query field (decimal format). Of course if the webmaster decides that his user base would not like this field, then it could be suppressed. This would help our international audience that cannot use zip codes.

Proximity Searches with Zip Codes
Here is a good discussion on pro cons and methods for proximity searches for zip codes:
http://forums.mysql.com/read.php?23,3868,3868#msg-3868

It may give you some other perspectives.

Vendor Map APIs
The other area that should use lat/long is in the APIs into external map services. I noticed that the if I input the lat/long (with no city or zip code) then the lat/long is not carried out into Google, MapQuest, or Yahoo with the result being a map of the United States.

Baby Steps to GIS
If we wish to get a bit more fancy in the future, we may consider storing the lat/long both in separate columns as well as a MySQL spatial Geometry column. The Geometry column type gives us a bit of headroom, since it can store store geometries of any type. This opens the door for more complex searches in the future. The limitation is that the current version of MySQL (5.0.x) does not perform the distance() and buffer() functions, which when implemented would save us some math and would be much faster.

- James

The locationsearch.module has been bounced around a few times and now resides in nedjo's sandbox, with actually decidedly little input from me. :-( (Sorry guys!) Unassigning myself since this isn't my project at this point.

If you want the module in contrib rather than sandbox, bug nedjo. :-)

Here's the locationsearch module as a candidate for Location contrib. See the README and TODO files for details.

+1 Needed functionality and works as expected with my tests today.

I am not sure if I like it as part of the advanced search options as opposed to a separate collapsible section. The advanced section is starting to look a bit cluttered. Slightly off-topic: I'd like to see more compartmentalization of advanced searching options - especially adding a location widget (or any others) into the mix. Any thoughts?

Looking ahead: How/when do we get rid of the pre-existing location tab. If we are adding location widget to the search page, especially if it were presented as a free standing option section, there is no longer any need for the tab. Yes? No? Could locationsearch.module nix it? Does Location.module itself need to be upgraded? Will the two be merged?

I agree that including this at the bottom of the advanced options is not ideal. In my case the location options drop completely off the bottom of the screen, so many people would miss them. I'm not sure exactly how to make it more prominate, though.

I like the ability to use city: and country: (it's like google and yahoo location searches, so it should be familiar) but it would be nice to have an explanation of that for the user somewhere.

I've added a couple proximity search filters into the location views module, including one that uses GMap to select a center point for the search (demo at http://www.elderweb.com/demo/views/proximitymap) and something like that would be a nice option here. Things are getting cluttered already, so I'm not sure the best way to add that in.

I was going to suggest something realted to search near me. If a user has specified a zip code or other location information, could that be supplied by default in the location search?

"Find near me" is a natural feature to add here. I don't know that I'd make it active by default, but even just a simple "near me" checkbox would make sense. That could even go in the search block, too.

As for cleaning up advanced search, why not simply make location its own fieldset above/below the advanced search fieldset?

I agree that further work would be useful, but don't have the time at present (unless it's bug fixing). As considerable new requests are coming in, I'm unassigning myself so that others may take this on.

Note that locationsearch is fairly complex because it needed to fix or work around significant limitations in search.module's extensibility. So, e.g., moving the locational attributes to a separate fieldset would I suspect require a fair bit of new work.

Note also that it's not possible to search only on locational attributes; at least one regular search term is also needed. This is because we can add to but not remove search.module behaviours. So users must enter something in the regular or advanced search boxes in any case.

One approach would be to apply what we have and then post feature requests for tweaks.

If I did have time for this, I would focus on pulling most of what's in locationsearch into a separate searchapi module, to enable the definition of additional search operands.

Since it doesn't break anything and does offer some nice functionality now, let's go ahead and add it to the location module project. That way we have a proper issue queue to handle future refinements and enhancements.

An improved searchapi is a better long-term solution, I agree; but that's more of a search.module task first. Let's make what is already available, er, available.

Marking as duplicate of #319278: [master][meta] Location_search rewrite.