This patch adds another Views filter plugin which extends (subclasses) the existing geofieldProximityGeocoder class, so that instead of inputting a postal address the visitor may leave the field blank to filter the View on locations within the entered distance from the visitor's CURRENT LOCATION.

See the screenshot, where the filter was used to filter a View Page (map) + View Attachment (the table underneath, reflecting the map).
in the map the green marker represents the visitor's current location, while the remaining markers are the locations after the filter was applied, with a radius (distance) of 1.5 km.

Geofield HTML5 based proximity filtering

For HTML5 location retrieval this patch relies on IP Geolocation Views and Maps.
The module uses Smart IP as a fallback, executing an IP address lookup, if the HTML5 (satellite and WiFi) based location retrieval fails.
That same module also produces the map in the screen shot and the configurable markers.

Apply the patch against the 7.x-2.x branch, using the attached .patch file as normal.
Then also drop the new file geofieldProximityGeocoderWithHTML5.txt in sites/all/geofield/views/proximity_plugins, changing its extension from .txt to .inc

Don't forget to execute /update.php before configuring your VIew.


Issue summary:View changes


Title:Patch adding plugin for proximity filtering based postal address with HTML5 as defaultGeofield plugin to extend proximity filtering based on postal address with option to use HTML5 location
Status:Active» Patch (to be ported)

PS1: naturally, if in addition to a distance figure (the 1.5 km in the example above) the user DOES type a street address or partial street address (e.g. just "Melbourne"), then this new plugin falls back to the old geofieldProximityGeocoder behaviour.

PS2: the above setup requires the Geocoder module

PS3: You can use the "Refine location via street address" block from the "IP Geolocation Views and Maps" module to display the visitor's reverse geocoded HTML5 position. That is the street address where the system believes the visitor is located, based on the latitude/longitude coordinates the browser/device received via satellite and/or WiFi.

I have done some testing and it seems to be working really well so far. Rik, I have PM'd you with a link so you can see your work out there in the wild.

Status:Patch (to be ported)» Needs review

Nice! At a glance, looks good, I'll take a look later to provide notes/commit.

@Brandonian #3:

Some notes from me:
The plugin as it is has a conditional dependency on "IP Geolocation Views and Maps", via if (module_exists('ip_geoloc')) { ... .
This is a quick fix that works, but isn't great architecturally.

This could be improved by having Geofield expose a hook that allows other modules to pass in lat/lon of the default point of interest, be it the visitor's current location or an externally geocoded street address. That hook may also be used in existing or future sections of Geofield code. I for one would love to take advantage of it in a proximity CONTEXTUAL filter for Geofield, which could then be driven by Views Global Filter. This is functionality that already exists between Views Global Filter and the Location module.

Alternatively, using a hook or CTools plugin approach the proximity plugin system in Geofield could be made more extensible, so that the above plugin could live in the IPGV&M module. This is pretty much what was requested here also: #1991828: Provide a hook_proximity_views_handlers such that other modules can implement a proximity_views_handler.


after applying this, I did as the filter config picture says.

I get this error:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'A' in 'where clause'

part of the views query:
AND (( A * ACOS( COS( RADIANS(45.3101717) ) * COS( RADIANS(field_data_field_geofield.field_geofield_lat) ) * COS( RADIANS(field_data_field_geofield.field_geofield_lon) - RADIANS(-89.0166135) ) + SIN( RADIANS(45.3101717) ) * SIN( RADIANS(field_data_field_geofield.field_geofield_lat) ) ) ) <= A) ))

Have you run update.php?

I have to say that we have been running this patch for the last few weeks without issue. @SocialNicheGuru when you get a chance, can you follow up to see if running update.php fixes your issue, so we can push this patch along?

This patch worked great for me as well, it threw an error until I ran update.php, so that might be @SocualNicheGuru issue.

I have tried this recently and I keep getting "Visitor Location not available" - I can see this is called from the new .inc file - does this suggest something wrong with the geolocating?

go to admin/config/system/ip_geoloc and make sure you select some user roles for which the HTML5 location may be sampled and reverse-geocoded to a street address

the above works. I re-installed and applied.

Status:Needs review» Reviewed & tested by the community

maybe it is better to put a "my location" button there, so that the user can easily locate to the current position anytime. just like the geolocation field widget.

Agreed that a "My location" button would be a good prompt.

Issue summary:View changes

mention branch to use

Re #4 RdeBoer-

Alternatively, using a hook or CTools plugin approach the proximity plugin system in Geofield could be made more extensible, so that the above plugin could live in the IPGV&M module.

I think that's what is being requested in #2134777: Allow other modules to define their own proximity plugins which would then make it easy for this to live in IPGV&M.

I really need the "My location" Option, anyone has any idea or can point me where and how to modify the code to accomplish this?



  • I would like to confirm that this patch works as described.
  • Feature Request to pre-populate the field with the visitor's city and state data as text.

Thanks RdeBoer this is going to help my site shine.


Re #17:
That's sweet of you to say Jay!


Is this going to get committed?


Hi Jay,
I don't know. It's not up to me, as I'm not the maintainer of Geofield and do not have the permissions.
Brandonian may know.

This seems like a really helpful enhancement.

Are we at all close to getting this committed?


I have tried the patch, and it seems quite good but I have 2 questions:

- When the user inputs an address, the proximity field seems to provide the distance from the user, not from the address that was input

- When the user inputs an address, the map is centered on the user's location, not the location that was input

Perhaps these issues are related, and perhaps there is some user error involved?

Is there something I should be doing differently on my end?

I am getting a lot of this warning, Anyway to debug the reason for this or how to improve the location detection?


@jsibley have you found a solution? I also need to center the map on the input location.

@rofsky, I haven't found a solution yet, but I might have a clue.

I don't know the internals of Drupal and of views well, but I think that the patch takes care of filters and sorting in views, but might not have patched where the actual field that gets displayed.

When I look at the SQL returned by the view and put in a location as an exposed filter, I see the values for the filter change, but the value of the field does not.

So, here is what I see for the field after I have put an address into the exposed filter:

( 3959 * ACOS( COS( RADIANS(40.813642200000004) ) * COS( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lat) ) * COS( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lon) - RADIANS(-74.21709899999999) ) + SIN( RADIANS(40.813642200000004) ) * SIN( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lat) ) ) ) AS field_collection_item_field_data_field_address_plus_phone__f

Here is what I see in the filter:

where ......(( 3959 * ACOS( COS( RADIANS(40.9792645) ) * COS( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lat) ) * COS( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lon) - RADIANS(-74.1165313) ) + SIN( RADIANS(40.9792645) ) * SIN( RADIANS(field_collection_item_field_data_field_address_plus_phone__field_data_field_geoaddress.field_geoaddress_lat) ) ) ) <= 10) ))

The sort uses a label from the field, so it will also be incorrect.

Unfortunately, I don't know where this would need to be changed in the code. Hope this helps, though.


A proper, maintainable solution should be built upon a proper maintainable framework.

The patch referred to above in #15, #2134777: Allow other modules to define their own proximity plugins, sounds like a great start. It's small, easy to apply and not likely to have any side-effects. With that in place I'm happy to re-roll the above functionality with any bits relying on third-party modules, e.g., located there.


Rik, are you saying that once the patch mentioned in #15 is committed, you would be willing to create a new patch with the HTML5 functionality? Would that potentially resolve the proximity field issue mentioned in #22 and #25, as well?

Also, in the meantime, do you know where the proximity calculation is defined?


Well a new patch would not automagically solve the issue. I'd have to investigate first where the bug originates, then rewrite the code and include the fix.

But the great thing about doing #15/[2134777] is that the patch would no longer have to consist of code entangled with Geofield. With #15/[2134777] in place we'd have an even more extensible, maintainable Geofield framework. Geofield is already architected very well -- this last part (or a solution similar to it) would be the icing on the cake for all of us.

Any new functionality of this kind could then added as a stand-alone mini-module or a class, and reside inside Geofield (as a separate file), IPGV&M or another module, wherever it is best suited. #2134777: Allow other modules to define their own proximity plugins already contains a lovely example of such a mini-module.

This keeps Geofield clean while making any extensions separately maintainable, so it does not burden the Geofield maintainers.

Not contributing anything other than to say that this patch works incredibly well for what I'm doing. Hope to see it incorporated in one way or another!

I would love this functionality. Am not confident about applying any patches, so the sooner it gets implemented or a new module created the better. Great work folks. Will follow thread with interest.