Hi,

I'm building a hobby project, and I've installed this module. Works well, but it still doesn't meet my requirements. I'd need 2 contextual filters:
1. the logged-in user geolocation
2. the distance and unit (km/miles).

I think this make a good use case, as it would allow users to browse/discover content close to them. I'm just sharing my need, I may work on it in the next few days and provide a patch. Thanks for any suggestion in advance.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kay.beissert’s picture

If the logged-in user can input an address to define his geolocation (like in google maps), this is what I need. I stay tuned.

mariano.barcia’s picture

@bertoluci, thanks for the input.

I realized that I also need a field "distance" to display along each result, and also to be able to sort the results by "closest results first".

So, my priorities would be:
1. Support geolocation field stored in the logged-in user info
2. Provide a "distance" filter (exposable)
10. Provide a "distance" field for displaying and sorting
11. Support changing the origin geolocation, which should mimick the geolocation methods (gmaps, html5).

10. This can be partially achieved by displaying the distance once the user clicks on one of the rows.
11. I think now this use case is a nice-to-have, because a more common use case would use the geolocation pair already there in the user info, who should inform their geolocation once ie. in the registration/settings form. In the view, users may play with the distance filter. That's the way Badoo does it for instance.

I took a glimpse of the code, and it's difficult to understand. Probably because Views itself has become very difficult to understand :-/ For the time being, I need to postpone working on this until I can make some good progress in other areas of my project.

Open Social’s picture

Make sure to adjust the fields, module name and view name to your use case
Also I get the lat and long via $_GET, that is only avaiable when you have an exposed filter with no ajax enabled.

/**
 * Implements hook_views_pre_execute
 */
function YOUR_CUSTOM_MODULE_views_query_alter(&$view, &$query) {
	// Add a field inside the query and sort on that one
  if($view->name == 'YOUR_VIEW_NAME') {
		$view->query->fields['geo']['field'] = '(((ACOS(SIN(' . $_GET['lat'] . ' * PI() / 180) * SIN(field_data_field_user_geocoder.field_user_geocoder_lat * PI() / 180) + COS(' . $_GET['lat'] . ' * PI() / 180) * COS(field_data_field_user_geocoder.field_user_geocoder_lat * PI() / 180) * COS((' . $_GET['lng'] . ' - field_data_field_user_geocoder.field_user_geocoder_lng) * PI() / 180)) * 180 / PI()) * 60 * 1.1515))';
		$view->query->fields['geo']['alias'] = 'geo';
    $view->query->add_orderby(NULL, NULL, 'ASC', 'geo');
  }
}
derjochenmeyer’s picture

Title: provide contextual filter » Provide contextual filter (e.g. use Geolocation Field data in nodes and users as filter input)
Version: 7.x-1.1 » 7.x-2.x-dev
Category: feature » task
johnv’s picture

Title: Provide contextual filter (e.g. use Geolocation Field data in nodes and users as filter input) » Provide contextual filter (using Geodata from argument/node/user as filter input)
Status: Active » Needs review
FileSize
22.18 KB

Please find attached a patch that contains a contextual filter, using the page argument as a filter.
Currently it mimics the proximity argument handler from the location module.

You can specify location + distance like this:

  1. www.example.com/myview/50.91,4.43_50 (out of the box)
  2. www.example.com/myview/BE_brussels_50 (requires geocoder module)
  3. www.example.com/myview/brussels_50 (requires geocoder module)

Options 2 and 3 need the Geocoder module to be installed, and use the Google Geocoding API.

It supports the following storage modules:

  • Geolocation (ofcourse)
  • Geofield
  • Location

The patch might need some love, though:
- I have included earth.inc from the location module, because i did not understand the SQL-distance part from the other handlers. That might be removed by refactoring the sql-distance part (see code), or we might use it more.
- support more Geocoder features, by reusing/ the Geocoder from/to settings.

Attached patch can also be the basis for:

  • getting geo-data from current user;
  • getting geo-data from current node;
  • separate distance argument like ../myview/brussel/50, which can be used on node, user, too.
pinkonomy’s picture

Is this possible with this module/patch to search for nodes inside an area?E.g. a user to enter an area and as a result will return all nodes inside that area.Is this possible?
thanks

pinkonomy’s picture

Is this possible with this module/patch to search for nodes inside an area?E.g. a user to enter an area and as a result will return all nodes inside that area.Is this possible?
thanks

johnv’s picture

@pinkonomy, this patch searches for nodes within the raius of the page argument. IIRC, the module already provides a search box in an exposed filter.

scalp’s picture

I applied the patch at #5. The result I get is that the contextual argument options show up in the Views UI. I can set them, but when I do a preview using a lat,long argument it's not getting added to the query. Same results on a page view. Nothing regarding the argument is getting passed into the query. Any thoughts?

JKingsnorth’s picture

Category: Task » Feature request
Issue summary: View changes
Status: Needs review » Needs work

I'm not sure if the patch in #5 is the right approach for the module. Geolocation field is supposed to be designed to be lightweight, and not rely on the many other solutions out there. I notice that there is also a lot of superfluous code in the patch, brought across from the filter handler.

I think in the first instance, to satisfy most use cases, we should look at creating a new argument that searches using the lat/long field of the currently viewed user or node (or argument), with a configurable distance.

I'm working on this at the moment, but I don't want to dissuade others by assigning the issue to myself :P

We can then look at the other bells and whistles in future iterations.

JKingsnorth’s picture

Hehe, this is proving very complicated. I thought I'd post how far I got, which 'works' for nodes, if used by itself. But tying in sort order and a field to display the distance relative to the contextual filter starting to get a bit barmy. Hopefully this might at least provide a starting point for somebody else?

doitDave’s picture

Assigned: Unassigned » doitDave
Status: Needs work » Active

Hi all,

I was also desperate for a working argument (Contextual filter) solution. As it turned out, this actually *is* a really nasty job, thanks to Views' complexity (which is basically good) and its horrible documentation (which actually is horrible). However, in the end I managed to rework the module to the following:

* Contextual filter, taking:
** Raw argument (lat,lng)
** Node + Field name (to extract these values from; extending the node_nid default argument plugin)
** Validating any provided argument with a dedicated argument validation handler (which does the same as the validation stubs already existing in the module)

* Filter:
** Aside of manually setting coordinates (existing behavior), any existing contextual filter can now be selected to filter on.

* Field:
** Streamlined (no longer with a "enter location" or "exposed" option, which IMO is now purely obsolete, because...)
** ...select any existing (contextual) filter as the distance location source for the field output, which makes it quite flexible (you can always provide a static default argument in filters or arguments).
** Also streamlined and removed the "extra options", which caused some flaws in the existing code right away (I did not check all existing issues).

* Sort handler
** Also allows to sort on every configured source (filter, argument), so you could even create multiple distance fields, filter on the first and order by the second, quite flexibly.

I do not want to hijack the issue nor the module, so I spare you a long patch for now. But if there's any interest, I'll gladly post it here or elsewhere.

Anyone interested?

attishu’s picture

Hi doitDave,

Yes I'm interested, also anyone who started working with Google Maps using this method. After a point we need a proximity - distance filter to show content properly.
I hope we can update the dev version with your patch.

ciss’s picture

@doitDave If you can spare the time please set up a sandbox (or other repo) with your modified code. Besides I don't think your patch would qualify as hijacking even if it theoretically contains out-of-scope changes for this issue.

ciss’s picture

Assigned: doitDave » Unassigned
Status: Active » Needs work

Setting status back to Needs Work as per #11.

peterbrot’s picture

@doitDave I'm interested to. Your solution could be very useful to me.