Drupal 8 Port

Thanks, that's at least a good start!
I'll ask around among the other maintainers what their plans are and then probably just commit this as the start of the 8.x branch.

Committed. Thanks again!
However, I guess it would be better to keep this issue open for all subsequent work?

Thanks a lot, looks good!
I didn't have the time to test this, but since the module currently doesn't do much anyways, we might as well just commit it. However, in the attached patch I still fixed some of the code style issues, please review!

Also, maybe ask Mattias about getting committ access to the project, for working on the D8 branch directly?
I myself don't really want to maintain this module at all, and the D8 version even less so. I just don't have the capacities.

It's not possible to create a D8 issue. Adding the patch for the location views filter here.

Should soon be fixed, thanks for mentioning it!

Great, committed.

And OK, I understand of course. Still, thanks again for your work so far!

Could the 8.x-1.x-dev release be marked to show on the project page?

I've been having a look at the D8 code that's in git, with a view to making it also work with Geofield module.

I tried installing Location module, but it looks fairly broken -- I can't see that it actually provides a field type! And yet the code here has this:

    foreach ($index->getFields() as $field_id => $field) {
      switch ($field->getType()) {
        case 'location':

which suggests it does!

No, no, the Search API data type name is just "location" – that's completely independent of the module with that name. At least in D7, the module doesn't even work (out-of-the-box) with Location, but only with Geofield.
I expect it's the same for D8.

The D8 release should actually be shown on the project page, not sure why it isn't – see #2723101: Release not appearing on project page.

Ah, that makes sense!

So I can see now that I need to change the fields I add to the search index so their type is 'location'.

However, I'm now stuck with the views filter.

It gives me an error:

> Undefined offset: 1 in modules/search_api_location/search_api_location_views/src/Plugin/views/filter/SearchApiFilterLocation.php

This is the code causing the error:

    $location_options[] = array(
      'field' => $this->realField,
      'lat' => $location[0],
      'lon' => $location[1],
      'radius' => $radius,
    );

I'm not sure how the Views filter plugin is meant to get the latitude and longitude values.

The field the view filter is on is either JUST the latitude or the longitude. That's because when I go to add fields to the search index, the location field I added to my entity shows as an expandable field with subcomponents (Location » Latitude sine, Location » Latitude cosine, Location » Longitude radian, Location » Longitude, Location » Latitude), but I can't add the Location field itself.

This is how I did it:
Modules being used:

1. Geocoder
2. Geofield
3. Geophp
4. Search API Location
5. Custom module to set value in Lat,Lon format in Form Display so Solr wouldn't choke while trying to parse location data

Then in SearchApiFilterLocation.php to get Lat,Lon from input I used geocoder module like this:

$plugins = ['openstreetmap', 'geoip']; // These don't need API key to geocode data.
$addressCollection = \Drupal\geocoder\Geocoder::geocode($plugins, $this->value);

$location_options[] = array(
  'field' => $this->realField,
  'lat' => $addressCollection->first()->getCoordinates()->getLatitude(),
  'lon' => $addressCollection->first()->getCoordinates()->getLongitude(),
  'radius' => $radius,
);

This part:
$plugins = ['openstreetmap', 'geoip'];
should be returned from field settings so it could be more general and used by everyone without any manual changes but I am not sure how to get that data in D8, therefore can't create a patch.

As for custom module to feed Solr with lat,lon data instead of formatted full address, I created a geocoder.dumper.latlon service.

What I've got is:

- geolocation
- geocoder
- search API
- search API DB backend

and then:

- a custom Views filter plugin which inherits from the Views filter in geolocation, but for SearchAPI views.

This unfortunately has hardcoded data in it, as I'm currently stumped on how to add geolocation data to the index as a single field -- see #2733527: adding compound fields to the index.

After that, because there's currently no SearchAPI backend that supports the search_api_location feature, I've added a hook_query_TAG_alter() which looks at the SearchAPI query option for search_api_location and adds the right WHERE expression to the query. Again, this is custom only because it depends on knowing the names of the index tables. That's because each subfield in the geolocation field has had to be added individually.

I worked on this during Ironcamp, and I got a working solution that is also able to return the distance, and sort the results based on the distance.
Together with the latest patch of #2744733: Add location as a supported DataType for SearchApiSolrBackend of Search API Solr, I was able to make a view with geo filtering and returning the distance from Solr.
See the attached screenshot.
I committed the changed directly to the 8.x-1.x branch.

The solution is also more robust as the 7.x branch, as the distance field is linked to the indexed location field, so technically it is possible to index multiple location fields and calculate the distances.

The facets aren't working yet, as the range/slider functionality is blocked on #2611812: Create a date query type.

I will continue to work on this the next days and write some text/blogpost to describe the testing process.

I will continue to work on this the next days and write some text/blogpost to describe the testing process.

Great job, thanks!

However, if you're already working on this module, maybe it would be time for that review of the D7 branch you've been wanting to do for … [e-mail searching] … over two years now? :P Would be nice to get a stable release finally (though I don't think it's keeping many people from using it).

I got a problem using the geocoding input. The geocoder geocode-method expects a string but the input is an array containing the distance and the "value" (location).

Warning: rawurlencode() expects parameter 1 to be string, array given in Geocoder\Provider\GoogleMaps->geocode()

See: src/Plugin/search_api_location/location_input/Geocode.php:26

$geocoded_addresses = \Drupal::service('geocoder')->geocode($input, $active_plugins);

vs.

$geocoded_addresses = \Drupal::service('geocoder')->geocode($input['value'], $active_plugins);

Am I doing it wrong or is this an actual bug?

@n3or
I get the same issue as you, manifesting as the following error:

Warning: rawurlencode() expects parameter 1 to be string, array given in Geocoder\Provider\GoogleMaps->geocode() (line 82 of ...vendor/willdurand/geocoder/src/Geocoder/Provider/GoogleMaps.php).
Could not execute query "http://maps.googleapis.com/maps/api/geocode/json?address=".

Changing the $input to $input['value'] as in #20 above fixes this for me.
I guess this should perhaps be a separate issue so we can post a patch there.

The geocode input needs indeed some work, I currently only tested it with the map input.

It's better to make separate issues, and maybe it's better to close this issue, or use it as a meta issue to bundle the work that needs to be done to complete the initial port.

The issue mentioned in #20 has a separate issue and a patch here : https://www.drupal.org/node/2833685

The module already ported. So marking it close.