OpenLayers Proximity port Drupal 7

I've also posted my interest in openlayers geocoder module. What will it take to get this done?

subscribe

subscribe

subscribe

following

sub

Subscribe

follow

sub

subscribing

I've got a port most of the way done, at the moment it uses geofield for the WKT source.

@jpstrikesback please share so we can help out, tks.

@jpstrikesback LEGEND!

changing title for better tracking.

sub

subscribe

subscribe

@jpstrikesback can you please share the code?

Hey all, sorry to peak your interest and not show results quickly :) I've got code in a semi working state except I'm having serious difficulty getting a subquery with an expression working in DBTNG so I'm trying to work that out at the moment as well as having my project priorities rearranged recently so it may not be until mid next week I can get this done, as that is the case I'll see if I can upload code over the weekend.
Cheers,
JP

Hi,

I am willing to pay for the development of this feature, if we manage to have it done sooner rather than later (and we make sure it fits my project's needs). Please feel free to contact me: dario@secondwheel.org

Thank you.

Hurrah! I'm past the dbtng thing, greater-circle proximity is working, I'll get square going and sort some other things and upload a patch asap (like, mondayish)

Awesome work JP. Hey just for the record, square never worked for me in D6.

subbing

OK, test this patch out, I haven't touched Rules & Drush integrations yet (other than code style) but everything else is working in my testing (as a straight port - i.e. only supports nodes for the time being, tho I'm planning to work on full entity goodness...in the meantime views relationships might go a long way)

Things to note:

- There is a new dependency on Geofield for coordinates & WKT, which means you probably want Geocode as well (the port to D7 is currently here git://github.com/phayes/geocode.git ), this works fantastic with Addressfield.
- The way to use this is largely the same as in 6.x so the tutorials should suffice other than anything drush/rules related

I'd love to hear any feedback and I'm open to maintaining a d7 port as well if that is desired.

Cheers :)
JP

Also @smilne23 I can confirm that square is working for me in D7 (tho you can only use the distance field/sort with circle as before)

Hi,
this patch doesn't work for me :(

I had apply the patch and I had try it on a simple WKT Geofield, but every time I go to save a content the system wrote an error :
Notice: Undefined property: stdClass::$field_geofield in openlayers_proximity_build_proximity_index() (line 244 of /var/www/sites/all/modules/developer/openlayers_proximity/openlayers_proximity.module).
I have a similar error when i try to rebuild index:
Rebuilding proximity index for events 93: Exerci Gemino. 0 location(s) added.
but the contet Exerci Gemino has a valid WKT value.

Any idea?

Tnks

@Carlo, I just tested it all on a fresh site still works for me, can you tell me what your settings for your geofield are? Like what Geocoder are you using? I'm using the Google Geocoder

@Carlo, just incase the patch didn't apply clean you can grab a tarball/zip from github:

https://github.com/jpstrikesback/proximity

cheers,
JP

sub

thanks JP +1

Other options will be available soon. http://gnode.ccardea.com

Subscribing. Any news on this, jpstrikesback? I see there's no commits since the initial on June 30th.

@heivolle it works great for me, I'd love to hear your/others experiences in as much detail as possible :)

Thanks for this! I have some issues in Drupal 7 (I'll make a new issue) but it has to do with the way I'm handling geofield entries for my nodes. Otherwise, this works great.

Hi, question for those who have this module patch up and running for D7:

I obtained the patch from github and then installed. After that, I activated the module from the modules list. However, at the OpenLayers admin page, I don't see the option to "update the proximity index", which is the first step in the tutorials. All of the other functionality appears to be presented as expected.

Any recommendations from others on how to take care of the proximity index update?

tvilms,

You'll find the proximity index option in a new tab to the right of "Maps" on the OpenLayers administration page.

Can we please get another maintainer and a Drupal 7 dev version?

Hi thanks for the reply. Sounds like I need to be on a newer branch of OpenLayers 7.x.

However, I've had troubles trying to update from OpenLayers 7.x-2.0-alpha1 (released 1/14/11) to the latest dev branch 7.x-2.x-dev (released 8/6/11). I get the following fatal error near what appears to be the completion of the update process: "Maximum function nesting level of '100' reached, aborting! in ...\includes\database\database.inc on line 429". I tried updating my php.ini file to get around this, but no luck.

The lesson-learned is that this OpenLayers Proximity port is only good with the 7.x-2.x-dev branch and not the alpha release.

@tvilms, do you have xdebug installed? if so:

find your xdebug.ini somewhere like:
/etc/php5/apache2/conf.d/xdebug.ini
and increase it to something higher than 100:
xdebug.max_nesting_level = 150

@Adam S, yeah I need to apply for co-maintainer in a new issue, will do shortly, in the meantime feel free to file issues over at my github and If I get comaintainer status I'll move them over

@elijahmeeks good catch, I hadn't even thought of that, I'll take a look later this week, feel free to file something at my github and send a pull request if you get into it before I do

Thank you jpstrikesback.

I am starting my first D7 site and if I were not already using OL Proximity and subscribed I would not be aware of this option. So good to see activity with OL.

I hope you are able to apply for co maintainer status and post this version on drupal.org so people can find it and be aware of it.

Thank you jpstrikesback and thank you to everyone who is helping make D7 work.

I am following the tutorial at http://drupal.org/node/1112308.
I configured my content type and added a new view as close to the tutorial as possible (some things have change between 6 & 7)

When I save the view or change the params and select apply I get:
Notice: Undefined property: stdClass::$unknown in openlayers_proximity_handler_field->render() (line 44 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined property: stdClass::$unknown in openlayers_proximity_handler_field->render() (line 44 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of /var/aegir/platforms/therapist-1/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).

Installed modules:
OpenLayers Proximity 7.x-2.x-dev
OpenLayers 7.x-2.0-alpha1
OpenLayers UI 7.x-2.0-alpha1
OpenLayers Views 7.x-2.0-alpha1
Geofield 7.x-1.x-dev

I am trying to create my first Views Proximity for D7. I have OL Proximity working on D6 and followed similar Views settings.

The Geofield is using Google Geocoder and the map is displaying fine on the nodes and an aggregate map.

I also ran Rebuild Index after getting the error but did not fix it.

Getting this error message when the View is saved. First line is:

Notice: Undefined index: location in openlayers_proximity_handler_field->query() (line 38 of sites/all/modules/jpstrikesback-proximity-9a06988/views/openlayers_proximity_handler_field.inc).

Then this error repeats, it appears it may be one error per node, but just a guess.

Notice: Undefined property: stdClass::$unknown in openlayers_proximity_handler_field->render() (line 44 of sites/all/modules/jpstrikesback-proximity-9a06988/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: unit in openlayers_proximity_handler_field->render() (line 46 of sites/all/modules/jpstrikesback-proximity-9a06988/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of sites/all/modules/jpstrikesback-proximity-9a06988/views/openlayers_proximity_handler_field.inc).

When I go to the View path it gives the same error.

And when I hit Apply on the filter, the line 44 error messae appears, it looks like once for each node. The nodes appear with a distance of ZERO for each node.

Attached is a screen shot of the Great Circle filter and a screen shot of the Distance Field.

Thank you.

@jcaustin98 @itserich, what version of views are you using when you get those notices? If not using rc1, can you try with that?

Thanks, I was using Views Dev and switched to RC1.

Still getting the same errors.

Also using:

OpenLayers Dev
Geofield Dev
and Geocode https://github.com/phayes/geocode

Thank you.

I am creating new nodes, geocoded, of the same type in the View. When I save them, I am getting these error messages:

Notice: Uninitialized string offset: 0 in geocode_widget_validate_walkthrough() (line 247 of modules/phayes-geocode-281c70f/geocode.module).

Notice: Undefined property: stdClass::$field_geocode_demo in openlayers_proximity_build_proximity_index() (line 244 of modules/jpstrikesback-proximity-9a06988/openlayers_proximity.module).

Geocode Demo is a content type I have, but it is not the one I am using and it is not contained in the View.

I deleted the content type Geocode Demo and that second error is gone (line 244) when I save a node, but the other errors when the Proxmity View is viewd per comment # 44 remain.

@jpstrikesback, thanks for the tip. I have xdebug installed as part of the LAMP package I installed for my localhost. I added the following to my php.ini file, and after that I was able to update to the latest snapshot of OL 7.x-2.x-dev. Things are much improved now that I've updated! Thanks. Now I can forge ahead with configuring OL Proximity.

[xdebug]
xdebug.max_nesting_level=150

Perhaps mine is a problem with Geocode, as noted in comments 27 & 28.

http://drupal.org/node/1093402

@jpstrikesback I have Views 7.x-3.0-rc1 along with:

Drupal 7.7
OpenLayers Proximity 7.x-2.x-dev,
OpenLayers 7.x-2.0-alpha1,
OpenLayers UI 7.x-2.0-alpha1
OpenLayers Views 7.x-2.0-alpha1
Geofield 7.x-1.x-dev
Chaos tools 7.x-1.0-rc1

OK, IIRC I am errantly advising Views RC1, it has some issues with Exposed filters I believe, try the latest dev snapshot (i recommend doing this on a test site) and let me know how you all fare. Also in my working setup I am using Addressfield as my provider of Address fields, then I geocode those fields using Geofield...I'm doing a bunch of testing so if you feel like sending me a rundown on your content types, fields & a views export in a gist feel free :)

Thanks jpstrikesbak

I upgraded to Views Dev - a Sep 1 version just came out today) and when I save a node it always gives this error message:

Notice: Uninitialized string offset: 0 in geocode_widget_validate_walkthrough() (line 247 of /sites/all/modules/phayes-geocode-281c70f/geocode.module).

When I try to view the proximity view, the error messages from #44 continue to exist.

This is with

OpenLayers 7.2 Dev
Geocode
Geofield 7.1 alpha 4
Address Field 7.1 beta 1

Address Field collects address, Geocode geocodes and Geofield presents to OL (I think that is how it works).

If you would like an Admin access on my site let me know where to send it.

Thank you.

Hope this is enough to duplicate the problem.
git://gist.github.com/1189046.git

I am getting this error message when saving nodes which have no location information. No address field, geocode, openlayers, etc. Just a couple text fields.

Notice: Undefined property: stdClass::$field_location_geocode in openlayers_proximity_build_proximity_index() (line 244 of /all/modules/jpstrikesback-proximity-9a06988/openlayers_proximity.module).

This is the error for nodes which have address field, geocode, and openlayers:

Notice: Uninitialized string offset: 0 in geocode_widget_validate_walkthrough() (line 247 of /all/modules/phayes-geocode-281c70f/geocode.module).

@itserich What is happening is that geocode_widget_validate_walkthrough() is being passed $field['und'] which is supposed to be an array but it is in this case a string $field['und'] = "". This might be a bug somewhere else. I'm getting this with autocomplete taxonomy terms so if it is a bug it is one in core.

Openlayers Proximity also has to account for the case when the Geocode module isn't successful

Subscribing and wondering if D7 port could be added to module on drupal.org and if #1205942: Exposed filter map widget could be implemented in it.

Also I am having same issues as #43 and #44.

Not any more. See fix @ https://github.com/jpstrikesback/proximity/pull/2

Thank you, this works great.

Downloaded at: https://github.com/adamdicarlo/proximity/commit/f378e6b6782afc8b14034d1a...

To avoid messages, be sure to enter a start value in Location in the exposed filter. And to make the filter appear correctly, click to activate the option Expose Operator.

Thanks!

Expose Operator is a must, but in my case default start value is not set and it works without errors, probably because my filters are set to "need input".

Ahh, maybe it is possible with "filling in and submitting form with Js".

I've uploaded a bunch of code fixes to github, check it out, more to come

Thanks jpstrikesback

The lastest release appears to be working fine.

https://github.com/jpstrikesback/proximity

More fixes, if you feel like it please test Locked Operators and Node Proximity.

Thanks to @jcaustin98 for sponsoring these fixes!

Thanks for your great work jpstrikesback.

subscribing

sub

Works like a charm. Thanks @jpstrikesback

Is it also possible to calculate the distance between two geofields? e.g. field_user -> field_location
I've only found the possibility to calculate the distance between a fix location and the node location or a string.

Hey Molnitza,

At the moment there is no capability to (properly) have two separate geofields in the same proximity view (it creates a cartesian product if I recall correctly and I don't think there is any handling for it...unless using reduce duplicates helps but I haven't tested enough), I think this would be really useful of course. Can you detail a little use case?

subscribe

@cesareaugusto no need to comment to subscribe. Use the follow link at the top of the page.

@nicoz sorry I didn't know of that. thanks!

Maybe someone can throw up a 7 dev version using jpstrikesback version? I have it running on a few sites and it's working well. A few rough edges, but works as advertised. With a proper dev release on the project page, maybe it will encourage more testing and patches.

Hey Nicoz, I'll put it in a sandbox this weekend, and then see about maintainership of the D7 branch,

Cheers!
jp

btw, do list the rough edges if you get a chance. I am starting a few new projects in Jan. that will use this so having a list is nice.

@jpstrikesback That's good news! For Drupal 7 what do you think about dropping Open Layers from the name? Proximity could be useful for many types of views, not just Open Layers maps. This would be consistent with Geofield as well.

OK, sandbox is up at:

http://drupal.org/sandbox/jpstrikesback/1367194

This is where further development by me will take place.

I've also sent Antonio De Marco a message to see how to move forward with maintaining a D7 branch and/or moving that branch to the namespace "proximity" (Rickvug, you've echoed my thoughts on the matter)

Cheers,
JP

@jpstrikesback There's an issue for adding basic proximity support for Geofield #1360260: Add views filter to provide proximity search of Geofields. I've chimed in there to see if there's an appetite for declaring Proximity (formally OpenLayers Proximity) the solution when using Geofield.

I tested the D7 code a bit late last week and found that views were working as expected. Looking at the code I did notice that the module implemented its own geocoding. What do you think about relying on geocoder for strings? I really like how in D7 there's now a clear separation of concerns between Geofield, Geocoder, Addressfield and now Proximity. Nice work on filling in the blank spot in the stack!

Thanks Rickvug,

That's definitely on my TODO list as well: axe the internal call to google and replace it with geocoder...tho perhaps for performance reasons it could be an if module exists moment?

You're right - this is the perfect use case of module_exists(). Really the UI in Views should say something like "enable Geocoder to support string based input".

I also don't think that having the module based around nodes makes sense anymore (for views filters, for example). A more general approach of choosing entity type and then selecting the geofield to use would be more flexible.

Rickvug, yep, agree completely, if you feel like sending a patch I'll get it in, otherwise I'll be working on it for sure in Jan. One thing to sort out is multiple Geofields currently produces a cartesian product if I recall

The project I was working on that involved proximity has been put on hold for the time being. If it is brought back I may jump in with a patch or two.

Supporting multiple fields is tricky but the logic seems straightforward. Really what you want to do is filter on a selected field as there are legitimate use cases for multiple locations being attached to an entity (home address and business address, to give one example). This selection would need to be made within the Views UI (select entity first, then which geofield to use). Unfortunately supporting this style of filtering will require a new schema. Perhaps entity id, entity type and field name in place of nid?

Hey All, I've had a little email exchange with Antonio De Marco (the Maintainer of our beloved OLP), as soon as the port is working & testable we should see a branch created for it after he reviews and likes it, if anyone wants to help get the tests upgraded and rules port in that will help (submit patches to my sandbox).

Rickvug, the multiple fields thing may be a misunderstanding on my part of building views queries but we'll see as I get into it more, I think it's a must fix cause you can break things via UI at the moment with the greatness of Geofields. Re: entities, agreed.

Cheers,
JP

JP - I'm happy to hear that Antonio is on board!

That said, I still don't think that Open Layers Proximity is the best name space for the D7 version of the module now that there's no tie to OpenLayers (aside from project history). Would it be possible to have yourself and Antonio as co-maintainers of a new Proximity namespace and point all upgrading Open Layers users that way? For the long term I really think this would be less confusing for users and drive adoption and interest in the module.

@rickvug Geo Proximity?

@mefisto75 Perhaps. "Geo Proximity" could potentially be wrongly linked to Geo module (http://drupal.org/project/geo), but then again the name is quite general. I'm not too picky about a name, I just think that keeping the link to OpenLayers gives users the wrong idea. It would be great if OpenLayers, Gmap, Bing maps and all other mapping projects all ran off of views, with geofield providing the data and Proximity (or Geo Proximity) providing the proximity filtering if needed. Having OpenLayers in the name doesn't lend to that kind of consolidation.

+1 for getting this project on d.o and changing the name.

Between the ones above I vote for Proximity. But if the main integration is through Views, maybe it could also be Views Proximity…

Installed D7 github version, works like a charm - have yet to encounter any issues!

However, I was wondering if there were plans to allow setting the LOCATION field (like SESSION variable using SmartIP)? That way location-specific nodes could be filtered based on proximity to user location? Or would this require a custom module?

Cheers,

R

Many thanks for all the hard work that has gone into this module. I am also running the git version (grabbed today) and so far no issues. I did upgrade from the previous version.

I was wondering however, I use search api and views to create faceted views (from search api indexes).
How would it be possible to allow for proximity filtering in search api indexes?

As far as I'm aware, the proximity filter option is only available to views based on content (nodes) not any other indexes. But for my facet blocks to show I need to create a search api index based view...

Or is there another way to do this?

Another great addition to this module would be to allow the location field as a contextual filter, so if I had a view for example eg: germany/city/hotels to show all hotels in a XX km radius from the center for the 'city', I could specify a Contextual Filter to grab the arg(1) value (in this case 'city') and use that as it's center point ... and do this without having to export the view and adding my own php code into it.

As I am currently working on projects using this type of filter extensively I would be more than willing to help out and I will have a read through the code and try and uderstand all the necessary hooks used in it.

Thanks again.

@tecjam You bring up a number of solid use cases. I don't see any reasons why they couldn't be implemented with some effort. The question simply is who has the time/resources available to undertake the work. :)

@rickvug: Thanks for the confirmation.

I would be able to help invest some time over these next few days / over the new year. However I am stuck at some basics due to lack of knowledge in advanced module development and not knowing the specific modules code throughout.

For starters all i want is to be able to apply proximity search on views based on search api indexes, not just node views. That way I can display facets, which are required.

I have search indexes set up which do grab the geocode lat/lon values as wkt created from Geofield / Geocode from an address field in the node creation page. They are indexed as 'fulltext'.

How do I tell the proximity search to show up on the search index views Filter criteria? Does anyone know?

This is a confusing thread. It would help to have an official D7 version so issues could be reported for D7.

If a D7 version cannot be created, perhaps a new module name altogether, just so issues can be reported and found more easily.

My current issue is multiple geocoded locations per node, and being able to Proximity Filter on a chosen field.

As per comments #83, 84 and 86.

I can see that the node geocodes both properly, but Proximity Filter appears to choose one to filter on, and it appears this cannot be set in the View.

subscribing

ditcheva, stop subscribing and start following. :) http://drupal.org/node/1306444

Sweet! I'm a converted follower.

@rickvug:

I have an urgent project that I need to be able to show facets on proximity views and be able to filter by circle, so I will be delving into the code and rip it apart trying to figure out how to allow proximity searches on search_api based views in the next few days.

Are there any tips you can give me in regards to which hooks I need to extend to be able to archieve this modules functionality to what I need?

I know there are different approaches:

1) allow proximity searching for search api indexes
2) extend existing views by adding a distance field (to print out) and filter by distance (circle)
3) apply the filters to the facets as well

I don't mind doing some dirty hard coding for now just to get my head round it, but if you have experience with this module and views I would be extremely greatful for any tips you can give me so I won't stumble around the code like someone looking for a needle in a haystack in the dark.

@tecjam I haven't delved deeply into the code for any of these modules so I can't give you an answer without researching myself. I've mainly gotten involved in this issue to try and reduce duplication and confusion in the geolocation space. The proximity sandbox would be a decent place to start. Best of luck!

Thanks for the promt reply, Rick. I have already started to read through the sandbox to try and see what hooks are used.

I presume you mean this one: https://github.com/jpstrikesback/proximity and not the drupal git for this project (http://drupalcode.org/project/openlayers_proximity.git).

I'll keep you updated =)

How close is the sandbox version of the code to being re-released as the openlayers proximity module again? (EDIT) What about the github code? How do these all compare?

There is clearly interest in this module. Is this the code to review or is it the patch in 25?

How can I help move this to a dev release?

Does this solve the issue: create a list of nodes filtered by html5 geo location of the user? This Would be' great for mobile devices!

This module really rocks - but it is really Hard to find! An official Project would really help!

I downloaded the module from the sandbox, but proximity filter is not available for users view. How do I use this module for user search.

subscribe

I downloaded from here: https://github.com/jpstrikesback/proximity
Was pretty easy to get this set up to do simple proximity searches. What will it take to make this an official RC1 or beta release so everyone can more thoroughly test and contribute back?

I can confirm that basic views functionality is working but not rules.
I simply don't see any options for actions or event in regards to "Notify nodes based on geographic proximity" in Rules UI.

When will this github repository become a Drupal project? Even a development version would be great for centralizing documentation, tracking 7.x issues, and deploying updates.

I plan to contribute and make the proximity filter compatible with any type of entity— not just nodes. This will enable an admin create a view that calculates the distance of a given node from any other entity, including the current user.

Does anyone know why when I try ato add a proximity field (to calculate distance) the location provider dropdown is empty? As a result I get these errors

Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Trying to get property of non-object in openlayers_proximity_handler_field->render() (line 46 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).
Notice: Undefined index: in openlayers_proximity_handler_field->render() (line 67 of /var/www/vhosts/healthinteractive.co.uk/livewell/sites/all/modules/proximity/views/openlayers_proximity_handler_field.inc).

I presume this is to do with the fact that there is no locaiton provider selected?

Any help would be appreciated. Thanx

@madmatter23, re: your post #109, I have a question about what you're planning. Would the following use case fit what you have in mind?

I'm not geocoding Nodes directly. Instead, I have a node with a Field-Collection Entity, in which I'm capturing a geocoded location together with a time period. The drawback with this currently is in getting filtered views of the nodes in proximity to a given location. As far as I've been able to tell, I can't use a typical proximity filter because I can't calculate distance from the Field-Collection Entities. Only nodes or strings are options right now. Would your work include the ability to calculate distance from a field in the Field-Collection Entity?

Whenever the exposed filter for proximity is empty the errors appear... No solution till yet found.

any updates as when we could possibly celebrate having a D7 version of this amazing mod
Thanks

sub

would like to at least have it as a dev version that show up for updating in the update module.

@tvilms Yes, my solution would work for your use case because field collections are entities.

@moderator Any chance I can get commit access to this project? I'd like to push 7.x-dev version of this module.

madmatter23 - Does your fork look anything like this one: https://github.com/FeyP/proximity

I'm really interested in getting the view to search based off the user's profile location which would be an entity your'e talking about. I tried to install this fork to no avail. Any chance you could put your fork up to github or a sandbox? The original owners of this have abandoned the project so getting a dev in place may not be easy right now. Looks like they've been trying for months!

how does this port to D7 relate to the proximity filter people at Geofield are developing within that module? Will they ever join into a unique proximity filter? Or are they totally different approaches?

Just to update I got the fork I mentioned above to work on my setup. I'm now filtering users based on their profile location!

Now I just need to figure out how to feed the filter a wkt from a node submission form to get a submission rule to work. String doesn't take WKT from what I've seen, any ideas?

Cellar, how did you get the entities to work?

It appears that antoniodemarco has abandoned this project. He has not chimed into this thread once and has not committed any code to this project in over a year. @madmatter23 you may have to go through the process of Dealing with unsupported (abandoned) projects to get your code committed.

subscribe

@josedanielestrada use the follow button at the top of the issue instead of commenting to subscribe to an issue. This feature was added 7 months ago now to avoid unnecessary noise in the queue.

By using FeyP's repo I was able to get the user entity as an option for location. I had to do a full uninstall and re-install to clear the database of the old modules and it started working.

From there I was actually passing a WKT field from a non-user entity to the view. This required some hacking on my part that I'm going to have to refine in order to make a universal patch. I had to hack the string field and pass my variable from there. Not pretty but I had to get something going.

I'm all for helping to make it universal to the point where you can pull the location from any entity and reference it to another entity. Right now FeyP's repository seems to allow for the user entity to be used but only against other users.

Also, it would be great to update the rules portion of the module once we figure out a single repository forward. I had to use another custom rules module and pass the variable directly into the view to get the results. It would be better to keep this all in one module as it was in D6 too.

Quick question for all as I'm revisiting this project, maintainership, etc.

Has anyone tried the proximity stuff in Geofield? They've got a great proximity solution in place in the 2.x branch now and many of the bugs are worked out. I just tested it and for the basic use of geocoding a location and finding geofields nearby it works great (tho I'm submitting a little patch to sort out a notice that kills the preview.)

IMHO, the 2.x version of Geofield is looking good but still needs some love. Some great work has gone into it and from my understanding Brandonian is beating it into shape as we speak (Brandonain, if your are watching this thread, I would love to hear your thoughts). That being said, I believe the OpenLayers Proximity module is currently in better shape and deserves a proper release.

I propose that there be a 7.x release of Openlayers Proximity as is and put into maintenance mode with the intention of deprecating it at the end of the D7 life cycle. There are a number of projects out there that are already using it and to not release a stable version would be disastrous for all of those site maintainers.

Then, once there is a solid 2.x release of Geofield, the OpenLayers Proximity project page be updated to recommend Geofield for any new projects, with intention of Geofield being the defacto proximity standard in late D7 and into D8.

The nice thing about Geofield is that it takes advantage of the awesome GeoPHP library (and module) that has the calculations already in there. No reason to reinvent the wheel here.

Even though there might be some good proximity filters out there, I don't believe we need to abandon the open_layers_proximity.

Openlayers is an output oriented module. By deprecating this project the selection of an input module might become more dependant on its outputing capabilities. For instance:

I'm using the geolocation_field as an input widget because I like that better than geofield. For displaying results I'm using Openlayers. The proximity filter of geolocation_field are minimal and not in the ballpark of what I need. Luckely, the output I need can be filtered to proximity by adding a module the output module I'm using.
In the future my output won't be filtered in the output module, but in the input. So I won't be selecting on the way the input is handled in the inputmodule but on the way it's able to filter the output. As a result I'm now allready making preparations to switch to Geofield when needed to.

So where does this leave us? I think the functionality of proximity filtering should be ripped out of all modules and a proximity filter module should be made independant of a module. Just like openlayers is not dependent on the input widget, you just need to select the right fields on which to base the results.

@Nicoz & @wemmies both make excellent points and suggestions. How about this:

• Release the 7.x version as OLP 7.x into maintenance mode as Nicoz suggested, fixing bugs by accepting patches, no new features.
• Put weight behind Geofields Proximity solution once there is a 2.x release (suggesting it on the project page as a more generalized alternative)
• Continue efforts in a future project called Proximity as best I/we can to create an input agnostic proximity solution for drupal whereby input fields can be any field that contain WKT/lat & lon/etc selectable by field & format, a module that solely cares about calculating proximity from any suitable source

I think that's a brilliant plan jpstrikesback.

That would be ideal, I believe. Let me know if you'd like help.

Could It also suggest possible Search API-Solr support for the larger sites? Seems the only Search API option for spatial searches never worked and is now dead.

Seams the only Search API option for spatial searches never worked and is now dead.

Hearing this breaks my heart.

JP, seems like a good plan. As I'm just getting started with coding for drupal, I might be up to speed and able to help once a stand alone module is being started.

Ok so I've been made maintainer and have pushed a 7.x dev release. Once that becomes a release and we make sure that it's all good in the hood I can start visiting maintenance items like RTBC'd patches.

Cheers All,
JP

Thanks for all of your hard work jpstrikesback. The community appreciates it.

I published an alternative compatible with geofield and views arguments. I use it with OL and Drupal 7: drupal.org/sandbox/Admdebian/1664610

Hi Admdebian, how does it differ from the default OL Proximity?

I created an issue in Views but that it might be useful here since I see the see the error message some of you are talking about...

http://drupal.org/node/1677574

Very well then. Don't want to sound like a "complainer" so here it is:

**I do want to say that I am by no means an experienced programmer. Just develop and administer drupal sites. **

The modules that I THINK are invloved are:

Views 7.dev
Openlayers
Openlayers proximity
The module that I THINK is causing the problem is the new (7/10/12):

Views 7.dev
Here is whats gong on: I have a page created through views (see attached). It's an openlayers map displaying nodes along with a table attachment that displays node information on a table. It also uses the openlayers proximity module to filter nodes on the map via city,state or zipcode.

I've rolled back to the previous version of the views dev (that i downloaded on 7/7/12) because when I downloaded and updated the new version that came out on 7/10/12 it gave me errors on the page (see attached).

These 3 modules I feel are crucial to A LOT of drupal admins and developers and fee they should work in sync together.

PS: Maybe this is a issue for some other forum but it would also be nice to see a filter using openlayers proximity and VIEWS that can filter using geolocation HTML 5 for mobile devices. For example the same concept I have here but instead of using this proximity filter I have here I would create a separate view for mobile devices and it would ask the user for their locations via GPS and then filter accordingly. Does that make sense?

DISCUSS...

Closing this issue as there is now a dev release on the project page to post new issues against.

@garciac1212, please open a new issue.