Integration with Search API and SOLR index

@hutch
I'm not really sure. The person who was handling the design aspects of our site started us down the road of using Location and Gmaps. When he moved on, and I had to take over what he did not finish, I looked at the direction he was going with those modules. It looked like a giant cluster f**k. I ran across this module when reading about the v3 API for Google and saw your post. I installed Geolocations and everything worked out of the box like I wanted (except the search api). One module, one solution.

I'm only using country, province, and lat/lng to geolocate specimen data, so I might not be the right person to ask :)

One thing I would like, and that we use in our particular circumstance, is lat/lng data for continent/oceans. I know that is not possible from Google API, nor logical when thinking of the Pacific Ocean having a lat/lng. However, when viewing a record that has a continent/ocean in our database, the map stays on the world view. I'm correcting this by adding a lat/lng when a node is submitted/edited and the only thing the user has filled out is the Continent/Ocean field. I use the following, though I'm sure they could be broken up better (Pacific being south pacific, north pacific, etc.).

Africa - Latitude: 7.18805555556, Longitude: 21.0936111111
Antartica - Latitude: -90, Longitude: 0
Asia - Latitude: 29.8405555556, Longitude: 89.2966666667
Europe - Latitude: 48.6908333333, Longitude: 9.14055555556
Indian Ocean - Latitude: -6, Longitude: 71.5
Indo-malayan - Latitude: -5, Longitude: 120
North America - Latitude: 46.0730555556, Longitude: -100.546666667
Oceania - Latitude: -18.3127777778, Longitude: 138.515555556
Pacific Ocean - Latitude:-8.783195 Longitude:-124.508523
South America - Latitude: -14.6047222222, Longitude: -57.6561111111

Anyway.... way off topic and rambling. As for the move to Location... I like Getlocations as it is :)

Thanks hutch. Glad I could help out in some way. Your module saved me a lot of headaches :)

Hey hutch. Having issues with this again and wondered if you had any ideas.
I have the geolocation fields I want in the solr index and they appear if I create a view and show them in table. However, when I try to create a map in the view using GetLocations Format, none of the markers are being placed on the map.

To give an example, the solr index is browsed using a url like this: http://testsite.loc/browse-map?page=2&f[0]=type%3Abir_locality
The "bir_locality" tells the index what type of node I'm looking for and returns the result number from paging (10). I've added the following fields in the view:

FIELDS
Indexed Node: Title
Geolocation: glid (indexed)
Geolocation: Latitude (indexed)
Geolocation: Longitude (indexed)
Geolocation: Marker (indexed)
Geolocation: Country (indexed)
Geolocation: Province (indexed)

An example of the data returned when viewing format is a HTML list:
Canberra CSIRO
401
60.1761
25.081499999999998
Australia
Australia, ACT

So, the data is there, the map shows on the page, but no markers are place. Any idea what might cause this?

Edit: The getlocations_all works on my site.

@hutch - Removing the pager didn't do anything. However, I did find a solution to my circumstance at least.

I'm pretty sure the solr index is based on what an entity exposes to it. Since getlocation isn't an entity, it does not know how to handle the fields. Simply a guess on my part. So I looked at the actual array data being exposed to the view:

[geolocation_glid] => 401
[geolocation_latitude] => 60.56
[geolocation_longitude] => 25.98
[geolocation_marker] => 
[geolocation_country] => Australia
[geolocation_province] => Australia, ACT
[title] => Canberra

As you can see, when it reaches the function template_preprocess_getlocations_view_map() the keys are not correct because of the geolocation_ prefix. As well, the field_name key => value is missing from the array. Probably due to relationships not being available.
In addition to that....

$base_field = $variables['view']->style_plugin->view->base_field;

... returns as "searh_api_id" instead of "nid" in my case.

What I did to solve my particular issue was create a preprocess function in my template.

/**
 * Preprocess for geolocations map on browse to reconfigure fields using solr index
 */
function bir_theme_preprocess(&$variables) {
  if (isset($variables['view']->name)) {
    $function = 'bir_theme_preprocess_' . $variables['view']->name; 
    if (function_exists($function)) {
     $function($variables);
    }
  }
}


/**
 * Special case to process solr index fields for geolocation
 */
function bir_theme_preprocess_browse(&$variables) {
  if ($variables['view']->current_display == 'browse_map') {
    $locations = array();
    $pre_locations = $variables['view']->style_plugin->rendered_fields;
    foreach ($pre_locations as $location_key => $fields) {
      $location_array = array('field_name' => 'getlocation');
      while (list($key, $value) = each($fields)) {
        $new_key = str_replace('geolocation_', '', $key);
        $location_array[$new_key] = $value;
      }
      $locations[$location_key] = $location_array;
    }
    $variables['view']->style_plugin->rendered_fields = $locations;
    $variables['view']->style_plugin->view->base_field = 'nid';
  }
}

Basically, I shortcut the template functions and rebuild the array with the correct keys. Again, this is for my own case just to get it working. Probably not the optimal solution.

Edit: I did try using bir_theme_preprocess_views_view() but it was called after the getlocations template.

Yes, the geolocations_fields_entity module is enabled. I'm not sure what would be missing from the field properties in there either. I've looked at a few modules implementing the same thing. All confusing to me.