Re-implement the Views proximity filter/field for Drupal 8

Hi Samuel,
Good idea. I can perhaps help you with some testing here as a user? Guido

I'll give a stab at this.

Here's initial work. Adds GeofieldProximity function, with an interface that allows interaction with Views. Probably could be abstracted even more so it isn't married to Views usage. Still need to port all the classes, update views plugins to use plugin manager.

Doing this for personal project, so I'll work on it in my off time.

Here's more. Tomorrow I'll update issue summary to reflect work and what needs to be done.

Boom! Got the field to work in Views using a custom proximity filter I created using Maxmind GeoIP. Now just needs final touches for port.

One more, this fixes the sort field.

Todo

1. Fix Filter views plugin
2. Implement each of the previously used filter plugins

I don't know much about all the new Drupal view plugin stuff. It's still highly confusing for me. Nevertheless I tried to take this a little bit further and repair the view field plugin. Perhaps my commits are helpful for somehow more knowledgable:

https://github.com/rgpublic/geofield/commits/filter-fix-experimental

All my commits today at least bring finally back the filter handler dialog somehow... It's still complaing about a missing "geofield-proximity.html.twig" though. Don't know what this is good for. The most important part I'm still missing is the exposed filter (Plugin/GeofieldProximity/ProximityExposedFilter.php). Don't know what's needed here.

Curious if anyone is still working on this or better yet, if anyone has it working? I'm new to Drupal and have been poking around to get the proximity filters working without any luck so far.

Alternatively, if someone can point me in the right direction that would be much appreciated. Coming from WordPress to Drupal, big learning curve.

Please say if this is not the place to ask this question.

Has this been fixed for Geofield 8.x-1.0-alpha2?

I cannot see the proximity field nor the filter to expose on a view. I can only see the geofield point to display.

https://www.drupal.org/node/2819577

Thanks,
Polly

#10, @polly, I am also (still) looking for the same stuff. It appears to me that the the patches did not make it to the alpa2. Did you try all of the patches #4,5,6,7 on both the dev version and the alpha2 version? Perhaps query tagging is an interesting solution. You can do much more with that but you have to write a module for that. Unfortunately I am not a php-coder. I am also interested in what your geostack look like. I am using geofield, geocoder, address (and I am testing with leaflet and styled_google_map.
Cheers Guido

Guido

I only tried update #7 with alpha2.

For now I have replaced geofield with geolocation. The proximity works! However, I have yet to work out how to populate geolocation (with geocache). Luckily I have very few nodes to geolocate so can do this manually for now.

I am displaying a simple nearest node locator view list - so not using mapping.

So I came across the need for this filter, have put together some work on it. The patch attached includes the work done in the fork mentioned in #8, then a bunch of further work by myself tying the last things together.

I have concentrated on getting the manual entry proximity filter functional, and have it working (just!) enough meet the goals on my site.

To do this, I have needed to pull in Geocoder module. I think that's how the D7 version did it? Though I see the D7 code has some nice wrapping... that can be a later task for now I think.

Will need to list that dependency somewhere, if we're going to roll with that.

@amoebanath, thanks for your efforts in moving this issue forward. I'm anxious to see Views proximity filter working in D8 Geofield. I'm happy to test when you've got something ready.

@amoebanath I'm not having any luck applying the patch on the latest alpha, dev, or that fork in #8. Can you please provide some guidance?

Hey
It should have been written against whatever was the latest dev commit at the time. If you check out a commit from around that point in time you should be able to apply it I reckon?
Unfortunately it's not an easy one to just re-roll :'(
Should have done some interdiffs...

Hi,
I was able to apply patch #13 to current module version 1.0-alpha2 after removing the very last line ("2.8.4 (Apple Git-73)+GitX" - Linux commandline patch had problems with that).

After flushing cache, proximity filter is available in my testview - and it seems to work correctly!

This happened on Drupal 8.2.4.

What else is necessary to get this change into dev?
More testing?

I have done a little more work on this feature. My work is based on the work done in #13.

• I corrected an error I was getting due to lack of schema definition for the views proximity field.
• I cleaned up some of the classes
• I added another proximity plugin to support lat,long coordinates as the origin point.

Because the majority of my testing was on the lat,long field, I was only able to confirm that the lat,long plugin works for filtering, sorting, and as a display field.

+++ b/src/Plugin/GeofieldProximity/ProximityManual.php
@@ -0,0 +1,72 @@
+    $locations = $this->geocoder->geocode($target_location, array_keys($plugins));

We can skip the array_keys call here. Geocoder->geocode already calls array_keys on $plugins.

Calling array_keys twice results in a PluginNotFoundException exception.

Other than this fix, patch in #18 works perfectly. Thanks @chrissnyder.

A few fixes to make sure distance2 is set.

The changes in #21 cause that it is not possible to use operators with only one value (e.g. < 10 km), or operators where two values is used and one of the values is 0 (e.g. between 0 and 20 km). The updated patch contains a rewrite of acceptExposedInput() - see the interdiff. It is against dev.

Hi all, I want to put some effort in here to check this out again. Which Geofield version with which patches will work or should work and can be tested. Some guidance will be very welcome.
Thanks Guido.

@guido,

My patch in #21 was rolled against the 8.x-1.x development branch. So you can checkout that branch from git or download the development version from the project page.

@beltofte,
Applied the patch (phpStorm), no prob. However cannot find the filter in Views... (Filter Criteria or Exposed Filters...). A small hint would be nice...
thanks Guido

@guido,
Have you added a Geofield to your content type?

I have access to "Proximity (field_geofield)" when adding a filter in my view. There should also be a contextual filter, but that broke my view and Drupal installation last time I tried that. Have not looked into that problem yet, as the current project I'm working only need an exposed filter.

@beltofte,
Yes, I have 3 ARTICLES that show ip on a leaflet Map. My USERS have a geolocation too. So am trying to show ARTICLES within a specific proximity of the current USER. I checked if the patch was applied (=ok).
The "Proximity (field_geofield)" is just not there in the list when adding FILTER CRITERIA.
Guido

@guido,
Then will you need to use the contextual proximity filter. As I wrote previously did it break my view - might be mis-configuration or bug. Did not have time go deeper into the issue.

@beltofte, thanks for your efforts but I was working on this previously and made interdiff for #20.

I also fixed some other small issues.

Wrong file names.

@matroskeen,
ok, so how does this work.. use the patch geofield_views_proximity_filter-2654360-29.patch against the latest dev version?
Does it work also for exposed filters?
Thanks for helping me out, Guido

@gdelver@xs4all.nl

1. Create a new view with entities that have geofield values.
2. Add filter criteria by Proximity.
3. Set origin point and unit.
4. ???
5. Profit!

Didn't test with exposed filters.

Patch #29 does not apply with latest dev version, could you re-submit a patch against latest dev?

@pebosi I made a new patch, based on #29, which should apply to the latest dev version.
I don't know if it's related but I have this error each time I try to add a proximity filter:

Drupal\Component\Plugin\Exception\PluginNotFoundException : The "ArcGISOnline" plugin does not exist. dans Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (ligne 52 de /../core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I made a typo it previous one...

I don't know if it's related but I have this error each time I try to add a proximity filter:
Drupal\Component\Plugin\Exception\PluginNotFoundException : The "ArcGISOnline" plugin does not exist. dans Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (ligne 52 de /../core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Never mind, it was related to #2841914: Geocoder::geocode() is looping through provider labels not the plugin_id which have been fixed already.
As I have no error applying patch #35, could this be flagged as RTBC?

What am I missing?, with the -34 patch I don't see any views field/filter/sort in the backend. There is no .views.inc file in the patch, is that right? Is the views data handled differently now? I already did drush @sites cr, something else required?

@protostruct You should have a "Proximity" field/filter/sort if your view has entities with a geofield.

There is no .views.inc file in the patch, is that right?

Yes, that's handled by views plugins: you should have these 3 files:
/src/Plugin/views/field/GeofieldProximity.php
/src/Plugin/views/filter/GeofieldProximity.php
/src/Plugin/views/sort/GeofieldProximity.php

@protostruct I have the same problem.

I have installed 8.x-1.x-dev version of geofield and applied patch from #35 cleanly.
Flushed all caches and took a look at my view - I was still only able to add the geofield itself - no proximity anywhere

@protostruct @mmmartin My bad! .views.inc is actually missing in the patch #35. As well as other ones.
Here is a new patch.

Wow, thank you very much for your quick response!

Credit for #52 should go to Matroskeen, which actually made this patch. I only fixed it to apply to the last dev.

Will it be possible to create a "Filter criteria" grouped with a list of distances ?

I applied the patch, but I encountered an error (see the screenshot)

@zenimagine Have you installed geocoder module?

@camdarley Yes, but I uninstalled it. Should the installer?

@zenimagine Yes, the patch require Geocoder (in order to let user enter an address in the filter input).
I should add the requirement to the patch though...

@camdarley

Thank you it works after installing "Geocoder 2.x-dev" and apply the following patches :

            "drupal/geocoder": {
                "Incorrect config schema for geocoder.settings": "https://www.drupal.org/files/issues/2824802-geocoder-schema-fix-2.patch",
                "Don't add third party settings when geocoder method is none": "https://www.drupal.org/files/issues/geocoder-omit_third_par$
                "Convert module to use short array syntax (new coding standard)": "https://www.drupal.org/files/issues/short_array_syntax-2$
                "Remove admin variables when uninstall": "https://www.drupal.org/files/issues/remove_admin_variables-2833058-2.patch"
            }

How do I display a filter to search for an address and Exposed Grouped filters with distances ? For example 10 km, 20 km, 50 km, 100 km.

With the group filtering criteria, how to expose the field "from" ?

Proximity filter label is not displayed.

Please lets drop the "required = TRUE" on the origin field of the sort plugin ! :)
Totally disables it for me, and I don't see the need to enfore a value.
(Or set the default before loading the value through the proximity plugin->getSourceValue.)

I've been working on the ProximityExposedFilter plugin for my client, so yes I make it work easily, but not in a generic way.
Because that would require an ajaxified dropdown to select the filter on the handler config form. Smells like a lot of work, but in the end that would make the whole thing really useful. Often, I think, people want to sort related to an address entered for filtering..

My approach now finds the first exposed proximity filter. The cheap alternative..

And still this stuff has an interface problem: ViewsHandlerInterface does not expose the ViewExecutable itself, so I am accessing it through "existent" public members of the $views_plugin object. Not that nice eh.

Sorry, broken patch file, this one is better. I also note that the 61+ patch does not apply on a regular composer installed module, because the .info.yml file is modified by the packaging script. So you need to add the git repo to your composer.json...

@protostruct Does the patch make it a bulk proximity filter? As in the capture of my previous message.

Here is a solution but for drupal 7 :

https://www.drupal.org/node/2161051

Any suggestions on getting this to work as a contextual filter? I'm getting a broken handler error though it works fine as an exposed filter. I'm trying to create a REST API with distance/proximity as a filter.

To what branch/version should the patch of #67 be applied?

I'm having issues applying it.

geofield 8.x-1.0-alpha6
small reroll needed

patch -p1 < geofield_views_proximity_filter-2654360-63.patch
patching file config/schema/geofield.schema.yml
patching file geofield.info.yml
Hunk #1 FAILED at 4.
1 out of 1 hunk FAILED -- saving rejects to file geofield.info.yml.rej
patching file geofield.module
patching file geofield.services.yml
patching file geofield.views.inc
patching file src/Annotation/GeofieldProximity.php
patching file src/Element/GeofieldLatLon.php
patching file src/Element/GeofieldProximity.php
patching file src/Plugin/GeofieldProximity/ContextualProximityFilter.php
patching file src/Plugin/GeofieldProximity/GeofieldProximityBase.php
patching file src/Plugin/GeofieldProximity/ProximityCurrentUser.php
patching file src/Plugin/GeofieldProximity/ProximityEntityURL.php
patching file src/Plugin/GeofieldProximity/ProximityExposedFilter.php
patching file src/Plugin/GeofieldProximity/ProximityGeocoder.php
patching file src/Plugin/GeofieldProximity/ProximityManual.php
patching file src/Plugin/GeofieldProximity/ProximityManualLatitudeLongitude.php
patching file src/Plugin/GeofieldProximity/ProximityOtherGeofield.php
patching file src/Plugin/GeofieldProximityInterface.php
patching file src/Plugin/GeofieldProximityManager.php
patching file src/Plugin/GeofieldProximityManagerTrait.php
patching file src/Plugin/views/field/GeofieldProximity.php
patching file src/Plugin/views/filter/GeofieldProximity.php
patching file src/Plugin/views/sort/GeofieldProximity.php
patching file templates/geofield-proximity.html.twig

I am also getting a Broken handler for the contextual rules filter when the patch is applied like @DevPilot.

All this patches should be sticked/packed to a specific release, and not to the dev, as they will need to be rerolled all times the dev goes further.

I need to further investigate before attributing this to the patch.
I also want to note that once I install this patch I get:

Drupal\Component\Plugin\Exception\PluginNotFoundException : The "ArcGISOnline" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (ligne 52 in /../core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

The new geofield 8.x-1.0-beta1 version of the module has been just issues, with important code base updates in the direction of better drupal 8 and php coding standards.
It would be great if this issue patches might be rebased (and sticked) on the new beta1 release.

@itamair, after upgrading to beta1, I'm seeing this:

PHP message: Error: Call to undefined function Drupal\geofield\Plugin\views\filter\geofield_proximity_views_handlers()

Looks like the module currently calls that function 6 times but the function doesn't exist.

src/Plugin/views/filter/GeofieldProximity.php
33:    $proximityHandlers = geofield_proximity_views_handlers();
157:    $proximityHandlers = geofield_proximity_views_handlers();

src/Plugin/views/field/GeofieldProximity.php
27:    foreach (geofield_proximity_views_handlers() as $key => $handler) {
50:    $proximityHandlers = geofield_proximity_views_handlers();

src/Plugin/views/sort/GeofieldProximity.php
25:    $proximity_handlers = geofield_proximity_views_handlers();
70:    $proximity_handlers = geofield_proximity_views_handlers();

Seems to have been removed in this commit a while back: https://cgit.drupalcode.org/geofield/commit/?id=7a0554459c26fad41489fcbb...

EDIT: Oh, I see, this is a known issue with the patches here attempt to address.

@mcrittenden it seems that same problems were already present in the alpha6 release.

All my work that upgraded the module from alpha6 to beta1 didn't change that anything in the GeofieldProximity View classes, besides better coding standards and PHPdoc ... indeed because I already noticed that all this stuff in the module section is super outdated (as the original issue message says). And actually I didn't have time (so far) to look deeper to this.
Indeed I added this as a priority in the Roadmap section of the Readme.md file
and I am here inviting all the most active followers/contiributers of this issue to rebase all their most valid work to the actual beta release,
so that it might be continued efficiently ...

@itamair Makes sense, my fault, I was thinking at first that it was a new issue that got introduced with beta1. Thanks for your hard work!

Here's a patch that should apply to the latest 8.x-1.x branch as of today (i.e., 8.x-1.x-beta1). I'm not getting valid results yet but I *think* that's because of my setup rather than an issue with this module. I'll continue to test.

ok @mcrittenden ... it looks nice/great step forward.
Tnx! ...
But in this meanwhile, just the following observations:

• why are you adding the Geocoder dependency in to Geofield? I think we should avoid this, as has never been the case (even in D7 version ...). What would we need Geocoder for? I had a (very) quick look, without finding any Geocoder Service/Method injection, apparently. Am I wrong?
  It is actually Geocoder instead depending from Geofield (in its geocoder_geofield submodule)
• I would consider to move all common functions from the .module to a generic geofield.service, as public methods or static ones, as it is really adviced in the D8 / Symfony coding patterns. I just did this in the last days deploy of the beta2 Leaflet module (@see leaflet.service)

Looking forward of seeing at your progresses.

Ah sorry @mcrittenden I now see that the Geocoder inclusion is far more antecedent of you amends.
I will try to check it better then

I made some more investigation and discovered that there is still a lot to do here.
First of all here is a new updated patch that still applies into the actual beta1, but that fixes some incorrect parts of the existing last patch:

- remove the dependency from the Geocoder module, that shouldn't be, and that might become optional, once (and if) the geofieldProximityGeocoder plugin will be re-implmented here;
- remove any reference to a totally un-existing Drupal\geofield\Plugin\GeofieldProximityManagerTrait;

From this on, a lot of fundamental work is still needed and requested to reproduce/replicate the GeofieldProximity functionalities present in the D7 version into the D8 patterns ones.
It means at least the following ones:
- define a GeofieldProximity Plugin type and a working Drupal\geofield\Plugin\GeofieldProximityManager (with Interface)
- implement initial, and more sophisticate, GeofieldProximity Plugins;
- recreate or move all the existing common functions, now presented/drafted in the .module file, as public or static methods into a Geofield Service class, that might be a brand new one (general helper Service) or (probably better) itself the existing GeofieldBackendManager one. These method would (and should) be injected with dependency injection into the classes (geofield proximity views plugins or whatever) that are going to use them.

Of course all this should be implemented complying strict Drupal and Php coding standards.

Good-willing and solid D8 coders are really welcome to support this roadmap !

Hi,

I'm currently looking for a views proximity filter solution, so I landed on this issue page.
Installed GeoField 8.x-1.0-beta1 and applied patch#83, but no proximity filter comes available.
I don't recieve any errors...

On "composer update drupal/geofield:1.0.0-beta1" it seems patch should be applied.
- Installing drupal/geofield (1.0.0-beta1): Loading from cache
- Applying patches for drupal/geofield
https://www.drupal.org/files/issues/geofield_views_proximity_filter-2654... (Adds views proximity filter)

I'm running:
Drupal core 8.4.4
Geocoder 8.x-2.0-beta2
Geocoder autocomplete 8.x-1.0
Geofield 8.x-1.0-beta1
Geofield Map 8.x-1.40

Any suggestions why this isn't working?
I'd really like to check this one out and try to help testing and improving.

Thanks in advance.

as you might/sould be able to get from my previous #83 comment all this is not working at all (we already know),
and that "there is still a lot to do here".
It is not a matter of testing ... but really to re-implement Proximity Views classes in Drupal 8.

Again ...

Of course all this should be implemented complying strict Drupal and Php coding standards.
Good-willing and solid D8 coders are really welcome to support this roadmap !

Ok, I misunderstood your comment then for which I'm sorry.

No problem. Thanks for your goodwills anyway

Taking a look at this, what sort of workflow are you expecting the base plugin to support? I'm thinking something along the lines of:

1. Instantiate the class.
2. Set the origin using a standard unit (metres? kilometres?).
3. Calculate distance to a point given as a parameter in the same standard unit.

This is based on the use-case of a view where the origin is common but each point needs to be calculated separately.

Future classes could extend that to take into account the various units we want to support.

IMO I think we should try to analyze and replicate at least the same functionalities now present in the D7 version of the module.
It means to look at that code, and try to reimplement it with D8 patterns and (strict) coding standards, and of course Plugins & PluginManager Services system.

Yeah I got that part thanks, I'm trying to figure out if you have any preconceived ideas of what the interface should contain. If the answer is no then I can have a crack at it and see what you think, but it's good to check first :)

For the interface too, indeed, the Drupal 7 implementation of Geofield Proximity would be a good suggestion to start from ... (and just reproduce).

Ok, so here's where I'm stuck.

The D7 implementation and the half-built D8 implementation both use the database to do the calculation of proximity - passing a WHERE clause to the query.

If we want to continue using the database engine to do the calculations, there is little point creating a plugin that can be used anywhere as the WHERE clause is quite specific to the views use-case.

Are you happy for the plugin to do the calculations directly on the web server without involving the database?
The plugin could be used to generate a calculated field which I think would then be subject to a normal numerical filter.

Thoughts?

Are you happy for the plugin to do the calculations directly on the web server without involving the database?

I am not sure I got it ... but it sounds strange and weird to me.
What do you mean "calculations directly on the web server without involving the database"?

Differently from Drupal 7 coding patterns ...
All the recurring operations/methods (among entities fields values, or whatever) should be run relying on contrib or custom Drupal 8 (Symfony like) Services.
All D8 specific classes (might them be a Router, a Controller, a Plugin, whatever ... ) might/should embed and use those Services and their specific methods. Custom Services might depend from core or contrib Services to specialize their application logics.
A Drupal core "database" service is specifically dedicated to the connection to the database.
But sincerely it's hardly and very rarely needed in D8, as it is ...
The "entity.query" Service is the Drupal 8 version of EntityFieldQuery in D7 ... and might be used to run queries.

Geofield module needs to strictly rely on D8 OOP coding patterns and all is components should be developed with solid background and skills on all these coding patterns (and drupal/php coding standards).

@Darvanen I am confident you have already developed D8 modules & solutions based on advanced use of Services and Plugins APIS. Is it?
Because here really would be the case ...

Yes I have already built several things using Drupal 8 including a custom pathProcessor which is injected into several components of a company project I'm working on. I'm very familiar with dependency injection, services and OOP. I'm a tiny bit shaky on making new plugin types but have made custom blocks using plugins before.

My concerns arise from how the views filter is implemented.

The views filter as it is currently written uses the query() method to inject a WHERE clause into the view's SQL:

$this->field_alias = $this->query->addField(NULL, geofield_haversine($haversine_options), $this->tableAlias . '_' . $this->field);

This means all the module is currently doing is providing the text for that where clause. It can only be used by the database:

$formula = '( :earth_radius * ACOS( COS( RADIANS(:origin_latitude) ) * COS( RADIANS(:destination_latitude) ) * COS( RADIANS(:destination_longitude) - RADIANS(:origin_longitude) ) + SIN( RADIANS(:origin_latitude) ) * SIN( RADIANS(:destination_latitude) ) ) )';
...
$formula = str_replace(':' . $key, $option, $formula);

To create a plugin means we need a more generic and robust way of calculating the proximity without relying on the database, that's all.

If the proximity filter is ONLY ever to be used as a views filter, then a filter plugin will do the job perfectly well. I assumed you wanted a GeofieldProximity plugin type so that proximity could be calculated *anywhere* that the service was injected, am I wrong in that assumption?

Here's an interdiff of the changes I've worked on so far (much of it is boilerplate).

Obviously this is not working code yet, it's a work in progress.

tnx @Darvanen for your effort.
I just wanted to assure the correct D8 coding pattens are used.
I didn't want anything special or specific because I didn't investigate further this Views proximity filter/field/sorter for Drupal 8.
I am sorry I don't have now time to contribute on this as I am mainly engaged on some nice enhancement on the Geofield Map module side.
But I will be able to review your code and test your working results, when you reach something ... solidly working.

Last advice I feel to give is this:
might the code and approaches already implemented in the Geolocation module be of any help?
I had a very quick look and I noticed it embeds and uses its own geocoder services somehow/somewhere.
The Geofield module might replicate and grab approaches (we are in Opensource) BUT should not depend from Geolocation module, even optionally, in any way as it seems to be a parallel (sort of competing) module.
Instead Geofield might depend optionally from the Geocoder module to use its services just when they are needed: i.e: in the D7 version of Geofield I see a "Geocoded location" option (relying on a geofieldProximityGeocoder plugin) just available if (module_exists('geocoder')) ...

So ... good work from me, and tnx again for your time and effort.

Alright, thanks mate, I'll take it from here :)

And, still, let's bear in mind that an exactly replication/porting into D8 patterns of the Views proximity filter/field/sorting functionalities (functions, classes, plugins, etc) now present in the D7 version would be the first and the best accomplishment for this thread.
Further improvements might be then faced afterword ... and more probably in a brand new issue (IMHO).

Ok I've run out of steam on this one.
Here's a work in progress that provides a generic proximity calculation service and a plugin manager framework to create more of them.

@Darvanen tnx very much for your effort.
Your patch applies nicely ... although forcing the substitution of some existing files (if proper and opportune substitutions they are welcome).
I have no time to widely test all this, and would have been a "nice to have" some more details on the expected results from your progresses: what should work now and what still not exactly?

But more than that I quickly noticed that some strange insertion are present and drupal & php coding standards are somewhere missing.
I might be wrong, but my first evident concerns are the followings;
- views.filter_value.geofield_proximity schema is inserted in the middle of other keys definitions: why not at the end?
- in the geofield.module file new added functions are missing proper phpcs Doc Comments ...
- some commented code lines left in the src/Plugin/views/filter/... proximity classes

Your work seems quite nice, but looks and feels still half-ended (or some more ...) and probably risk to remain almost useless in this form.

Would be nice if you find some more steam to optimize your patch fixing the above mentioned matters, and leave some further indication / details for other good willing D8 developers that might have new fresh steam and energy to test and even continue/complete your work ...

Hi @itamair I agree that it's very incomplete, I was hoping that someone could pick up the framework and run with it but on reflection it's still missing the glue to hold it all together. I'll try to find some time for it but I didn't want to leave it assigned to me while I wasn't actively working on it.

Hi everyone.
Here's a patch which provides working proximity field/filter/sort view handlers.
Based on geofield_views_proximity_filter-2654360-100.patch.
Views handlers are very basic. They work but filter plugin doesn't allow user to specify the point of origin. However on particular project it's possible to implement custom origin source plugin (by implementing GeofieldProximity plugin).
Views handlers are attached to the field, so can be used on any entity type. But works only on configurable fields for now.

A little fix for my previous patch (comment #104).
This fix avoids a view crash if proximity value is not available (now it just renders empty field).

tnx @mpolishchuck ... patch applies cleanly into 8.x-1.0-beta4.
Let's wait for user reviews on this. I will too asap ...

@mpolishchuck I made a very quick review.
Tnx again (from the community ...).
I can confirm that the patch applies cleanly and the code standards are quite ok (although still to be optimized) but the matter is that still this is an incomplete solution, and would be nice to know also how much incomplete this is.
Your description gives a clue, but is very synthetic.
Referring to the base target that should be achieved (expressed in my #99 comment)
would then be very useful to have described the following:
- use cases the user is able to accomplish with this patch implementation (i.e.: the user can add a sorter indicating a distance, in specific units, and a geographic point, and with which limitations);
- use cases the user is still NOT able to accomplish ...
and that still need to be addressed.

All this would properly drive the patch review, and help the involvement of other good willing developers.

@itamair
Some info about my patch #105

- User can add proximity field to the view. User is able to specify the proximity value rouding and add prefix/suffix to it. Also he can specify decimal point character and thousand separator.
- User can't use click sorting for the proximity field (it's not implemented)
- User can add proximity filter to the view. User is able to select one of the operators: <, <=, =, !=, >=, >, between, not between. For between and not between operations filter requires two values: min and max.
- User can add proximity sorting (asc or desc).
- User can specify measure units (kilometers, meters, miles, yards, feet, nautical miles), but only in handler settings, so it can't be exposed by the proximity filter.
- User can't specify origin point using the exposed form.

Proximity will be measured from the origin point to the point in the geofield. Using the default proximity plugin implementation user only can manually specify origin point in the handler settings. Developers can implement their own proximity plugins so origin point can be specifiedin some other way, for example extracted from user's settings or extracted from some other entity. The proximity plugin has API access to the views proximity handler, so also it has access to the view executable.

As I understand still need to implement the following:
- Enable user to use click sorting on the proximity field.
- Enable user to specify origin point using views exposed form.
- Enable user to specify measure units using views exposed form.

I hope this info is helpful.

great @mpolishchuck, bravissimo !!! ... that's exactly what I meant.
Now it is really much more clear the state of this issue implementation, and gives even more value to your work.
I just briefly reviewed the patch functionalities, that match your description, but unfortunately I am too engaged on other Geofield Map fronts to be able to add operative and practical contribution (so sorry ...).
I like a lot the plugin approach to origin point definition.

I would suggest to still keep a look to the parallel D7 functionalities implementation on proximity filters, to have a nice guideline and base of confrontation, on what still might be implemented and how (D7 to D8 functionalities is not that hard once well/better understood how to manage D8 coding patterns).

All other good willing D8 developers are really welcome to this ongoing party ;-)

Hi, thanks for the patch!

i'm trying the patch #105, i don't understand if i can't configure well the views or if it doesn't do what i need:

I need a filter on the view where i write a name of a location, and then the view shows to me the result within a certain radius from that location.

The geocoder part i can in some way handle by myself, i think, but i see for the views filter only the distance when i expose the filter, but not the coordinates (i would like to expose only the coordinates with a fixed distance, i don't need that the user changes that value).

Is it possible with this patch? Am i missing something? Thanks!

EDIT: oh...sorry i didn't read well

As I understand still need to implement the following:
[...]
- Enable user to specify origin point using views exposed form.
[...]

Sorry

Fixed some wacky layout introduced by #13 which causes field label and description to double up.

I needed an exposed filter with a text field that would be geocoded, like "Within 20 km of Lille, France". But I had not much time to make a proper generic patch. I coded something upon the given patch and the Geocoder module. I just paste it here in case it can help anyone: https://gist.github.com/gaelg/30947b310403bf13459eb85227897eaf

@GaëlG

Please remove the code, create a patch or create something like a Gist. It is unhelpful as is and clogs up the page.

@dpi You're completely right, Gist was the right tool for this. Sorry!

I'm testing the patch from #112 on an existing map view with leaflet.

As soon as I try to enter the "Coördinates: Proximity" with a "smaller than x kilometers" settings, I get the following SQLSTATE error:

SQLSTATE[42000]: Syntax error or access violation: 1582 Incorrect parameter count in the call to native function 'RADIANS': SELECT COUNT(*) AS expression FROM...

@GaëlG

Thanks a bunch for sharing your code solution. Quick question, I have a REST view where I pass in filter criteria as URL parameters but need to filter by proximity and was wondering how difficult it would be for me to edit your code to accept the radius, long, and lat values as URL parameters instead of exposed form fields? Something like getHotels?_format=json&radius=10&lat=-81.5660627&long=28.385233

@cybersoda My code just adds the ability to transform a postal address into coordinates used for the filtering. In your case, you would pass the coordinates directly in the URL, so no need for a geocoding tool. So you'd better look at the patches provided in this thread rather than at my code from #113.

Are there some news about this issue:

- Enable user to specify origin point using views exposed form.

I have the same usecase as #117. The only solution I see currently is to switch to geolocation module as long as there's no further support for this requirement. Right?

I might try to get more through this in the next days ... and see if I can pull any rabbit out of the cylinder.
But I should say that this is not in my to-do priorities .. .
Every contributor is really welcome to help this issue at least reach its acceptable usability status ...

Thanks @itamair! I really appreciate it!

Hi all ... just to inform that I started better focusing and working on this.
At the moment the #112 patch still remains the most usable solution and step beyond for Proximity functionalities in Geofield D8,
but in the next days I should be able to deploy a more complete and more scalable solution on this.
Stay tuned ;-)

@itamair That's great news, many thanks. This is an important feature that can help many sites.

I faced the bug mentioned for D7 in #2761811: NULL SQL result with Haversine formula, zero expected. Here's a patch upon the patch #105
https://gist.github.com/gaelg/4466550a8d66d77a66271dc854b534ec

Hi folks ... just a very temporary and draft update, here is a (only testing purposes) improved patch,
that refactors and evolves a lot from the previous (best) #112.
The main operative achievement is that now the Proximity Filters should expose and work correctly as Exposed Filter allowing the user to dynamically change the Origin Coordinates.
It seems to properly work also with between operators and in ajax.

If you want to try, and start reviewing ... feel free, but just keeping in mind that I am still focused on this, and a good amount of work will still be done, till the first dev commit of all this ...
It means classes and methods and interfaces will/might change to consolidate and make the inner Geofield Proximity handlers plugin system fairly solid and scalable, for the public use and evolution.
Cheers.

Sorry made a little mess with file upload.

geofield_views_proximity_filter-2654360-125.patch

and

geofield_views_proximity_filter-2654360-127.patch

have the same content

Thank you itamair :)

Hi folks!
A lot of work has been done on this, that (finally) brought to a solid version of (New) Drupal 8 Geofield Proximity View (Field, Filter and Sort) Handlers System. Let's move all there for further discussions, reviewing and integrations.