Major module modifications

i'm planning to integrate with search_api_solr for my current project http://drupal.org/project/geocluster

i'd be interested in indexing geohash values and then implementing the clustering logic as a solr plugin to be used with search_api_views.
this might be currently out-of-scope of your efforts but wanted to say hello to see if there is any overlap in our work.

Fantastic madmatter23! You could apply to become comaintainer as the current maintainers haven't done anything for a few months short of year! This module may even be abandoned...

you might be interested in Best practices for co-maintaining projects.

I'm currently looking at the module, the code does really need some cleaning up and your proposals seem to make sense to me.
Expect more from me in the next few days. As a start, I'll move everything Solr-specific into the Solr module so we aren't so tightly coupled here.

I couldn't find, though, how you can use a map for filtering in your version, as it was possible in the original one. Did you remove this functionality, or is there another module necessary for this, or did I just look in the wrong places? (I already installed the Geomaps module, but as far as I can see that only lets me display the results on a map.)

Yes, I'd already found that and was largely working off that version, as it seemed to be a bit cleaner than the previous one.
However, in my opinion there is still a long way to go before this becomes a clean module for adding this feature. Large areas of the module could be done much cleaner, and probably also much easier. You can also propose new hooks if one would be needed, instead of hacking around the problem with existing ones.
I now don't really have the time to take this on myself – maybe in a few weeks, or months. I'd really like the Search API to have a great location search available.

Well, here is a summary of the problems a see:

'spatial' option

First off, the option should be properly namespaced, and therefore be called search_api_location, not just spatial.
Also, I'd make this an array of arrays, allowing multiple location filters for each query. As I understand it (of course, I might be mistaken), that's no problem for Solr. You can even use different fields for each filter.
Also I'd definitely remove the radius units from the option – converting the radius to a defined unit (probably kilometres, but it doesn't matter) should be done beforehand, not left to each individual service class.
There might even be an argument for completely getting rid of the option and just defining some special handling for filters on location fields, for service classes which support the search_api_data_type_location feature. You could just also append the radius to the value (LAT,LON,RADIUS or the like). Of course, having operators other than = and <> would then be a bit useless, but that's a minor issue. You could define that other operators should just be ignored, or treated as <>.

Of course, for defining anything you have to clearly document the feature to developers, which you currently aren't doing. Even now you should have somewhere defined how a "location" will look when it gets to the server, what the server has to expect. Currently, you use a feature and an option, but define them nowhere.

Processor

Why even a processor? It doesn't seem to do anything really, apart from stuff specific to search pages, which should be better configured in the page, in my opinion, and then probably implemented with a hook_search_api_query_alter().
Especially I see no reason to only allow one location field per index which has to be globally set.

Check whether server is compatible

You never check whether an index's server actually supports the "location" data type, but just use it. Even though this should probably all degrade gracefully (the field will be indexed as a normal string and the query option, when present, ignored), you should at least warn the user that things will not work, and also not give them the according options (different Views handler, additional configuration for Pages), if the server isn't compatible.

SearchApiViewsHandlerFilterLocation

Also, in your current module version in the sandbox, the SearchApiViewsHandlerFilterLocation class (and the views_handler_filter_solr_location.inc file) seems to miss. There are also some other changes which weren't properly executed, e.g., the wrong 'path' key in search_api_location_views_views_api().

Whitespace

Not really a large problem, but there are a lot of whitespace issues in the module, mostly trailing spaces, a few missing newlines at the end of files and also confusing things like SearchApiIndex$index, which seems to be OK with PHP but isn't very good to read.

Attached is a patch of what I started to do before I gave up, against the latest sandbox version.

In any case, I'm also in favor of madmatter23 being added as a co-maintainer, at least if the current maintainers don't react soon and at least give their opinion on the changes here.

Also, of course, all Solr-specific code should be included right in the Solr module, instead of the alter hooks. See #1744250-4: Support location based search for a start of that.

Madmatter, have you received my email ? I contacted you through drupal.org's contact form last week I believe.

I would be inclined to sponsor part of the work being discussed here. If you and/or drunken money are interested, please let me know.

Many thanks

Just sent again.. if you haven't received my email. perhaps you could contact me ?

Many thanks

I've also committed your patch to the sandbox, and I'll run through it to get a better understanding of your changes.

Thanks, but you have again left out the search_api_location_views/handler_filter_location.inc file. Probably you forgot to git add before committing.

I probably won't have the time to work on this further in the near future, but still thanks for the committ access.
Keep up the good work!

Oh, and if there's any patch you'd like to get into one of my modules for this, and I'm not responding in the issue, please don't hesitate to ping me via mail! The same goes if you are unsure about how to interact with the Search API in some case.

Hello madmatter,

Been wondering on your plans with your sandbox module. I notice there has been some tremendous progress at http://drupal.org/sandbox/madmatter23/1799850

How about releasing it as a dev branch of Search API Location, so more eyes start working with it,

Looks like Solarium is coming to Drupal land, and then we wont need to reinvent the wheel :)

http://drupal.org/node/1900188
http://drupal.org/sandbox/cpliakas/1899634

Check this out!
http://wiki.solarium-project.org/index.php/V3:Geospatial_support

and a concrete example
http://wiki.solarium-project.org/index.php/V3:Query_helper

This seems to me lightyears ahead of the current Search API Location :)

Update: Due to the generous sponsoring of well mannered squirrel, I'm now working on this and will hopefully have a working prototype ready next week. It will include proximity search and support for bounding boxes.

Awesome, I cannot wait to help test the stuff drunken monkey.

Will your "proximity search" include distance facets? A block with distances like

1km (53)
5km (123)
10 km (4231)

I have started some work here http://drupal.org/sandbox/giorgio79/1889026, but got stuck. I imagine sg similar to this http://drupal.org/sandbox/pwolanin/1497066, video: http://www.youtube.com/watch?v=qYDzp-Yt3-4&feature=youtu.be
(FYI I already made you comaintainer there drunken monkey)

Yes, distance facets are definitely planned, though not top priority.

I've just hacked the present version of this module to add views argument (ie contextual filter) support.

How's views support looking in the refactor? If an additional set of hands would help I have the motivation/time at the moment.

same here, the current dev version / next release of geocluster supports search_api_solr backends and i would be pleased to help test it with a new iteration of search_api_location. looking forward to review stuff :)

I have now uploaded my first revision of the module. It even comes with README files! Please help test it and tell me what you think. (And maybe we can then get the module maintainers to look at it.)
Reminder: this is the sandbox we're using.
(I'm not providing a patch to the current module state, as this is more or less a complete rewrite.)

To use this new module version, you'll also need the new Solr patch at #1744250-6: Support location based search. (Which you could of course also test and review, while you're at it. ;))

I've just hacked the present version of this module to add views argument (ie contextual filter) support.

Oh, great! This is currently still missing in my version (I've only added filter support, and that's also a bit makeshift at the moment (due to the insane complexity of Views)), but I just thought about adding that. So if you could work on that and provide a patch, it would be greatly appreciated!

@drunken monkey, the first revision works like a charm. Thanks so much for your work on this, and to well mannered squirrel for the support. You've just made a critical first step in filling a huge functionality gap in the Drupal universe.

Here's a shot of a simple views list with an exposed proximity filter:

and here's the same thing rendered on an OpenLayers map:

I'm currently working on a project that has a use case directly related to this module's functionality, so if there's anything I can do to help, please don't hesitate to ask.

Oh, one thing I didn't mention: I'll of course also add support for the other Geocoder backends, it's just now hard-coded to Google. A simple matter of adding the form element and checking for it.

@ pasada: If you want, you could contribute a patch adding the Geocoder backend selection to both the Views filter configuration and the page configuration. (For the page configuration I'd also have planned a checkbox for whether to show the additional filters in the compact form (i.e., in the search block).)
Other than that, testing also helps a lot, so thank you very much for it!

PS: And another commit: I fixed the dependencies. There is no actual dependency on Geofield, after all, and Geocoder is only used by the two submodules.

hi , i can't find a proximity filter in views , however I install the module from this sandbox :http://drupal.org/sandbox/madmatter23/1799850
and I apply the following patch http://drupal.org/files/1744250--location_support-6.patch on Search_api_solr.
Any idea please ? i really need this functionnality on my website

Thanks a lot

Installed, and working. Codes nicely understandable, and with the exception of my note about geocoding below, makes sense to me.

I've got a version of my patch for the arguments working - couple of questions before I finish off and post a full patch though. Just if you have thoughts:-

To allow setting the point and the radius in the arguments I've made a second pseudo field. You can always set one as fixed if that makes sense for your use case. Code doesn't look nice though:

search_api_location_views_views_data_alter()

         $table[$key]['argument']['handler'] = 'SearchApiViewsHandlerArgumentLocation';
         $table[$key]['argument']['type'] = $field['real_type'];
         // add additional pseudo field to set radius by an argument.
         $table[$key . '_radius']['group'] = $table[$key]['group'];
         $table[$key . '_radius']['title'] = $table[$key]['title'] . ' ' . t('radius');
         $table[$key . '_radius']['help'] = t('@TODO');
         $table[$key . '_radius']['real field'] = $table[$key]['real field'];
         $table[$key . '_radius']['argument']['handler'] =                                            'SearchApiViewsHandlerArgumentLocationRadius';
         $table[$key . '_radius']['argument']['type'] = 'decimal';

With two fields the options need to be merged in query(). I'm guessing:

       $location = geoPHP::load($this->argument);
       $location_options = (array) $this->query->getOption('search_api_location');
       // Assume this assumption can't be made. Have to checking for real_field?
       $location_options[0] += array(
         'field' => $this->real_field,
         'lat' => $location->y(),
         'lon' => $location->x(),
       );

It will need to array_search or foreach through to find ('field' => $this->real_field) to merge them. There's no neater way?

The options 'When the value is not available' 'Display all options' doesn't make much sense for radius either. Not knowing the order we can't guarantee to unset the point. I assume just remove that default, the rest make sense.

The argument received by the point can vary too. If it's a geofield context it's serving WKT; I'm guessing the argument should also expect the comma separated format used elsewhere in the module. geoPHP will probably solve most of this, but not that of working like the filter - ie geocoding. Should alternative field(s) be offered for geocoded/formats? It seems a bit over complex.

Which is everything for the argument.

But on the note of the filter field. I'd prefer it if it was just a standard input field (wkt, the comma separated format), and then form alter additional modules offer different ways to fill/replace it. It offers more flexibility if nothing else. But on a more pedantic note the usage limits of the google geocoding api specifies Note: the Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited..

I have to use location field or i can use geocoder autocomplete and thanks to geofiel , just geocode from another field (and index that in Solr ).?

hi , i can't find a proximity filter in views , however I install the module from this sandbox :http://drupal.org/sandbox/madmatter23/1799850

Did you clear the cache? And set the index type of the field to "Latitude/longitude"?

But on the note of the filter field. I'd prefer it if it was just a standard input field (wkt, the comma separated format), and then form alter additional modules offer different ways to fill/replace it. It offers more flexibility if nothing else.

I'll surely add a select box for choosing which format (defined by Geocoder) should be used. Then users can choose for themselves.

But on a more pedantic note the usage limits of the google geocoding api specifies Note: the Geocoding API may only be used in conjunction with a Google map; geocoding results without displaying them on a map is prohibited..

Oh, darn, didn't know that. But if we proivde the select box for choosing the service/format, I think it'll be fine.

Regarding the argument, I'm not really sure how to best do it. Using an additional argument is a bit ugly I think, and I wouldn't know how it could be done relatively cleanly. You could probably look at the taxonomy views integration, they have this "taxonomy parents with depth from a different argument" thing that could resemble our use case.
From my feeling, I'd just have used a special syntax, like LAT,LON,RADIUS. We could even make it configurable, a) whether to use a fixed or a variable radius, b) which format to use and maybe also c) how the location should be interpreted (comma-separated coordinates or a string to geocode).

I have to use location field or i can use geocoder autocomplete and thanks to geofiel , just geocode from another field (and index that in Solr ).?

If I understand you correctly: you will have to use a Geofield, and from that it's "LatLong Pair" property. But of course you can fill it from another field via Geocoder, as usual. Or, you can just use a normal text field, as long as you enter the data in the correct format (comma-separated latitude and longitude).

You could probably look at the taxonomy views integration, they have this "taxonomy parents with depth from a different argument" thing that could resemble our use case.

Views taxonomy integration does both. It adds a 'filter' to the Has taxonomy terms (with depth); and it adds an additional 'field' so it can be modified like above Has taxonomy term ID depth modifier.

I could do both as well.

From my feeling, I'd just have used a special syntax, like LAT,LON,RADIUS.

But then you need to configure special contexts for everything. If I have (I have) a geofield in the context of a panel and I put a view pane into the panel I'm just going to get the geofield output as the contextual filter argument. I think this is a pretty normal panels, views pane, context situation for this. A WKT point is pretty easy here.

The module depends on geofield/geocoder; and hence geoPHP so there are a wealth of existing formats to choose from for a point, and it detects them all automatically. Circles - now circles are difficult. But keeping the radius as an additional argument (and optionally filter on point argument), works fine with the geocode there.

geofield already provides Views proximity filters. It would be sensible to reuse them, integrate with them imho #1469956: [Meta] - Improve Views-powered Geofield proximity searches

Yes I clear the cache and reindex .
I'll explain better , I have an entityform compose by an geocoder autocomplete (field) and a geofield ( with a widget : geocode from another field which in my case the geocoder autocomplete field).
In Search API , I index the LatLngPair (Lattitude/Longitude) and the geocoder autocomplete field (full text).

Now I want to create a view where I can see my search result on a map and where i can choose the distance of searching .
I don't know if i do something wrong but i can't fix my issue and i can't figure out what .

Any idea maybe ?

If you need more details ask me .
Thanks

geofield already provides Views proximity filters. It would be sensible to reuse them, integrate with them imho

The code behind the exposed fields might be useful geocode and exposed filter. But unless I understand it, the rest is based on the available functionality of sql proximity searches. The code is only in the new 2.0 alpha version too.

hi drunkenmonkey,

as always, the README.txt files are very informative. given that this is still sandbox code, that's even more remarkable - thanks a lot!

why is does the search_api_location.info state search_api_solr as a dependency? while its the only backend known to be supportive at the moment, i don't see any reason to state it as a hard requirement for the module.

i'd suggest to drop the geocoder dependencies and make geocoder integration an optional enhancement, if module_exists.

#1744250-6: Support location based search adds both support for geofilt (radius) and bbox queries. the current implementation seems to be geared towards the geofilt radius-based distance filter.

i would like to explore the possibility of adding bbox capabilities, especially by using an argument: a user might want to specify a bounding box argument in the same manner as its currently possible for database-queries using Views GeoJSON and optionally Leaflet GeoJSON.

i'm not sure if refactoring parts of the current search_api_location sandbox module into reusable parts for such use cases would be helpful. as stated in #30, #32 we can also think about adding search api support to existing filters/arguments in geofield or views_geojson, but they are also very geared towards database backends...

While looking at the great work happening on Geofield 7.x-2.x, I came across Brandonian's recent refactor of the views proximity handlers. There's definite duplicate work here, so it would be wise to collaborate.

drunken monkey has kindly done the heavy lifting of getting lat/lng indexed in Search API. In reviewing the issue queues of several related efforts, however, it seems that the wheels start to fall off when the debate begins on how best to manage exposed filters input. This is where everyone's use-case comes into play, as Brandonian points out:

We've had many, many different requests for various data sources (geofield on current node, geofield on current user, html5 location of current user, etc), and continuing to extend our views handlers by adding switch statement after switch statement was going to turn into a maintenance nightmare, so I've scrapped all that and created a mini-plugin system for interfacing with Views.

As giorgio79 pointed out above, it might be wise to integrate the proximity filters (and other views integration, for that matter) being developed for Geofield 7.x-2.x instead of reproducing the same effort here, since Geofield is already a dependency. Thoughts?

For the contextual filters this should cover most different contexts and url arguments.

The case is a little different from the Taxonomy one reference above because an empty radius doesn't trigger a search filter. Where as a empty depth is no depth, ie that level only. So the fully integrated (radius and point) field is extra, but probably helps DX.

Patch is against the sandbox.

debate begins on how best to manage exposed filters input

For exposed filters I do think keeping it as plain as possible and allowing a plugging system for whatever people want map, geocode, HTML5 location... makes complete sense.

For other proximity code filtering more generally it's worth noting that https://wiki.apache.org/solr/SpatialSearch is a world simpler than dealing with being able to do things like https://dev.mysql.com/doc/refman/5.0/en/functions-for-testing-spatial-re... from https://dev.mysql.com/doc/refman/5.0/en/gis-geometry-class-hierarchy.html So the filter options themselves just can't be there.

Keeping it simple now and getting a stable version of this module released, then get plugins would make the most sense?

@ekes patch works like a charm and makes the views integration of this module pretty much feature complete for a number of common use cases. For example, I just created a view that pulls geolocated nodes from a search index with a lat/long pair contextual filter and exposed filter. Then I created a panel that uses the current user as a context. I then added the view to the panel and passed the current user's location as an argument (from a geofield in the profile). The result: a view centred on the user's location (if known) or on a location entered in the exposed filter. Mission accomplished!

Keeping it simple now and getting a stable version of this module released, then get plugins would make the most sense?

I couldn't agree more. Between the hard work of drunken monkey and ekes, we've now got a functional and scalable solution for proximity search. Great work, folks!

Let the testing begin.

I want to test that , but when I want to patch I have some error on my terminal.If I understand well , i patch the search_api_location_views directory from the sandbox : http://drupal.org/sandbox/madmatter23/1799850 ?

I use the following command to patch : patch -p0 < 1798168-35.search_api_location.views_contextual_filters.patch
Maybe i'm doing something wrong ?

I use the following command to patch : patch -p0 < 1798168-35.search_api_location.views_contextual_filters.patch

Drupal patches are now made with git; so the path begins a/somewhere and b/somewhere; so you need patch -p1 < patch to remove the additional path. That or if you checked out of git you can just use git apply patch.

Documentation and more details: https://drupal.org/patch/apply

ok thanks , work perfectly with git .
I try to use this and I come here if i have other problem.

This module works only if I use the Location module , or can I display my results on a map thanks to a geocode from a geocoder autocomplete field ?
Maybe my explaination isn't clear , don't hesitate to tell me if .

besides the name, drunkenmonkey's sandbox doesn't relate to the location module.
as stated in the readme.txt it integrates with geofield

Well , so if I understand well , I suppose to don't have problem to integrate that.
However I'll need a litlle explaination on views.
I've made lots of different combination but never suceed to display a google map with all my search result on it .
Someone can describe me a bit : the type , the field , the filter , openlayers or geofield map ... that i need to have in my views ?
Thanks a lot .

I want to index the LatLonPair with SEARCH API but it doesn't work.
When I check in the Apache Solr Index I see that there are no LatLon fiels indexed.
May I change the schema.xml on solr or in the search api solr folder ?

why is does the search_api_location.info state search_api_solr as a dependency? while its the only backend known to be supportive at the moment, i don't see any reason to state it as a hard requirement for the module.

Ah, thanks! That's of course just an overlooked leftover from the old module. I've removed that now.

#1744250-6: Support location based search adds both support for geofilt (radius) and bbox queries. the current implementation seems to be geared towards the geofilt radius-based distance filter.

i would like to explore the possibility of adding bbox capabilities, especially by using an argument: a user might want to specify a bounding box argument in the same manner as its currently possible for database-queries using Views GeoJSON and optionally Leaflet GeoJSON.

As you have already remarked in the other issue, Solr's bbox isn't a real bounding box, it's just a quicker, less accurate implementation of the radius search. Therefore, I think, we shouldn't mind that too much – more so, since it would be completely backend-specific.

As giorgio79 pointed out above, it might be wise to integrate the proximity filters (and other views integration, for that matter) being developed for Geofield 7.x-2.x instead of reproducing the same effort here, since Geofield is already a dependency. Thoughts?

Geofield isn't a dependency, and it's 2.x branch even less so – especially since it's not even in beta state at the moment. I'll definitely take a look at it and see how similar their problems and solutions are, and what we could borrow from them, but I really don't think that depending on them is an option right now. Even though it would of course be disappointing, if they'd really already solved this.

In any case, the suggestion of introducing separate plug-ins to deal with user input seems great. We could then also follow dasjo's suggestion to drop the (explicit) geocoder dependency.
So, I'll explore this in the next few days and see what I'll find.

For the contextual filters this should cover most different contexts and url arguments.

Wow. Thanks a lot, seems to work perfectly! I've committed this to the sandbox.

did you commit this on the madmatter sandbox : http://drupal.org/sandbox/madmatter23/1799850 ?
ty

did you commit this on the madmatter sandbox : http://drupal.org/sandbox/madmatter23/1799850 ?
ty

Yes, exactly.

Sorry I didn't get the time to work on this the last few days, I hope I'll get the plugin system done tomorrow or on the weekend.

My first take at an plugin system for user input (using CTools plugins, like Geocoder) is now committed in the sandbox. I just haven't had the time yet to also adapt the Pages integration, so you can at the moment only use this with Views while Pages still uses hard-coded Geocoder. But I'll hopefully change this tomorrow.

Anyways, please review and see what you think, and what I could've done better there.

I'm particularly unsure about the argument handler. Should that use the plugin system, too? It didn't use Geocoder before, so I just left the custom system in there for now, only removing the GeoPHP dependency. But maybe we should still use the plugin system there, and maybe add a third built-in plugin using GeoPHP?

Pages are now supported, too. I also improved the plugin settings in the Views filter a bit.

You can now also set the Geocoder's plugin settings when using Geocoder to resolve an address.
However, the AJAX used for this doesn't work in the Views admin UI (probably related to #1694574: drupal_process_form() deletes cached form + form_state despite still needed for later POSTs with enabled page caching), so currently you have to open the filter form a second time, after selecting the Geocoder plugin, to get the correct plugin settings. Does anyone happen to know a solution/workaround for that?

Apart from that, I think we're finished here. Eagerly awaiting feedback, especially from mollux. ;)

.

If you really want the borders of London, not a certain distance from the center of London, then just use a taxonomy term. It's not possible with this module (or any other location search/filtering, as far as I know).

.

.

I just played around with this and struggle with the possibility to pass an "empty" radius.
The code sets the drop-down value for - to NULL but this seems to cause an error and the views filter isn't triggered at all.
With the attached patch the empty radius seems to work as intended. It keeps - as value and converts it later in SearchApiViewsHandlerFilterLocation::query() to NULL.

By the way it would be nice if the location_input plugins had access to the operator and value form fields to. Especially when working with exposed forms its maybe not sufficient to change the input-processing, but also the basic form elements.

Just been testing the contextual filters, and they work great except for some minor issues.

1. I am getting this error notice when using the point and the radius contextual filters together:
Notice: Undefined index: in geoPHP::load() (line 62 ofsites/all/modules/geophp/geoPHP/geoPHP.inc).
This does not happen when using the regular distance filter. (Possibly related #1862922: Undefined index: P in geoPHP::load)

2. A great additional feature would be to have a 3rd contextual filter for "unit" in addition to point and radius that would accept kilometers (metric) or miles (imperial, USA, Canada and UK) and return values accordingly, including the facets.

I just played around with this and struggle with the possibility to pass an "empty" radius.
The code sets the drop-down value for - to NULL but this seems to cause an error and the views filter isn't triggered at all.
With the attached patch the empty radius seems to work as intended. It keeps - as value and converts it later in SearchApiViewsHandlerFilterLocation::query() to NULL.

It wasn't really a bug, I actually planned for this to have no effect. However, I can see that specifying a location without a radius does have its uses, and we should give users the possibility to do that.
It seems, in the Pages integration I've already done that. So, I committed your patch. Thanks!

By the way it would be nice if the location_input plugins had access to the operator and value form fields to. Especially when working with exposed forms its maybe not sufficient to change the input-processing, but also the basic form elements.

Hm, that's an interesting idea …
I don't know how easily that could be done, though, especially with Views. Or, for Pages too, come to think of it – we need specific names for the elements after all, and different ones in both cases. Making that in a generic way could be difficult.
I agree, though, that it would be a great addition. That way, people could also use this mechanism to provide selection via maps and slider widgets, like currently in the Search API Location module.

Some feedback from mollux would be great, but I'd definitely consider this. Would you be able to provide a patch?

1. I am getting this error notice when using the point and the radius contextual filters together:Notice: Undefined index: in geoPHP::load() (line 62 ofsites/all/modules/geophp/geoPHP/geoPHP.inc).
This does not happen when using the regular distance filter. (Possibly related #1862922: Undefined index: P in geoPHP::load)

Ah, you're right. Thanks for reporting!
Should be fixed now.

2. A great additional feature would be to have a 3rd contextual filter for "unit" in addition to point and radius that would accept kilometers (metric) or miles (imperial, USA, Canada and UK) and return values accordingly, including the facets.

It would be rather hard to do that for facets, since they are almost completely independent from this module. But it would certainly be possible to add it for the radius.
Or would a simple option in the radius contextual filter be sufficient for your use case in that respect?

2. A great additional feature would be to have a 3rd contextual filter for "unit" in addition to point and radius that would accept kilometers (metric) or miles (imperial, USA, Canada and UK) and return values accordingly, including the facets.

It would be rather hard to do that for facets, since they are almost completely independent from this module. But it would certainly be possible to add it for the radius.
Or would a simple option in the radius contextual filter be sufficient for your use case in that respect?

Adding a simple option for the contextual radius would be great. So, to double check, facets would still be metric even if the radius filter is imperial? Perhaps some kind of a separate module would be needed, like Distance Facets? :)

So, to double check, facets would still be metric even if the radius filter is imperial? Perhaps some kind of a separate module would be needed, like Distance Facets? :)

We could probably very easily add a setting to the Search API Solr module (or some code to automatically realize what unit is being used). You could create an issue there.
However, this isn't really a priority for me, so it might take a while until I get back to it.

Sounds good drunken monkey. Raised a new issue #1948320: Ability to execute location searches in metric (kilometers, solr default) or imperial (miles) unit

@pasada - regarding your post #37, I'm trying to accomplish the exact example you had described but I'm getting no such result. Let me explain what I did and maybe you could point me to where I'm going wrong:

1. in "Page Manager" I create a new page
2. for "Context" I added "Token"
3. in the view I created to display the search results I created a pane display
4. for "Contextual Filter" I added "geolocation: LatLong Pair (indexed)"
5. in "Pane Settings">"Argument input"> I set "geolocation: LatLong Pair (indexed) source " to "from context" and "Required context " to "Token>Current User: Location"
6. for the view's "Filter Criteria" I set " geolocation: LatLong Pair (indexed) (exposed) " as the filter

Also, I added location field to profile pages and I made sure that my admin profile has lon/lat values in it.

I added the pane to my panel and, well, the contextual filter does not seem to do anything. The exposed filter on the other hand seems to work fine.

Also, one more very important caveat here, I tried to apply "1798168-35.search_api_location.views_contextual_filters.diff" patch with git but I'm getting a bunch of errors:

abbaS$ git apply 1798168-35.search_api_location.views_contextual_filters.diff
error: patch failed: search_api_location_views/README.txt:1
error: search_api_location_views/README.txt: patch does not apply
error: search_api_location_views/handler_argument_location.inc: already exists in working directory
error: patch failed: search_api_location_views/search_api_location_views.info:7
error: search_api_location_views/search_api_location_views.info: patch does not apply
error: patch failed: search_api_location_views/search_api_location_views.views.inc:16
error: search_api_location_views/search_api_location_views.views.inc: patch does not apply

Any ideas of what I'm doing wrong? Any help would be very appreciated.

@bianchie - It's been a while since I wrote that post and much has happened with this module and its dependencies since. I'll be revising over the next couple of weeks, as location search is integral to a project that we're currently on. So I'm hoping to post a full tutorial just as soon as a couple of details are worked out. Stay tuned.

While I'm here, a quick question for the maintainers: What's the plan for this module? There's been some fantastic work in recent months, but activity seems to have levelled off. Will this sandbox fork replace search_api_location, will it spin out into its own module (search_api_localsolr), or will it continue as a sandbox project?

I have written to this module's maintainer, mollux, some time ago. He promised to take a look at it, but such things can take a while for busy developers in my experience. If he approves, my favorite course of action would be to have the sandbox replace the current Search API Location code (even though it's admittedly almost a complete re-write). This would be best, since the Solr module would then support this module natively, without any patches needed. Another approach would be to have this in a new 3.x branch, though I don't think the 1.x and 2.x branches would then have much use (apart from the Maps integrations, but that could (and, imo, should) be split out into a separate module (possibly still bundled in this project, though).

Upgrading the sandbox to a full project would be the last ressort, due to the necessary name changes.

@pasada, many thanks for the prompt response. I'm definitely looking forward to your updates/tutorials. But, if at all possible, so that I don't keep on spinning my wheels in place, can you tell me if the steps I described are fundamentally flawed or the reason I'm not getting the expected result and the errors with the patch is because of the many changes in the module that took place. Once again, your response much appreciated.

@drunken monkey: I just opened an issue to integrate the sandbox fork and dropped a reminder note to the maintainers. Let's see what they say.

@bianchie: I recommend getting things working in a Views page (by pulling in the user location as a contextual filter) before adding Panels to the mix. Regarding the patch, correct me if I'm wrong, but wasn't that already committed?

WRT #64 @pasada, yes...where are we with this? Do you guys want non-programmer site builders in here yet to flounder around and take the module of a spin?
If so, where are we starting, from the sandbox? http://drupal.org/sandbox/madmatter23/1799850
If the sandbox just needs a modest push to get it out to daylight, can we talk about some sponsorship arrangements?

Yes, please, the module in the sandbox is ready to test!
I don't think any sponsoring is necessary at the moment, unless you want some new features added. But thanks for the offer!

As of yet, I haven't received a definitive answer from the project maintainers here (I wrote mollux again yesterday, though), but I hope we will soon be able to move Matt's and my sandbox code to this project in some way and create a Beta release.

@pasada - the thing is that my view is based on search api index and there doesn't seem to be user fields, filters or anything of the kind for that matter available for configuration. Am I missing something?

@bianchie: You'll need to add a relationship to pull in current user profile fields for use as arguments.

@pasada - there are 3 types of relationships listed in this view:

1. Indexed Node: Author
The author of the node.

2. Indexed Node: Category
Field "field_category".

3. Indexed Node: Translation source node
The original-language version of this node, if one exists.

Am I wrong in thinking that neither of them is relevant to pulling current user info?

@bianchie: Working on it this weekend. Should have something for you in the next couple of days.

@bianchie: OK, I had a chance to play around with contextual filters last night and came up with a solution. The following is a quick and dirty recipe for performing proximity search based on arguments passed in from a user's profile, via panels, to a view that uses the "LatLong Pair (indexed)" proximity filter:

First off, you'll need a working implementation of search_api, search_api_solr (rc5 as of this writing) and the madmatter23 fork of search_api_location. No patches required. I'll assume that you've already got a geofield field called (I'll call it "geo") in both the user profile and in a content type that is the focus of your search. Now would be a good time to create a test user and some dummy content, being sure to populate the geo field for each. I'll also assume that your search server and index is already configured and working.

Now you create a view with a content pane display. Within the view, create a contextual filter of type "Geo: LatLong Pair (indexed)" ("Geo" being the name of the field). Set the proximity to 100km for the purpose of this example.

Now go to the pane settings and set the argument input to "From content" and set the required context to User > Geo. There might be two instances of the Geo field in your list; start with the second one, but you might have to try both.

Next you create your panel, being sure to add the current user as a context. Add your views pane to the panel and check the pane settings to ensure that the "Geo: LatLong Pair (indext)" argument has "Current User" selected.

If you got to this point, you should now be cursing me because your filter isn't working and your panel is returning all items event though you've got a location set in the current user's profile. You would be right. It turns out that search_api_location can't parse the argument input from the user geo field, so you've got to massage the field output a little bit. I'm not sure if this is a bug or by design, but I'll do my best to describe the issue and greater minds can decide.

Although it attempts to use geophp to parse input, the contextual filter seems to only accept input in the form of a lat/long pair. By default, geofield outputs in WKT format (e.g. POINT (blah, blah)). The effect is that the argument is ignored and all results are displayed. You can play with this in the views auto preview by passing in a few different lat/long pair combinations.

The temporary fix I used was to modify the field display settings for the user profile geo field to output a lat/long pair with no labels. This gets you close but not all the way: 43.656, -79.387. Note the space after the comma, which the filter doesn't dig.

So let's just make a small change to the module code to accommodate our space. In the search_api_location module directory, open search_api_location_views/handler_argument_location.inc and go to line 54:

    if (empty($point)) {
      // Try Solr LatLonType.
      if (preg_match("/^([+-]?[0-9]+(?:\.[0-9]+)?),([+-]?[0-9]+(?:\.[0-9]+)?)$/", $this->argument, $match)) {
        $point['lat'] = $match[1];
        $point['lon'] = $match[2];
      }
    }

Now duplicate the if statement to accommodate a positive match if there is a space after the comma. You should end up with this:

    if (empty($point)) {
      // Try Solr LatLonType.
      if (preg_match("/^([+-]?[0-9]+(?:\.[0-9]+)?),([+-]?[0-9]+(?:\.[0-9]+)?)$/", $this->argument, $match)) {
        $point['lat'] = $match[1];
        $point['lon'] = $match[2];
      }
      // Try Geofield lat/lon (same as Solr LatLonType, but with space after comma)
      if (preg_match("/^([+-]?[0-9]+(?:\.[0-9]+)?), ([+-]?[0-9]+(?:\.[0-9]+)?)$/", $this->argument, $match)) {
        $point['lat'] = $match[1];
        $point['lon'] = $match[2];
      }
    }

The two statements are identical with the exception of the one little space after the comma in the preg_match. Now your argument should accept the output of the profile field and your proximity search should work. This is probably far from the most elegant solution, but I know you're in a bit of a rush for a working solution.

Hope this helps.

@pasada - I'm very grateful that you spent your weekend time looking into this and writing this extensive post. I'll let you know how it goes.

@pasada - I feel I'm almost there but I'm still hitting some walls.

To begin with, I set up all the versions of all the appropriate search api components, geofield, and token module, which btw. you didn't mention in your guide, but without which I was not able to configure "Argument input" to pull user: geofield from context.

I set up some content and admin user with geofield lat/lon coordinates.

I set up a view with pane display with the contextual filter and tested the behavior by throwing some coordinates into "preview with contextual filters:" input field, and everything seems to work swimmingly well - the results change predictably in accordance to the lat/long point and radius set. And that's fantastic!!!!

Then I set up a new page in page manager with context set to user (I also tried token in many attempts at making this work). Then, I set up a panel, added the view pane with "geolocation:latlong Pair (indexed) point set to user (or current user token when I had the context set to token).

I modified the lines in "handler_argument_location.inc" to what you specified, I took a deep breath, and …… nothing. The pane was still listing all results.

So, then I realized that you mentioned that after setting "manage display" for geofield on the user you were getting the following output with a space after the comma:
43.656, -79.387
The way I understood this is that you see this information displayed in this format when you go to user/view page, right?

Well, after configuring my "manage display" settings in accordance to the steps you outlined I get the following:

Latitude: 43.656
Longitude: -79.387

I have tried all the different combinations of settings and I cannot get what you got at all. Is this the root of the problem why the solution you outlined is not working for me?

I'm sorry for continuous questions but once again, I'd really appreciate your input on this. I feel that I'm almost there but I'm missing something, probably something very obvious.

@bianchie: You're almost there. Just one small detail that you missed: in the display options for the geofield lat/long pair, you need to remove the labels (uncheck the labels checkbox in field view format options). That will give you e.g. 43.656, -79.387, which is what the modified views handler is expecting. Hope this helps.

@pasada - thank you again. yes, I actually did have this option checked off but that didn't change anything. what did change things was when I turned off all the other displays off ("user account" and "token" - both of which had this option checked off as well - bug?).

Anyhow, I'm getting a beautifully formatted lat/long now.
Testing the view pane and it works beautifully as well, with and without the space after the comma, which means that code modification works, is that correct?

Now, the view page still does not receive the coordinates as an argument for some reason.

Playing around with the page/panels settings by changing contexts from user to token to both, adding and removing the view panes, changing the pane settings accordingly still does not yield successful result.

I actually noticed that there seems to be some unstable behavior where once in a while when trying to add content to a pane "view pane"in not available as an option (clearing cache does not change anything). To fix this I have to go to the view pane display and change contextual filter from "geolocation: LatLong Pair (indexed)" to "geolocation: LatLong Pair (indexed) point" and "geolocation: LatLong Pair (indexed) radius " instead and vice versa (certainly looks like a bug).

Anyhow, could you confirm that I'm setting up my page/panel properly? Here are my steps:

1. create new custom page
2. give it a "administrative title"
3. give it a "path"
4. set "variant type" to "panel"
5. from "optional features" select "contexts" and click continue
6. for "contexts" select "token" click add (or "user" depending on which option i'm trying)
7. in the dialog window leave default settings and click on "finish" then click on "continue"
8. in "choose layout" select a 2 col panel and click "continue"
9. in "panel settings" leave default settings and click on "continue"
10. in "panel content" click on gear icon, select "add content" then in popup window click on "view panes", if available, then select my view pane then for "geolocation: LatLong Pair (indexed)" select "token" (or "user" depending on which option i'm trying) and click "finish"
11. back on "panel content" click "finish" once more
12. on "variants>panel>content" click on "update and save"
13. back on "view pane" settings, verify that in "argument input" "geolocation: LatLong Pair (indexed) source" "from context" is set to "current user: geolocation" (which is the name of my geofield), click "apply"
14. save view
15. go to the url specified in the path for the page
16. all results show - no filtering applied - i suppose the argument is not being passed to the view pane

so close, but no banana
as always, help greatly appreciated.

gratefully yours,

@bianchie: I can't see any problems in your config, but there are so many little details to go wrong that all you can do is experiment until you've got a method that works. All I can add is that I've been able to successfully pass current user arguments from panels to a views pane that resulted in a user-specific location search. At this point, all you can do is play with it until you find the missing piece.

If you want another approach, I've decided to ditch the contextual filters and go exclusively with exposed filters. My use case is to present a basic "What/Where" form with the filters "Category" and "Location" exposed. The category is a basic select list (text) and the location is a search_api_location Lat/Long pair. The awesome sauce is in passing default values to the exposed filters from the authenticated user's profile fields, which is done through the following in a custom module:

function MYMODULE_form_alter(&$form, &$form_state, $form_id) {
  if($form_id == 'views_exposed_form') {
    global $user;
    $user_fields = user_load($user->uid);
    if (!empty($user_fields->field_category['und']['0']['value'])) {
      $interest = $user_fields->field_category['und']['0']['value'];
      $form['category']['#default_value'] = t($interest);
    }
    if (!empty($user_fields->field_location['und']['0']['value'])) {
      $location = $user_fields->field_location['und']['0']['value'];
      $form['location']['#default_value'] = t($location);
    }
  }
}

(Replace MYMODULE with the name of your custom module.)

This approach lets site members search with relevant default values (e.g. Jazz near New York), but offers the flexibility of using exposed filters to override the defaults from the same page (e.g. Blues near Chicago). This might not fit your use case, but at least it gives you an alternative to mess with. Good luck.

@pasada - Again, thank you for you valuable input/help!

I was able to resolve the issue I described before you suggested the new approach. Once again it was related to field display options for geofield. Geofield was passing the coordinate data to the context as WKT even though the format for "Default" display, the only one present, was set to Lat/Long . The solution was to set up "Token" display with format set to Lat/Long. With that corrected everything was working beautifully as you described.

Now, the alternative approach you suggested is pretty much exactly what I want to accomplish. I don't have any prior experience with creating new modules and coding in php so I need some time to digest/understand your suggested code and how to implement it. I mean, I do know I have to create .info and .module files, the naming conventions, etc., but, for example, I don't understand "$location = $user_fields->field_location". Is "field_location" a field from "User Locations" module (with the previous approach we used geofield), or is "location" in "$form['location']" a placeholder name for "geolocation: LatLong Pair (indexed) (exposed)". As you can see I'm not at all versed in this yet, however I'll keep at it.

Anyhow, thank you for your invaluable help with this!

Does the refactored module supports bounding box search?
thanks

Does the refactored module supports bounding box search?

That depends on what you mean with that.

Just been testing the module with the latest version of search api, and solr, and now I am seeing distance facets with .1 km intervals. Can we control this somehow? Also, can the module exclude distances that do not alter the search results?

FILTER BY DISTANCE
< 2.2 (189) Apply < 2.2 filter
< 2.3 (189) Apply < 2.3 filter
< 2.4 (189) Apply < 2.4 filter
< 2.5 (189) Apply < 2.5 filter
< 2.6 (189) Apply < 2.6 filter
< 2.7 (189) Apply < 2.7 filter
< 2.8 (189) Apply < 2.8 filter
< 2.9 (189) Apply < 2.9 filter
< 3 (189) Apply < 3 filter
< 3.1 (263) Apply < 3.1 filter
< 3.2 (263) Apply < 3.2 filter
< 3.3 (263) Apply < 3.3 filter
< 3.4 (263) Apply < 3.4 filter
< 3.5 (263) Apply < 3.5 filter
< 3.6 (263) Apply < 3.6 filter
< 3.7 (263) Apply < 3.7 filter
< 3.8 (263) Apply < 3.8 filter
< 3.9 (263) Apply < 3.9 filter
< 4 (381) Apply < 4 filter
< 4.1 (465)

Can we control this somehow?

It is controlled with the facet limit: if the radius is, say, 5 km, and you want 10 facet filters, then we of course have to use steps of 0.5 km. I can't think of an easy and clean way to circumvent this, I'm afraid.

Also, can the module exclude distances that do not alter the search results?

Yes, but it shouldn't. Use the appropriate filter provided by the Facet API Bonus module.

Awesome, thx! It was the "hard limit" setting in "configure facet display"

I'm thrilled that you forked this module because it's something I've been dying to have done on my site, but I feel like I'm missing something that everyone else knows. Please forgive my ignorance for being several steps behind on this issue.

The trouble I'm having is when I go into my Index View and add an Exposed Filter of the Geofield LatLong Pair, I don't get any proximity options (or any options for that matter) like I did with the original broken module.

The steps I took:
- In my content Type, I created a "Location" field using the "location field" widget.
- I then created a Geofield, Geocoded from another field (my Location field)
- Then go into Search API and create my Index, Add related fields, add my new Geofield> LatLong Pair, type "latitude/longitude".
- Still in Search API, I then go to the Workflow tab and go to the bottom where there is "Processors", check off "Location based Search", check off "fields to run on", check off my Geofield, select Radio button for "Select Type" "distance around a point". Then re-index
- Go to my Index View, Add new indexed Geofield, formatter "latitude/longitude"
- Add Filter, Select my Geofield, check Exposed, then there are no options other than the standard, "Required", "Label", "Operator", "Value", etc.

Aren't there supposed to be proximity values here and things like that? There used to be settings for the old broken module. Am I missing something?

Thanks for all of the work you did on this module. I hope it gets rolled into the original.

There is no Search API processor anymore in the new version of the module. Are you sure you're using the right one, in the sandbox?
Other than that, make sure that you're using the latest module versions, especially for Solr.

It turns out I just installed the Sandbox module incorrectly (new to git).
You're comments completely helped me fix the problem and it now looks GREAT! Thanks so much.

Hopefully, this will soon be committed and people won't have to use the sandbox anymore.

This is working well for us, so a massive thanks for all the work so far! Looking forward to it being committed at some point soon.

One thing I can't seem to do is sort a list by proximity.

I am using a SearchAPI View to display the results, with an exposed filter on a lat-lon field.

The results are displayed and appear to correctly limited by proximity.

What I would like to do is sort the view results by proximity, the closest first.
It would also be good to be able to list the proximity value with the results.

Is this behaviour already available or is it yet to be developed?

What I would like to do is sort the view results by proximity, the closest first.
It would also be good to be able to list the proximity value with the results.

Sorting by distance should be possible by sorting on the latlon field you use for the proximity filter. As long as a location is set, this will (or should) sort by distance to that location.

Returning the distance along with the results isn't currently possible, however. This is due to Solr not supporting it very well until Solr 4.x, though we could later add this as a Solr 4-specific feature.
For now, your best option is probably to compute the distance in PHP – or provide a patch for the Solr service class to let Solr return it after all.

Sorting by distance should be possible by sorting on the latlon field you use for the proximity filter. As long as a location is set, this will (or should) sort by distance to that location.

I'm sure I tried that, but can't have, because that is certainly working for me now. Thanks drunken monkey, that's another drink I owe you!

For now, your best option is probably to compute the distance in PHP – or provide a patch for the Solr service class to let Solr return it after all.

I will look into this as we are using Solr 4.x.

Many thanks!

@finn.lewis Which field should I use for exposed filter so as to filter by proximity?

Hello @drunkenmonkey,

I found a bug in the Views exposed filter:

stderr: PHP Fatal error: Call to a member function centroid() on a non-object in search_api_localsolr/search_api_location_views/handler_filter_location.inc on line 136

This error occurs when using Raw Input instead of Geocoder as location filter in the Views.

Another module had the same issue, here is their patch #1698512: Fatal error when geocoding an address failed.

Tried reporting here, but I am not sure that post reached you :)
#1942294: stderr: PHP Fatal error: Call to a member function centroid() on a non-object in search_api_localsolr/search_api_location_views

Oh, no, sorry, I forgot to set up notifications for that project.

But thanks a lot for reporting! It seems to me this is generally pretty broken! We specify that the location callbacks should return a "LAT,LON" string – but then just return a Geocoder/GeoPHP point, even though we don't even depend on Geocoder. I can't believe I didn't notice that …
I've committed a fix to the sandbox, please test!

Thx drunken monkey, works like magic now :)

And … committed! :D
This is now finally the official version of this project. There's now also a Beta release, where I tried to re-add the map widget functionality from the old module. Please try it out and see if it works!

@drunken_monkey:Thanks!
Question:Which module should we use?I am a bit confused now!

Use the official Search API Location project, e.g., its Beta 1 release.
For modules, enable "Search API Location" and either "Search API location pages" or "Search API location views" (or both), depending on what you're using for your searches. If you want the map functionality that was in this module before, enanble the "Search API Location Map" module, too.

Still the Distance field is missing.Is this planned on a future release?thanks

What is missing where?
If it's a feature request, please create a new issue.