proximity searches

Very interesting question. I have no idea if this could be done. When I have time, I'll play around with it.

The very latest cvs has new fields for a complete formatted address that can be displayed in a single cell and a distance calculation and proximity filter. The proximity filter is still proof-of-concept. It currently only computes distance in miles, I'm still working on a way to allow the user to select km as an alternative unit.

I'd really like to get some reviews for the proximity filter. To use it:

* Add a Location: Proximity filter to the view and expose it.
* Optional, add a Location: Distance field to the view to display the distance between each node and the postal code selected in the proximity filter.

For this to work you must have longitude and latitude data available in the nodes. The filter looks up the postal code provided in the filter in the zipcodes table, then brings up a list of nodes that have lon and lat fields within your selected distance, sorted by distance.

I have a GMaps locator map almost working as an alternative to selecting a postal code to search on. The idea is to use a GMaps map to click on the spot you want to use as your center point, then sort the view by proximity from that location. Everything works fine except that something is getting cached and it will only work the first time you use it. After that, it only works if I clear the cache. I have the filter set to cacheable='no', but that doesn't seem to be enough. I'm attaching the module to this page in case anyone wants to try it out, but I don't want to commit it until I figure out where it's getting cached so I can stop the caching.

To use it, add a Location: Proximity Map filter to your view and expose it. Obviously, only works if you have GMaps installed.

Anyone have any ideas on how to stop the caching??

How is the click info getting transmitted to views? I assume through an argument?

Nope, I put the whole map form (which includes several elements) into the 'value' element of the filter, and I am picking up the selected value from $filterinfo['value']['coordinates']['gmap_latitude']['#default_value'] and $filterinfo['value']['coordinates']['gmap_longitude']['#default_value']. If that didn't work, I was going to get it from the $_GET['edit'] values, but it seems to work this way.

Also, just to clarify, it's also not re-drawing the map, so it's possible that the caching is coming from Google Maps or GMap rather than views. I just don't know at this point.

I think I'm beginning to see where this is getting caught and I have an idea to do it differently. I am 'tricking' the value operator into giving me more than one value, which actually does give me the form fields I need, but doesn't do it in a way that the Google map gets redrawn. I think it is going to work better if I slip the GMap form in using views_pre_view, then grab the results from the $_GET. I am pretty sure that will keep things from getting cached and get me unstuck. I'll give that a try in the next day or two...

Figured out how to get it working. See a demo at http://www.elderweb.com/demo/views/proximitymap.

Turns out it is that the *form* gets cached when the view is created. I fixed it by using views_pre_view to invalidate the cache so the form would re-generate. Now that I have it working I'm not sure it *ought* to work, but it does.

The changes to get the GMap proximity search filter working have been committed to cvs. I'm marking this fixed since this functionality has been added and people can open issues if things don't seem to be working.

I decided to clean this up. The proximity map, in particular, was doing some things I didn't like (like forcing a cache clear to get the map to generate). I am in the process of re-writing these functions. I had to get some other bug fixes committed, but the proximity changes aren't working completely correctly yet, so I've temporarily pulled out the proximity filters and fields from the committed modules (both cvs and 4.7). I'll get them back in as soon as possible. If anyone badly needs them in the meantime, use the older cvs version that had them (look in the cvs repository around July). The subsequent bug fixes are not major problems that would keep that version from being usable.

When I click on the map, only the latitude is entered into the boxes below the map. The longitude is left blank. I have to manually enter a longitude as well to get the proximity search to work.

(nice work with this proximity search by the way... I like it)

I wonder if something changed in GMap since I first committed this? Google is always changing their api, so it's possible. If I could only free up some time to work on this I have a much better version very close to working. It just needs a little time :-(

Would it be possible to use this proximity filter when user locations are enabled to show the distance from the user logged in without having to enter a zipcode? Give me some hints, I'll take a stab at implementing it and contribute it back.

I have modified the location_views.module to use the user's location when the postal code is left off of the filter. This works great for me since I have also patched location.module to make postal code required when users register. In addition to this, I figured out how to make the distance field sortable in table views. I'm not sure if this is usefull to anyone else. In case anyone is interested, I have attached a patch which adds this functionality to the view.

The latest commits get all distance and proximity features working for both node and user locations by using the usernode module. To get it working, install the usernode module and update to the latest version of this module.

The recent changes do not include making any changes or enhancements to the way proximity seraches are handled (like allowing for searches by lat/lon instead of zip), just getting everything that works for node locations to work for user locations.

This issue covers a lot of ground that is also covered by other feature requests, and the last one, incorporating user locations, is done, so I'm closing this issue so we can track each individual other request separately.