Great to see that a version 3 release candidate of location.module is out now!
I currently try to find a suitable geodata/location solution for a webcommunity project, and hus evaluation location.module, too - in v3 i can't get a views-based proximity filter working.
What i (and probably many others using this module) need is a exposed views-filter that enables me to enter a distance (e.g. in km) and a postal code (that gets geo-coded on the server side when retrieving the filtered views-data).
Am i too stupid, am i missing something, or is the "old" proximity search gone missing in v3, *and* a possible exposed distance filter via "Location: Coordinates" broken? The v3 "Location: Coordinates"-filter should make a proximity search possible, shouldn't it? however, configuring it for "postal code" results in only the display of a "distance" formfield (what unit?) without any postal-code filed. And configuring it to "lat/long" brings up 3 fields (lat, long and distance), however they have no influence on the view whatsoever.
There seems to be no corresponding issue at the moment.
So: Is this currently broken and being worked on? Or am i completely thinking the wrong way?

Comments

Title:Proximity Seach - broken, or missing??Proximity search views-filter - broken, or missing??

btw: the SQL query composed by views preview (with "location: coordinates"-filter set to "lat/long") doesn't contain any of the where-sql-code generated by location_views_handler_filter_proximity::query() ... strange. So the functionality seems to be there in the module's code, but doesn't get invoked?

in my admin/build/modules it shows: "Location Search 6.x-3.0-rc1 A custom search page for locations.
This version is incompatible with the 6.5 version of Drupal core."

In location_views.module, I changed a line in the function location_views_filter_handler_proximity() and it started working. I saw some crazy stuff while debugging, somehow isset($filter['value']['latitude']) was returning true when a var_dump cleared expressed that it was not.

Approximately arround line 934, change this:
if (isset($filter['value']['latitude'])) {
To this:
if (is_array($filter['value']) && isset($filter['value']['latitude'])) {

the release notes for rc2 might say something about this issue.

yeah, what's the deal w/ this?

Assigned:Unassigned» bdragon

Oops!

I forgot to implement the zipcode stuff. DOH!

Coding it now.

What the hell? I forgot to implement the nice distance too?!?

For the record, it's accepting distance in METERS, of all units.. *sigh*..

Can some more info be given on the state of this?

Is it in the current dev? And...if so...how generally is it accessed?

Subscribing

Again, this is a much wanted feature (especially if it will work in UK!) and we are willing to pay for this as well :)

Hi, brandon.

Will the fix be applied to 5.x-3.x as well? Please let me know... otherwise, I have to revert to using 5.x-3.x-rc1 even though that has other problems as well...

-J

Brandon, could you give us a rough time estimate, when a release candidate including the proximity filter for D6 is coming out?
I'd like to contribute an additional proximity filter for a node author's location, but there should first need a working implementation of the original node location proximity filter...

Subscribing

Err, I think I did development in my second staging install and forgot to finish it. Looking into it.

StatusFileSize
new966 bytes

I just tried todays -dev Location, and proximity search stuff almost worked! Just so we're on the same page, I'm talking about adding a filter "Location: Coordinates", and setting a fixed lat/long, and a distance. A couple of gotchas:

- distance is in meters (needs descriptive text, and/or more sensible units)

- the location_views_handler_filter_proximity seems to use $this->value to find the current settings, and doesn't find them. If you replace this with $this->options, it basically works (well, it still does rectangular matching, so gets a few results which are a bit too far, but it's better).

Attached is a totally I-don't-know-what-I'm-doing patch that makes the change outlined above. It might help somebody until this is fixed for real.

hey Simon,
how are you doing meanwhile? Remember our short talk in Szeged about Geo-Boundaryfiltered views-generated feeds for dynamic viewport-dependant gmaps (right after Brandon's and Rebecca's BoF?)? Still looking into getting that done (before christmas, other stuff was more important until now). Unfortunately location.module still seems not to be ready in several areas.

Even with the small patch, as soon as the location:coordinate filter gets exposed, it's not working anymore, not even talking about a working zip-based filter.

@Brendan: Could you give us a *rough* estimate when this will be available in location? You mentioned you already coded it partly? Do you plan finishing that in the next, say, 2 weeks? Or should we rather not count on that and try to fix it by ourselves? Could try that, but if you're already (partly?) working on a solution, which will be available soon, that's even better.
just give us a hint...

[double post]

Yes, I remember our conversation. It's still an interesting topic, but I need to pay the bills first (unless you have a client, that needs this work done? ... :)

I didn't try exposing the view yet, it didn't even work when it was hidden. My patch only attempted to fix that, and "works for me".

EDIT: I just tried exposing the view, and now it doesn't obey what data was set in the exposed filters. Experimentally, it looks like $this->options contains what was configured in the view, and $this->value[0] contains what was entered in the exposed view. The symptom I hacked around last time, was that since the filter was not exposed, nothing was showing up in $this->value, so the filter was ignored. That hack breaks exposed filters (sorry, I don't know this stuff yet).

I think the root cause is further back - in value_form() the views filter should be setting $form['value'] but it is not. I'll dig in that direction. (but, the truth is, brandon would be way more effective at this stuff than me).

> It's still an interesting topic, but I need to pay the bills first (unless you have a client, that needs this work done? ... :)

Hehe, yeah, me too. I plan to come up with a solution by myself, but this will be an add-on functionality to a project currently under development, hope to get to this in January.

[double post]

the only distance I've seen is in the "fields" part of a view... to work to list the "5 closest nodes to this lat/long" it would need to be a "filter" and not a "field", yes? so it could be "exposed"?

Then I'm guessing I would filter by: distance to this lat/long, published, of type "whatever", sort by distance, and limit to 5 nodes...

I'm also thinking of embedding a view in a node. For example, I have "groups" that are a cck type, using cck fields, one of the fields is a cck location field... it would be super cool to be able to list the 5 nearest other "groups" closest to this group, at the bottom of the page for the node... but this would require allowing a view to be part of the node... there is a module to do that... I just read about... what was it called? ah yes: viewfield

yes, YesCT, what you described would work and do the trick for what you want to achieve - *if* the location.module's views proximity filter would be working... <:}

ah, but you would need some kind of proximity views-*argument* as well, to feed the resp. location you the currently viewed group node (from its CCK-lat/long fields) into the "nearest other group" view. Well, that could be technicaly done without an dedicated location argument via a global:null argument altering the lat/long of the proximity filter in the default argument value section via a PHP snippet - but this calls for some inside knowledge of programatically handling views. It'd be definitely nicer for many to have a simple "location:proximity"- or "location:cooredinates" argument ready to snap in and work in conjunction with a (functioning!) proximity filter.

How did it work on the Drupal 5 version? Was it an exposed view filter in that version?

And...did/will/could it work with zip codes too? Or just lat and longitude?

I'm happy others Are interested in this funcionality! :)

But I'm worried that even when it works.. That it will only work for node that are using the locAtion info directly attached to the node and it won't work with a cck location field .. Same as my gmap view issue ... And to get it to work that will still have to be sorted out. I have about 3 hours a day to work on this, but I'm having trouble figuring out where to start. I wonder if I could provide a install profile with some cck location fields and data of some canned "tests" that would make it easier for people to test their location and gmap solutions on cck location field set ups?

I've read about "tests" but not done them yet... I have devel module Installed and I can set to figuring that out if it seems useful.

Thanks!

danielnolde. There's nothing fundamentally broken with this, other than it's not handling the configuration settings properly (it's putting the data in the wrong place, then looking for it in the wrong place, etc). I am starting to understand this part of Views, but am reluctant to spend lotsa time fixing this, when bdragon appears to have working code ready to commit (or at least understands this much better than I).

YesCT. Your comments are offtopic for this issue, which is about Location Views Proximity Search not working. It is not Location modules problem that your data is in some other format, that it knows nothing about.

I don't want to highjack a issue or be off topic!

But this is about getting proximaty search to work in the location module, and I should have been more clear that I have a keen interest in making sure that it works with locaions stored as cck fields, which are part of the new location module. :) I don't want you thinking I'm making up custom cck fields storing street, city etc. Instead, it is a bonafied official "location" cck field.

And I've seen extensions to location that work with locations directly associated with a node, that don't work with a node that uses location module's cck location field type... So I was try to offer to organze some test cases that use locations cck field ....

Maybe I'm not using the right termonology... I really want to contribute! Thanks.

Also does not seem to be working in 5.x-3.x at this time. Is this correct?

Version:6.x-3.x-dev» 5.x-3.x-dev

Re: #27, it appears that proximity search/filter is not working for me in 5.x-3.x, either. I spent a fair amount of time trying to explore other options (including downgrading to unsupported versions of location), but nothing seemed useful.

Of all modules, I find the development of location to be the most... interesting. I've lost more hair tonight.

It's not too hard to fix the module for a specific usage (exposed, or not-exposed), you just need to fix handlers/location_views_handler_filter_proximity.inc to handle $this->options and $this->value consistently. In my case, I changed $this->value in function query() to $this->options, and it basically worked.

Of course, this is not the _correct_ solution, but bdragon appears to have working code that just needs to be committed.

Version:5.x-3.x-dev» 6.x-3.x-dev

Almost there. I've been banging on my patch all day, and I finally have everything working together nicely.

(Don't ask me about Drupal 5 support in this issue, as the views support is completely different for D5 and D6.)

Status:Active» Postponed (maintainer needs more info)

Committed an initial version of the new proximity code.
http://drupal.org/cvs?commit=156689

Hopefully it should implement most of what people need.

It consists of a field (to display distance from a point), a sort (to sort by distance from a point), and a filter (to filter by proximity.)

All three work with each other. For example, you can set up the field to display distance from the location entered in the filter, or you can sort by the same.

If you have both a field and sort, and they are configured the same, the sort code attempts to reuse the distance field for the sort, rather than adding another distance formula to the query.

Please check it out and give feedback.

Thanks!

Some kudos to bdragon for headbanging... ;)

bdragon rock on! I'm gonna go try it out!

Subscribing.

shweeet :))
thanks, Brandon!
With your current dev/HEAD version, the distance/proximity-filtering now works!!
I found a small bug, made a patch and some more improvements, as just posted on http://drupal.org/node/343487

Thanks so much for working on this!

It seems to work fine with static longitude/latitude values, but if I only have zip code info available it's not coming up with a distance at all (the distance/proximity field is invariably empty in the view data).

I don't want my users having to manually enter lat/long data--so their profiles have zip code and address info only and I'm building a view based on that profile info. Choosing "users location" as the origin when creating the view proximity field results in a blank value for me in the view data. Same result if I choose the Origin to be a distance/proximity filter and create the filter with the zip code entry.

Choosing Static Location, and entering static lat/long values works, however.

daniel (barret), using the zip-based proximity-filter requires that the zipcodes-table is populated with resp. zipcodes - at the moment (zipcode data for some countries is included in location.module's /database dir).
With this proposed patch - http://drupal.org/node/343487 - it's even possible to use/try the zipcode-based proximity-filter even without a (completely) populated zipcodes table.

Hmm...

The views location filter does not appear to be working. I current am using an address in the United States. Location/Gmap finds a lat/lon for the address and so it appears on the map and everything. However, if I try to do a proximity search (zipcode US only) via views it will not return any results. I tried using the advanced search and that does return the correct results.

I've been forced to stick to 5.x-3.0-rc1 because of this issue. The simple proximity filter on a list of locations has by far proven to be the most acceptable search method to my users. Will be watching this thread anxiously.

proxiity filter does not work on d5. this is the most important search feature :(

I tried rolling back, but i got the white screen of death.

this worked to fix the proximity filters. It should be put into Head for 5.x.3. I include it because it might also work for location 6.

http://drupal.org/node/326749#comment-1155243

Is this still an issue for 6.x-3.x-dev? I'm having no luck using the proximity filter in Gmap styled views so is this my problem or is it still being worked on? I've played around with various patches and such but to no avail.

Thanks for the info.

I can confirm this is still a problem in 6.x-3.0. Proximity filter fails when trying to make a view (basically no results show, even if nothing is entered).

StatusFileSize
new35.92 KB

I don't know if it's related to this issue, but when I've added Distance field into my view it says 5,723.55 km and whatever which postcode is entered.
See attachment.

Hi All,

This is a missing sql statement in the api function location_latlon_rough. But with some cooding you can change it in the views handler.

As long as bdragon is not changing the api function you may use the following code:

replace the code in your location_views_handler_filter_proximity.inc placed in the folder handler of location with the code below.

<?php
// $Id: location_views_handler_filter_proximity.inc,v 1.3 2008/12/03 22:51:23 bdragon Exp $
/**
* General proximity filter for location latitude/longitude.
*/
class location_views_handler_filter_proximity extends views_handler_filter {
 
// This is always single, because of the distance field's possible dependency
  // on it.
 
var $no_single = TRUE;
  function
option_definition() {
   
$options = parent::option_definition();
   
$options['type'] = array('default' => 'latlon');
   
$options['operator'] = array('default' => 'mbr');
   
$options['identifier'] = array('default' => 'dist');
   
$options['value'] = array(
     
'default' => array(
       
'latitude' => '',
       
'longitude' => '',
       
'postal_code' => '',
       
'country' => '',
       
'search_distance' => 100,
       
'search_units' => 'mile',
      ),
    );
    return
$options;
  }
  function
admin_summary() {
    return
'';
  }
  function
operator_options() {
    return array(
     
'mbr' => t('Proximity (Rectangular)'),
     
'dist' => t('Proximity (Circular)'),
    );
  }
  function
expose_form_left(&$form, &$form_state) {
   
parent::expose_form_left($form, $form_state);
   
$form['expose']['type'] = array(
     
'#parents' => array('options', 'type'),
     
'#type' => 'select',
     
'#title' => t('Form mode'), // @@@ Less stupid title?
     
'#options' => array(
       
'latlon' => t('Latitude / Longitude input'),
       
'postal' => t('Postal Code / Country'),
       
'postal_default' => t('Postal Code (assume default country)'),
      ),
     
//'#id' => 'edit-options-type',
     
'#description' => t('FIXME'),
     
'#default_value' => $this->options['type'],
    );
  }
  function
value_form(&$form, &$form_state) {
   
$val = $this->value;
   
// [11:44] <merlinofchaos> If you load the page from scratch, $input for your identifier will be empty.
    // [11:44] <merlinofchaos> So what's going on here is that for $_GET forms, there's no form id, no op button or anything, so they always appear to submit.
    // [11:45] <merlinofchaos> FAPI doesn't quite get along with that; sometimes it handles the input being empty right and sometimes it doesn't.
    // [11:45] <Bdragon> But if I set #default_value to a static string, it doesn't work either
    // [11:45] <merlinofchaos> Right, fapi thinks the empty input is actually input, thus it overrides the default value.
    // [11:45] <Bdragon> Ahh, hmm...
    // [11:46] <Bdragon> So where would I go to clean it up?
    // [11:55] <merlinofchaos> Bdragon: See views_handler_filter_string.inc line 174
    // [11:55] <merlinofchaos> Bdragon: That's how i address this problem.
    // [11:58] <Bdragon> Hmm, OK
   
if (!empty($form_state['exposed'])) {
     
$identifier = $this->options['expose']['identifier'];
      if (!isset(
$form_state['input'][$identifier])) {
       
// We need to pretend the user already inputted the defaults, because
        // fapi will malfunction otherwise.
       
$form_state['input'][$identifier] = $this->value;
      }
    }
   
$form['value'] = array(
     
'#tree' => TRUE,
    );
   
$form['value']['latitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Latitude'),
     
'#default_value' => $this->value['latitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['longitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Longitude'),
     
'#default_value' => $this->value['longitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['postal_code'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Postal code'),
     
'#default_value' => $this->value['postal_code'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal', 'postal_default')),
    );
   
$form['value']['country'] = array(
     
'#type' => 'select',
     
'#title' => t('Country'),
     
'#options' => array('' => '') + location_get_iso3166_list(),
     
'#default_value' => $this->value['country'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal')),
    );
   
$form['value']['search_distance'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Distance'),
     
'#default_value' => $this->value['search_distance'],
    );
   
$form['value']['search_units'] = array(
     
'#type' => 'select',
     
'#options' => array(
       
'mile' => t('Miles'),
       
'km' => t('Kilometers'),
      ),
     
'#default_value' => $this->value['search_units'],
    );
  }
function
exposed_form(&$form, &$form_state) {
   
parent::exposed_form($form, $form_state);
   
$key = $this->options['expose']['identifier'];
   
$type = $this->options['type'];
   
// Remove unneeded fields when exposing the form.
    // It's shorter than redefining value_form.
   
if ($type != 'latlon') {
      unset(
$form[$key]['latitude']);
      unset(
$form[$key]['longitude']);
    }
    if (
$type != 'postal' && $type != 'postal_default') {
      unset(
$form[$key]['postal_code']);
    }
    if (
$type != 'postal') {
      unset(
$form[$key]['country']);
    }
  }
 
// Used from the distance field.
function calculate_coords() {
    if (!empty(
$this->value['latitude']) && !empty($this->value['longitude'])) {
     
// If there are already coordinates, there's no work for us.
     
return TRUE;
    }
   
// @@@ Switch to mock location object and rely on location more?
   
if ($this->options['type'] == 'postal' || $this->options['type'] == 'postal_default') {
     
// Force default for country.
     
if ($this->options['type'] == 'postal_default') {
       
$this->value['country'] = variable_get('location_default_country', 'us');
      }
     
// Zip code lookup.
     
if (!empty($this->value['postal_code']) && !empty($this->value['country'])) {
         
$location = array('country'=> $this->value['country'], 'postal_code' => $this->value['postal_code']);
         
//DG senceless api call
       
$coord = location_latlon_rough($this->value);
       
//DG Lets get the data from the database
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
        }
        if (
$coord) {
         
$this->value['latitude'] = $coord['lat'];
         
$this->value['longitude'] = $coord['lon'];
        }
        else {
          return
false;
        }
      }
      else {
       
// @@@ Implement full address lookup?
       
return false;
      }
    }
    if (empty(
$this->value['latitude']) || empty($this->value['longitude'])) {
      return
false;
    }
    return
true;
  }
function
query() {
    if (empty(
$this->value)) {
      return;
    }
   
//DG this makes the code not working, because $this->calculate_cords never has a value. an it allway returns
    // Coordinates available?
    /*if (!$this->calculate_coords()) {
      // Distance set?
      if (!empty($this->value['search_distance'])) {
        // Hmm, distance set but unable to resolve coordinates.
        // Force nothing to match.
        $this->query->add_where($this->options['group'], "0");
      }
      return;
    }*/
    //DG if no postal code return
    
if (empty($this->value['postal_code'])) {
     return;
     }
    
// DG if no distance set it to 1 because it is required else we will get nor results at all
   
if (empty($this->value['search_distance'])) {
     
$this->value['search_distance'] = 1;
     }
       
$location = array('country'=> $this->value['country'], 'postal_code' => $this->value['postal_code']);
       
//DG Lets get the data from the database
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
        }
   
$this->ensure_my_table();
   
$lat = $this->value['latitude'];
   
$lon = $this->value['longitude'];
   
$distance_meters = _location_convert_distance_to_meters($this->value['search_distance'], $this->value['search_units']);
   
$latrange = earth_latitude_range($lon, $lat, $distance_meters);
   
$lonrange = earth_longitude_range($lon, $lat, $distance_meters);
   
// Add MBR check (always.)
   
$this->query->add_where($this->options['group'], "$this->table_alias.latitude > %f AND $this->table_alias.latitude < %f AND $this->table_alias.longitude > %f AND $this->table_alias.longitude < %f", $latrange[0], $latrange[1], $lonrange[0], $lonrange[1]);
    if (
$this->operator == 'dist') {
     
// Add radius check.
     
$this->query->add_where($this->options['group'], earth_distance_sql($lon, $lat, $this->table_alias) .' < %f', $distance_meters);
    }
  }
}
?>

Warm regards from cologne

Dirk

Hi all,

one more change for the views handler. Its for drupal 6 and location 6x.3.0. Its running on a beta production site.

use it like my post above.

<?php
// $Id: location_views_handler_filter_proximity.inc,v 1.3 2008/12/03 22:51:23 bdragon Exp $
/**
* General proximity filter for location latitude/longitude.
*/
class location_views_handler_filter_proximity extends views_handler_filter {
 
// This is always single, because of the distance field's possible dependency
  // on it.
 
var $no_single = TRUE;
  function
option_definition() {
   
$options = parent::option_definition();
   
$options['type'] = array('default' => 'latlon');
   
$options['operator'] = array('default' => 'mbr');
   
$options['identifier'] = array('default' => 'dist');
   
$options['value'] = array(
     
'default' => array(
       
'latitude' => '',
       
'longitude' => '',
       
'postal_code' => '',
       
'country' => '',
       
'search_distance' => 100,
       
'search_units' => 'mile',
      ),
    );
    return
$options;
  }
  function
admin_summary() {
    return
'';
  }
  function
operator_options() {
    return array(
     
'mbr' => t('Proximity (Rectangular)'),
     
'dist' => t('Proximity (Circular)'),
    );
  }
  function
expose_form_left(&$form, &$form_state) {
   
parent::expose_form_left($form, $form_state);
   
$form['expose']['type'] = array(
     
'#parents' => array('options', 'type'),
     
'#type' => 'select',
     
'#title' => t('Form mode'), // @@@ Less stupid title?
     
'#options' => array(
       
'latlon' => t('Latitude / Longitude input'),
       
'postal' => t('Postal Code / Country'),
       
'postal_default' => t('Postal Code (assume default country)'),
      ),
     
//'#id' => 'edit-options-type',
     
'#description' => t('FIXME'),
     
'#default_value' => $this->options['type'],
    );
  }
  function
value_form(&$form, &$form_state) {
   
$val = $this->value;
   
// [11:44] <merlinofchaos> If you load the page from scratch, $input for your identifier will be empty.
    // [11:44] <merlinofchaos> So what's going on here is that for $_GET forms, there's no form id, no op button or anything, so they always appear to submit.
    // [11:45] <merlinofchaos> FAPI doesn't quite get along with that; sometimes it handles the input being empty right and sometimes it doesn't.
    // [11:45] <Bdragon> But if I set #default_value to a static string, it doesn't work either
    // [11:45] <merlinofchaos> Right, fapi thinks the empty input is actually input, thus it overrides the default value.
    // [11:45] <Bdragon> Ahh, hmm...
    // [11:46] <Bdragon> So where would I go to clean it up?
    // [11:55] <merlinofchaos> Bdragon: See views_handler_filter_string.inc line 174
    // [11:55] <merlinofchaos> Bdragon: That's how i address this problem.
    // [11:58] <Bdragon> Hmm, OK
   
if (!empty($form_state['exposed'])) {
     
$identifier = $this->options['expose']['identifier'];
      if (!isset(
$form_state['input'][$identifier])) {
       
// We need to pretend the user already inputted the defaults, because
        // fapi will malfunction otherwise.
       
$form_state['input'][$identifier] = $this->value;
      }
    }
   
$form['value'] = array(
     
'#tree' => TRUE,
    );
   
$form['value']['latitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Latitude'),
     
'#default_value' => $this->value['latitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['longitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Longitude'),
     
'#default_value' => $this->value['longitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['postal_code'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Postal code'),
     
'#default_value' => $this->value['postal_code'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal', 'postal_default')),
    );
   
$form['value']['country'] = array(
     
'#type' => 'select',
     
'#title' => t('Country'),
     
'#options' => array('' => '') + location_get_iso3166_list(),
     
'#default_value' => $this->value['country'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal')),
    );
   
$form['value']['search_distance'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Distance'),
     
'#default_value' => $this->value['search_distance'],
    );
   
$form['value']['search_units'] = array(
     
'#type' => 'select',
     
'#options' => array(
       
'mile' => t('Miles'),
       
'km' => t('Kilometers'),
      ),
     
'#default_value' => $this->value['search_units'],
    );
  }
function
exposed_form(&$form, &$form_state) {
   
parent::exposed_form($form, $form_state);
   
$key = $this->options['expose']['identifier'];
   
$type = $this->options['type'];
   
// Remove unneeded fields when exposing the form.
    // It's shorter than redefining value_form.
   
if ($type != 'latlon') {
      unset(
$form[$key]['latitude']);
      unset(
$form[$key]['longitude']);
    }
    if (
$type != 'postal' && $type != 'postal_default') {
      unset(
$form[$key]['postal_code']);
    }
    if (
$type != 'postal') {
      unset(
$form[$key]['country']);
    }
  }
 
// Used from the distance field.
function calculate_coords() {
    if (!empty(
$this->value['latitude']) && !empty($this->value['longitude'])) {
     
// If there are already coordinates, there's no work for us.
     
return TRUE;
    }
   
// @@@ Switch to mock location object and rely on location more?
   
if ($this->options['type'] == 'postal' || $this->options['type'] == 'postal_default') {
     
// Force default for country.
     
if ($this->options['type'] == 'postal_default') {
       
$this->value['country'] = variable_get('location_default_country', 'us');
      }
     
// Zip code lookup.
     
if (!empty($this->value['postal_code']) && !empty($this->value['country'])) {
     
$location = array('country'=> $this->value['country'], 'postal_code' => $this->value['postal_code']);
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
        }
       
$coord = location_latlon_rough($location);
        if (
$coord) {
         
$this->value['latitude'] = $coord['lat'];
         
$this->value['longitude'] = $coord['lon'];
        }
        else {
          return
false;
        }
      }
      else {
       
// @@@ Implement full address lookup?
       
return false;
      }
    }
    if (empty(
$this->value['latitude']) || empty($this->value['longitude'])) {
      return
false;
    }
    return
TRUE;
  }
function
query() {
   
$this->value['country'] = variable_get('location_default_country', 'us');
    if (empty(
$this->value)) {
      return;
    }
   
// Coordinates available?
    //DG this is always empty
    /*if (!$this->calculate_coords()) {
      // Distance set?
      if (!empty($this->value['search_distance'])) {
        // Hmm, distance set but unable to resolve coordinates.
        // Force nothing to match.
        $this->query->add_where($this->options['group'], "0");
      }
      return;
    }*/
   
if (empty($this->value['postal_code'])) {
    return;
    }
    if (!empty(
$this->value['postal_code'])) {
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $this->value['postal_code'], $this->value['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
        }
    }
    if (empty(
$this->value['search_distance'])) {
   
$this->value['search_distance'] = 1;
    }
   
$this->ensure_my_table();
   
$lat = $this->value['latitude'];
   
$lon = $this->value['longitude'];
   
$distance_meters = _location_convert_distance_to_meters($this->value['search_distance'], $this->value['search_units']);
   
$latrange = earth_latitude_range($lon, $lat, $distance_meters);
   
$lonrange = earth_longitude_range($lon, $lat, $distance_meters);
   
// Add MBR check (always.)
   
$this->query->add_where($this->options['group'], "$this->table_alias.latitude > %f AND $this->table_alias.latitude < %f AND $this->table_alias.longitude > %f AND $this->table_alias.longitude < %f", $latrange[0], $latrange[1], $lonrange[0], $lonrange[1]);
    if (
$this->operator == 'dist') {
     
// Add radius check.
     
$this->query->add_where($this->options['group'], earth_distance_sql($lon, $lat, $this->table_alias) .' < %f', $distance_meters);
    }
   
//print_r($this->query);
 
}
}
?>

Dirk

Dirk,

I tried to use your fix but it did not work. Also if you have indeed fixed this issue it would probably be better to submit a patch so that bdragon can apply it and mark this issue as resolved and to make it easier to see what you are changing. Thanks.

hi zifra,

what is your problem? can you describe better?

My changes are not realy worth a patch, cause the changes are quite easy! I didn´t changed the api function because i´m not shure what is the aim of bdragon.

Anyway what you wanna do? I can help you. Just descripe your problem a bit.

Dirk

I tested out the fix posted by DesignWork in #48 and it worked for me, so I generated the attached patch. Apply it in the "location/handlers" folder.

Status:Reviewed & tested by the community» Postponed (maintainer needs more info)

Hi Guys,

I've updated the proximity filter to work with with a google api request, so there is no need to import the zip Table.
I also changed the distance field to be a select box.

This is my first Drupal development so please be patient ;o)

Edit: Added

drupal_set_message(t('Google is not responding')', 'error');

if Google API is not responding.

Oliver

<?php
// $Id: location_views_handler_filter_proximity.inc,v 1.3 2008/12/03 22:51:23 bdragon Exp $
/**
* General proximity filter for location latitude/longitude.
*/
class location_views_handler_filter_proximity extends views_handler_filter {
 
// This is always single, because of the distance field's possible dependency
  // on it.
 
var $no_single = TRUE;
  function
option_definition() {
   
$options = parent::option_definition();
   
$options['type'] = array('default' => 'latlon');
   
$options['operator'] = array('default' => 'mbr');
   
$options['identifier'] = array('default' => 'dist');
   
$options['value'] = array(
     
'default' => array(
       
'latitude' => '',
       
'longitude' => '',
       
'postal_code' => '',
       
'city_string' => '',
       
'country' => '',
       
'search_distance' => 100,
       
'search_units' => 'mile',
      ),
    );
    return
$options;
  }
  function
admin_summary() {
    return
'';
  }
  function
operator_options() {
    return array(
     
'mbr' => t('Proximity (Rectangular)'),
     
'dist' => t('Proximity (Circular)'),
    );
  }
  function
expose_form_left(&$form, &$form_state) {
   
parent::expose_form_left($form, $form_state);
   
$form['expose']['type'] = array(
     
'#parents' => array('options', 'type'),
     
'#type' => 'select',
     
'#title' => t('Form mode'), // @@@ Less stupid title?
     
'#options' => array(
       
'city_search' => t('City Search with Google API'),
       
'latlon' => t('Latitude / Longitude input'),
       
'postal' => t('Postal Code / Country'),
       
'postal_default' => t('Postal Code (assume default country)'),
      ),
     
//'#id' => 'edit-options-type',
     
'#description' => t('FIXME'),
     
'#default_value' => $this->options['type'],
    );
  }
  function
value_form(&$form, &$form_state) {
   
$val = $this->value;
   
// [11:44] <merlinofchaos> If you load the page from scratch, $input for your identifier will be empty.
    // [11:44] <merlinofchaos> So what's going on here is that for $_GET forms, there's no form id, no op button or anything, so they always appear to submit.
    // [11:45] <merlinofchaos> FAPI doesn't quite get along with that; sometimes it handles the input being empty right and sometimes it doesn't.
    // [11:45] <Bdragon> But if I set #default_value to a static string, it doesn't work either
    // [11:45] <merlinofchaos> Right, fapi thinks the empty input is actually input, thus it overrides the default value.
    // [11:45] <Bdragon> Ahh, hmm...
    // [11:46] <Bdragon> So where would I go to clean it up?
    // [11:55] <merlinofchaos> Bdragon: See views_handler_filter_string.inc line 174
    // [11:55] <merlinofchaos> Bdragon: That's how i address this problem.
    // [11:58] <Bdragon> Hmm, OK
   
if (!empty($form_state['exposed'])) {
     
$identifier = $this->options['expose']['identifier'];
      if (!isset(
$form_state['input'][$identifier])) {
       
// We need to pretend the user already inputted the defaults, because
        // fapi will malfunction otherwise.
       
$form_state['input'][$identifier] = $this->value;
      }
    }
   
$form['value'] = array(
     
'#tree' => TRUE,
    );
   
$form['value']['latitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Latitude'),
     
'#default_value' => $this->value['latitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['longitude'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Longitude'),
     
'#default_value' => $this->value['longitude'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('latlon')),
    );
   
$form['value']['postal_code'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Postal code'),
     
'#default_value' => $this->value['postal_code'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal', 'postal_default')),
    );
   
$form['value']['city_string'] = array(
     
'#type' => 'textfield',
     
'#title' => t('Proximity search'),
     
'#default_value' => $this->value['city_string'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('city_search')),
    );
   
$form['value']['country'] = array(
     
'#type' => 'select',
     
'#title' => t('Country'),
     
'#options' => array('' => ''), // + location_get_iso3166_list(),
     
'#default_value' => $this->value['country'],
     
'#process' => array('views_process_dependency'),
     
'#dependency' => array('edit-options-type' => array('postal')),
    );
   
$form['value']['search_distance'] = array(
     
'#type' => 'select',
     
'#options' => array(
       
'5' => '5 ' . t('Kilometers'),
       
'10' => '10 ' . t('Kilometers'),
       
'25' => '25 ' . t('Kilometers'),
       
'50' => '50 ' . t('Kilometers'),
       
'100' => '100 ' . t('Kilometers'),
      ),
     
'#title' => t('Distance'),
     
'#default_value' => $this->value['search_distance'],
    );
/*    $form['value']['search_units'] = array(
      '#type' => 'select',
      '#options' => array(
        'mile' => t('Miles'),
        'km' => t('Kilometers'),
      ),
      '#default_value' => $this->value['search_units'],
    );
*/
 
}
function
exposed_form(&$form, &$form_state) {
   
parent::exposed_form($form, $form_state);
   
$key = $this->options['expose']['identifier'];
   
$type = $this->options['type'];
   
// Remove unneeded fields when exposing the form.
    // It's shorter than redefining value_form.
   
if ($type != 'latlon') {
      unset(
$form[$key]['latitude']);
      unset(
$form[$key]['longitude']);
    }
    if (
$type != 'postal' && $type != 'postal_default') {
      unset(
$form[$key]['postal_code']);
    }
    if (
$type != 'postal') {
      unset(
$form[$key]['country']);
    }
    if (
$type != 'city_search') {
      unset(
$form[$key]['city_string']);
    }
  }
 
// Used from the distance field.
function calculate_coords() {
    if (!empty(
$this->value['latitude']) && !empty($this->value['longitude'])) {
     
// If there are already coordinates, there's no work for us.
     
return TRUE;
    }
   
// @@@ Switch to mock location object and rely on location more?
   
if ($this->options['type'] == 'postal' || $this->options['type'] == 'postal_default') {
     
// Force default for country.
     
if ($this->options['type'] == 'postal_default') {
       
$this->value['country'] = variable_get('location_default_country', 'us');
      }
     
// Zip code lookup.
     
if (!empty($this->value['postal_code']) && !empty($this->value['country'])) {
     
$location = array('country'=> $this->value['country'], 'postal_code' => $this->value['postal_code']);
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
        }
       
$coord = location_latlon_rough($location);
        if (
$coord) {
         
$this->value['latitude'] = $coord['lat'];
         
$this->value['longitude'] = $coord['lon'];
        }
        else {
          return
false;
        }
      }
      elseif (!empty(
$this->value['city_string'])) {
       
$request_url = "http://maps.google.com/maps/geo?output=csv&key=".variable_get('googlemap_api_key', '')."&q=" . $this->value['city_string'];
       
$csv = file_get_contents($request_url) or drupal_set_message(t('Google is not responding'), 'error');
       
$csvSplit = split(",", $csv);
        if (
strcmp($csvSplit[0], "200") == 0) {
           
$this->value['latitude'] = $csvSplit[2];
           
$this->value['longitude'] = $csvSplit[3];
        }
        else {
          return
false;
        }
      }
      else {
       
// @@@ Implement full address lookup?
       
return false;
      }
    }
    if (empty(
$this->value['latitude']) || empty($this->value['longitude'])) {
      return
false;
    }
    return
TRUE;
  }
function
query() {
   
$this->value['country'] = variable_get('location_default_country', 'us');
    if (empty(
$this->value)) {
      return;
    }
   
// Coordinates available?
    //DG this is always empty
    /*if (!$this->calculate_coords()) {
      // Distance set?
      if (!empty($this->value['search_distance'])) {
        // Hmm, distance set but unable to resolve coordinates.
        // Force nothing to match.
        $this->query->add_where($this->options['group'], "0");
      }
      return;
    }*/
   
if (empty($this->value['postal_code']) && empty($this->value['city_string'])) {
    return;
    }
   
$adress_found = false;
    if (!empty(
$this->value['postal_code'])) {
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $this->value['postal_code'], $this->value['country']);
        if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
       
$adress_found = true;
        }
    }
    if(!empty(
$this->value['city_string']))
    {
       
$request_url = "http://maps.google.com/maps/geo?output=csv&key=".variable_get('googlemap_api_key', '')."&q=" . $this->value['city_string'];
       
$csv = file_get_contents($request_url) or drupal_set_message(t('Google is not responding'), 'error');
       
$csvSplit = split(",", $csv);
        if (
strcmp($csvSplit[0], "200") == 0)
        {
           
$this->value['latitude'] = $csvSplit[2];
           
$this->value['longitude'] = $csvSplit[3];
        }
    }
    if (empty(
$this->value['search_distance'])) {
   
$this->value['search_distance'] = 1;
    }
   
$this->ensure_my_table();
   
$lat = $this->value['latitude'];
   
$lon = $this->value['longitude'];
   
$distance_meters = _location_convert_distance_to_meters($this->value['search_distance'], $this->value['search_units']);
   
$latrange = earth_latitude_range($lon, $lat, $distance_meters);
   
$lonrange = earth_longitude_range($lon, $lat, $distance_meters);
   
// Add MBR check (always.)
   
$this->query->add_where($this->options['group'], "$this->table_alias.latitude > %f AND $this->table_alias.latitude < %f AND $this->table_alias.longitude > %f AND $this->table_alias.longitude < %f", $latrange[0], $latrange[1], $lonrange[0], $lonrange[1]);
    if (
$this->operator == 'dist') {
     
// Add radius check.
     
$this->query->add_where($this->options['group'], earth_distance_sql($lon, $lat, $this->table_alias) .' < %f', $distance_meters);
    }
   
//print_r($this->query);
 
}
}
?>

Status:Postponed (maintainer needs more info)» Reviewed & tested by the community

Jrosen's patch in #49 of DesignWork's code posted in #46 resolved the issue for me. Can we get this committed to the project?

Installed the patch from #49, but the proximity search as set up here http://drupal.org/node/359463 is still not working.

Initially, it displays all possible results - prior to the patch, no results were displayed, ever.

When a zip code is entered - even one taken directly from one of the locations listed - no results show up.

The file "zipcodes.us.mysql" that came with the module is installed in modules/location/database/. Are additional files needed? The website is limited to US addresses.

- - - - - - - - -

also tried the code in #50 ... same results as above.

hi,

I use drupal 6 with current locations and gmap-modules and zip-code-database (installed according to that: http://drupal.org/node/359463). I have to nodes with locations being properly displayed in Google-maps. Inside the location there are latitude and longitude saved. My problem is that the search/filter for zip-codes (plz) is not working.

I have a view with a proximity filter. When I select a place with latitude/longitude it shows me the proximity to the nodes correctly. But: if I select a place with zip-code (and country) the nodes don't show (empty result).

In preview it looks like this (working latitude/Longitude)

Body:
Jop 1
Distance / Proximity: 170.24 km

Body:
Jop 2
Distance / Proximity: 171.99 km

SELECT node.nid AS nid,
node_revisions.body AS node_revisions_body,
node_revisions.format AS node_revisions_format,
(IFNULL(ACOS(0.601630442741*COS(RADIANS(location.latitude))*(0.988022017143*COS(RADIANS(location.longitude)) + 0.154312973013*SIN(RADIANS(location.longitude))) + 0.798774567927*SIN(RADIANS(location.latitude))), 0.00000)*6364467.83762) AS location_distance
FROM node node
LEFT JOIN location_instance location_instance ON node.vid = location_instance.vid
LEFT JOIN location location ON location_instance.lid = location.lid
LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid
WHERE (location.latitude > 44.0107947979 AND location.latitude < 62.0156872649 AND location.longitude > -6.19830854786 AND location.longitude < 23.9522147979) AND ((IFNULL(ACOS(0.601630442741*COS(RADIANS(location.latitude))*(0.988022017143*COS(RADIANS(location.longitude)) + 0.154312973013*SIN(RADIANS(location.longitude))) + 0.798774567927*SIN(RADIANS(location.latitude))), 0.00000)*6364467.83762) < 1000000) AND (node.type in ('neutest'))

The SAME query with ZIP-Codes instead of Latitude/Longitude:

Query
SELECT node.nid AS nid,
node_revisions.body AS node_revisions_body,
node_revisions.format AS node_revisions_format,
'Unknown' AS location_distance
FROM node node
LEFT JOIN node_revisions node_revisions ON node.vid = node_revisions.vid
LEFT JOIN location_instance location_instance ON node.vid = location_instance.vid
LEFT JOIN location location ON location_instance.lid = location.lid
WHERE (0) AND (node.type in ('neutest'))

delivering an empty result.

Somehow the Zip-Codes don't get converted (geocoded) instantly when making a variable query with zip-codes.

Is there anyone out there who can show me how proxmity-search is working?

Thanks in Advance!

Cedrix

Woah, location_latlon_rough is totally broken.

I take that back, I had forgotten to load my zipcode table.

(The api still sucks though. :P)

Since the Proximity Filter doesn't have a Views Argument--can anyone give me a clue on how to pass just the Distance value to views? I need to programatically pass a caluclated distance behind the scenes, while leaving the Zip code field exposed for the user to input.

hi bdragon,

did you saw, that the same function in 5 has an sql select? It should be something like:

$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
if ($r = db_fetch_array($res)) {
$lat = $r['latitude'];
$lon = $r['longitude'];
}

than you can give the values back! I was not shure why this db_query is missing but i did not changed it in the api. Maybe we should test this and then rewrite the views handler.

What do you think to make a views handler proximity by city. I did this for 5 and i think this should be nice because most of the people don´t no zip codes but city names.

I could provide this view handler.

Warm regards

Dirk

Hi daneyuleb,

describe a bit more what you wanna do? I´m willing to help.

Dirk

Status:Postponed (maintainer needs more info)» Reviewed & tested by the community

This patch worked for me - I think .... I now have a set returned, but the only two entries in my content type selected are in New Jersey, if I type a California zipcode, I still get those two results returned, even though I have the distance set to 25. Is that by design?

Julie

I've installed the patch, all ok.

The one thing I'm trying to work out is how add a filter that limits the distance to a set number away from the user logged in. What settings should be used?

could someone try and post a patch for what worked for them against HEAD?

And I just want to double check something... this would be just for the location locations (not the cck locations), right?

subscribing

#49 works well for me as well -- thanks DesignWork & jrosen

@zelavi: I was only able to get this to work when the nodes were geocoded. In Location > Main Settings, I turned on 'Use a Google Map to set latitude and longitude', and in Location > Geocoding options, I selected 'Google Maps'. Then when I saved my node (as long as the address is recognizable by a Google map) the latitude & longitude is automatically set.

@cedrix: It worked for me when i selected 'Postal Code (assume default country)' in the exposed 'Location: Distance / Proximity' views filter

@YesCT: I only tested against non-cck locations so far, so not sure about cck locations. Here is a patch against head

I am having the same problem as zelavi. I have my nodes geocoded and I applied the fix in 49. However, all possible results come up. If I switch the view to search by lat and long, it works fine. Am I supposed to load the zip tables from somewhere. I am really confused as to what type of arcane magic I need to be involved in for this thing to pop out distances based on zip codes.

It looks like my problem was that I'm using Locations via CCK. When I get a chance, I'll try the patches as #61 suggested.

scottrigby: thanks for the response. I did have that set up already, which is why I believe it's a CCK issue.

@dionysio
in the module there is a database directory, there are a few sql files, if there is a file for your country load it into the zipcodes table in the database. If there is not a sql file for your country, you need to get the zipcodes from somewhere else.

StatusFileSize
new983 bytes
new71.14 KB

This is how I got the proximity search to work on my site using Location 6.x-3.1-rc1 (most recent version).

I enabled the location module and set it up for a node type (I didn't use the CCK fields). Added a number of nodes of this type.

When setting up the view I enabled the Location Distance /Proximity Filter. I set my settings as in Picture 8.png (attached). Notice that I have the filter set to be exposed and optional. I also have the distance set to 10 miles by default.

Looking at the code in handlers/location_views_handler_filter_proximity.inc lines 195 to 204 in function query()

<?php
   
// Coordinates available?
   
if (!$this->calculate_coords()) {
     
// Distance set?
     
if (!empty($this->value['search_distance'])) {
       
// Hmm, distance set but unable to resolve coordinates.
        // Force nothing to match.
       
$this->query->add_where($this->options['group'], "0");
      }
      return;
    }
?>

If coordinates are not available, but if the distance is set we force noting to match.

I changed the code to look like this:

<?php
// Coordinates available?
   
if (!$this->calculate_coords()) {
     
// Distance set?
     
if (!empty($this->value['search_distance'])) {
       
// Hmm, distance set but unable to resolve coordinates.
        // check to see if filter is optional
       
if ($this->options['exposed'] && $this->options['expose']['optional']) {
         
// the filter is optional, so we do nothing
         
return;
        }
       
// Force nothing to match.
       
$this->query->add_where($this->options['group'], "0");
      }
      return;
    }
?>

Check first to see if the filter is exposed, and if it is set to optional before deciding to force the query to return nothing.

This change is working for me.

The patch is attached

Tagging.

is there a way to set the default to a value instead of returning nothing?
For example, I might want to import the location of $user, the currently logged on user.

Chris

I tried the previous patches against the latest dev release (4-4-09) and nothing has worked for me. I am using a CCK type with location fields.

When I applied the patch in #67 I started getting results but no matter what zip code / distance I enter my view is returning all nodes of the desired content type.

I also tried the patch in #49 and had no success. I see some people claiming these patches are working for them and specifying they did not use CCK, I am using CCK so... is that the cause of my un-functional views filter?

It does work fine filtering by city, zip-code, or state, it's just the proximity that causes everything to stop working. And of course, proximity search is what I really want to use.

Tagging again.

See #430730: Document using zip code proximity search with views on getting proximity views to work with location cck fields.

Also, for historical purposes:
http://groups.drupal.org/node/929
is related.
and the doc "Howto: zip code proximity search using Location Module"
http://drupal.org/node/359463
will need to be updated.

marked #354755: Location Search a duplicate of this issue.

StatusFileSize
new2.9 KB
new2.89 KB

Still seems pretty broken. I used the latest patch with UK postcode data.

Latitude and longitude proximity search *kinda* works, but the proximity ranges seem to be about 50 miles out! (I have a "shop" which I put in next to my house, but it only shows up when I extend the range to 50 miles!) Last line of the query looks like this:

WHERE (node.type in ('one_water_stockist')) AND (location.latitude > 50.130815831836 AND location.latitude < 51.869184168164 AND location.longitude > -1.3812281194882 AND location.longitude < 1.3812281194882)

Long/Lat of house: 51° 41' 57.138" N, 0° 5' 19.1004" E
Long/Lat of "shop": 51° 41' 55.7304" N, 0° 6' 39.9456" E

The query looks correct and, as you can see, co-ordinates place the shop in range easily, so I assume it's something else that's way off?

Postcode search doesn't do anything. The last line of the query looks like this:

WHERE (node.type in ('one_water_stockist')) AND (0)

Exports of both views are attached, for debug purposes and in case I'm doing something silly, but I followed the directions here:
http://drupal.org/node/359463

So all in all, still pretty broken. =(

Status:Reviewed & tested by the community» Needs work

Forgot to change status...

@greg.harvey: did you try the patch in #63?

I actually used #50, but you make no mention of updating the code in #50 when you re-rolled against HEAD in #63, so I assumed they were the same. Am I wrong?

I'm also using 6.x-3.1-rc1, not dev, because it's a production site. Is dev safe? Should it be used? I figured since this was only changes to a views handler that wouldn't matter - please advise if, again, I'm wrong!

For the record, I did read your post in #63 and I have an identical setup to you (long/lat data being pulled in to standard Location fields, not CCK, using Google mapping of the postcode to get the results). You achieved *exactly* what I want! =)

@greg.harvey: #50 actually is different -- what i poseted was just an update of jronson's patch in #49 (updated to apply cleanly to current dev). Personally, yes I'd recommend using 6.x-3.x-dev with this patch, just because i haven't tested with 6.x-3.1-rc1.

There are other things that make testing difficult, and it's soooooo easy to get false negatives. For instance, if an address isn't recognized by google maps, then it won't geocode. Or if the province is added incorrectly because the state doesn't validate (for instance if you type too fast, or add the abbreviation when the field requires the fill province name -- #351918: Location Element Validation (Province is not validated)).

Great - I'll try your patch and come back. I'll try it against RC1 first, but dev if that doesn't work (though dev will be a pain now as a load of data is entered with RC1 and of course there's no "upgrade" to dev!)

The postal codes definitely validate against Google Maps, because that's how both nodes got their Location lat/long data in the first place! =)

#418596: Ajax geocoding for Distance/Proximity filter. had an idea about using any kind of location input, and geo-coding it to let other types of proximity search work, since the lat/long seems to be working well.

Hmmm, ok - latest patch was an improvement. At least Views is now trying to execute a query based on the location entered for the postal code. Query now looks like this:

WHERE (node.type in ('one_water_stockist')) AND (location.latitude > -2.16855151133 AND location.latitude < 2.16855151133 AND location.longitude > -2.16855151133 AND location.longitude < 2.16855151133)

Problem is here:

<?php
    $lat
= $this->value['latitude'];
   
$lon = $this->value['longitude'];
?>

$this->value['longitude'] and $this->value['latitude'] are still null. I printed $this to screen and picked through it - there are no lat/long values in that object at all. There are spaces for them, but they are empty in every case.

Seems the translation of the postal code to longitude and latitude so that proximity can function is not working. I'm not sure how/where this happens, but I know it works when I create a new node, so the mechanism is fine within the core of the Location module - there must be some problem with the way this handler invokes it. Any suggestions?

Status:Needs work» Needs review
StatusFileSize
new3.03 KB

Got it working!!!! =D

It turns out the current handler doesn't know what to do with UK postal codes. They're weird. A user will enter something like NG22 0BS but the zipcodes table only contains NG22 matched to co-ordinates, so the SQL query executed against the zipcodes table where zipcode = 'NG22 0BS' will never work. It needs to be where zipcode = 'NG22'.

As such, I've added a little to your patch:

<?php
   
if (!empty($this->value['postal_code'])) {
     
// uk postcodes are weird - we need to make a special case:
     
if ($this->value['country'] == 'uk') {
       
preg_match('/^[a-zA-Z]*[0-9 ]+/', $this->value['postal_code'], $matches);
       
$this->value['postal_code'] = substr_replace(str_replace(' ', '', $matches[0]), '', -1);
      }
?>

I used a regexp to grab the first part of the UK postal code (the bit we need to match against the zipcodes table) and save the result back in to the postal_code value. Now it works like a charm!

Patch attached... needs reviewing by a UK audience to confirm it's good for all UK postal codes and others to be sure it hasn't broken anything for them.

Thanks! =)

Btw - the calculate_coords() function seems to have been bypassed along the way in the writing of this function. I'm not sure this is a good thing? Right now it's redundant - it should probably be re-written to complete this patch, no?

subscribe

@greg.harvey: This patch works great except that if I want to search for postcodes like EC1 or SE16 it doesn't work, it only works if you use the full postcode

subscribe. Tested it out. Works great.

@vivianspencer: Sorry, I got lazy - it wasn't a requirement for me. ;-)

Thanks for fixing!

Ps - anyone got thoughts on that redundant function? Seems it ought to be updated and used or deleted entirely...!

tagging

Sorry, I don't know what happened to the comment that went with the above patch

I'm not sure if I should have created a new thread for this but I've added a new option in the proximity filter which allows you to search by city name

re #92 so it is a proximity search based on city name, or just a match to find all the locations that match the exact city name?

re #92 so it is a proximity search based on city name, or just a match to find all the locations that match the exact city name?

The current functionality already allowed you to match locations based on the city name using the normal search parameters.

The patch above is a proximity search on the city name, if you look at the patch it utilises the "google_geocode_location" function which it gets from the included file "/geocoding/google.inc"

Thanks!

Tried patch in #91, it works exactly as it's supposed to.

For now this is a great sultion for me, however I would still like the proximity based on postal code working.

Thanks for this great patch!

*edit*
Actually, let me help by mentioning my setup:
Drupal 6.11
Location 6.x-3.x-dev (2009-Apr-18)
Gmap 6.x-1.x-dev (2009-Apr-18)
CCk 6.x-2.2
Views 6.x-2.5

@libeco: are you saying it's not working? It should be! =/

Try #87 and compare results. #87 has no city look-up but the postal code stuff worked.

Hmm, didn't realise they both fixed different problems. I'll try it out right now!

Thanks!

StatusFileSize
new51.17 KB

I'm not sure now whether or not #91 is built on #87 or not? I tried postal code for both and it seems to work for Holland, but not for Belgium

Holland has postal codes of four numbers and 2 letters, however, I only have a postal code database of the four numbers (which is enough for rough distance/proximity searches). Belgium however only uses 4 numbers. I've used the included Belgian postal code database.

It seems like no matter what country I select for the proximity search it takes the default (which is Holland) and ignores the picked choice. Since I use 4 numbers for both countries it seems to use the 4 numbers which I type in for Belgium, but actually look for them in the Dutch database.

However, when I set the default country to Belgium in the proximity/distance filter it doesn't solve the problem.

I have this set, but changing this to be doesn't change anything either.

$this->value['country'] = variable_get('location_default_country', 'nl');

Does that make sense to you?

Thanks!

PS. I attached the Dutch postal db if you want to try (or maybe it could be added to the module, but I'm not sure how complete it is)

Ah, postal code proximity search is limited because there are only so many countries where the long/lat can be looked up, AFAIK. It is listed somewhere, but can't remember where. You'll probably find your countries aren't supported yet. =(

The patch in #91 actually includes the patch in #87, the patch in #91 just introduces a new filter which allows you to search by city name.

I'm not sure how these filters work together, I only needed the use of one or the other

@libeco: this link may be of interest to you: http://code.google.com/support/bin/answer.py?answer=62668&topic=12266, it shows you which countries the google maps api provides geocoding for

@vivianspencer: that's what I figured. My intention was to suggest libeco try the earlier patch in case something broke in between the two, not that they contained different, independent functionality. =)

Thanks for the Google link - I know there was some data somewhere about what was supported. Useful to have in this thread!

Thanks, but both the Netherlands and Belgium are supported it says on that page.

Ok, so Google does but the module doesn't. Unfortunately for you, that means you either need to work on the patch so it supports your regions (like many people in this issue did, myself included) or you need to wait until someone else who also needs this feature and *is* prepared and/or able to work on the patch to make it support your regions. Sadly few people have the time to work on functionality they do not need themselves. (I wish I did! There's loads of stuff I want to do! =)

I'm of two minds as to whether this is a good idea or not, but you could, for your specific case (postal code Views proximity filters do not currently work for Belgium and the Netherlands), raise a separate issue and link to the work going on here to avoid duplication of effort. If you need it and can't build it, it's worth posting a commercial request (if you have any budget) in the forums. It's also worth jumping on IRC and asking if anyone is working on something like this already, or if anyone based in those regions intends to.

HTH! =)

OK, thank you for your help, it's much appreciated! I'll see whether I'll post a new issue or decide to stick with proximity search based on city.

Thanks again!

I can confirm that the patch in #87 worked for me on Location 6.x-3.1-rc1. I had to remove the "#process" & "#dependency" items from the form array in value_form(), though. Don't know why.

#87 and #91 both work for postal codes (US) and #91 works for cities. Woo-hoo! Hesitating to set to RTBC, though, until more than greg and I have tested.

Hi,

Thanks all for contributing.

I'm using

location-6.x-3.x-dev.tar.gz
drupal 6.10

I'm applied the patches
- #comment #91

The following is working:
- filters using coordinates "lat/lon"

The following are not working at all:
- postcode, I am in Australia

The following works partially:
- city, say there is a suburb called Adelaide, within 5 km there is a suburb called norwood.

If I type in [adelaide] within 5km, norwood appears.

But if I type in [norwood] within 5km, nothing appears.

Not sure why it is.

Also, would be nice to have city autocomplete using the zipcode db.

Would like to contribute via a paypal donate to the project to push it along.

cheers
Ed

Tutorial on how to do a location/proximity search here: http://drupal.org/node/359463

It appears that this feature is working, however, some folks are having problems, as the comments indicate.

juicytoo (in #109): consider posting a bounty also in http://drupal.org/paid-services and #drupal-consultants (see: http://drupal.org/irc for Drupal Consultants. You can find paid help here, as well as advice on best practices and general discussions surrounding the business side of Drupal. Ask questions here only if you're willing to pay for the advice.)

Maybe open up another issue, link to this one, and from this one to it, describe exactly what you want (like Australia city search) to get working, tag it with "location bounties". And maybe you can get some action. :)

super!

... I'm just adding [#nnnnnn] notation:

#473246: location bounty - get proximity search working

Hi,

I've not understand all the post above... too bad english... and case is complex...

I'm using location_cck and I would like to use the exposed filter by proximity, using the zipcode.
For the moment, as soon as I expose the filter, the result is empty, even without criterion.
I tried the patch http://drupal.org/node/357295 # comment-1239806 but it doesn't work even by lat / lon.
I read something I did not understand about the need to define a relationship (after patched), do I need?

Can anyone help me step by step, to run this search by distance (zipcode)?

My eternal gratitude to the good Samaritan who'll release me from this mess!

I'm really looking forward to seeing this functionality released for the next RC!

This discussion has been all about ZIP/postcodes for proximity searching. Has anyone given any thought to making the same functionality for a larger proximity scope, such as for Country + City?

An alternative could be to enter ZIP or Country+City - then a method to convert to the central ZIP for that city.

Here in Europe we don't have that many huge cities so using a ZIP code is often too specific. For example, I live in the 7th largest city in Italy - which has an area of only 55 square miles. So for us to implement a ZIP codes method seems a little unusual.

What does everyone else thing about this feature?

I think it should be in a separate feature request! ;-)

But it's valid. =)

Feature request for Country + City added: http://drupal.org/node/489904

Thanks. =)

On this specific patch, can we move this on? Can some people test #109 and confirm it works?

If we don't stop adding countries and regions and features then a lot of kittens are going to be massacred. Can we please agree this works and push for it to be committed to -dev?? Anything that was raised in this thread that has NOT been done should be moved to its own issue or we'll never get anywhere. And the maintainer will never review our patch because it's too freakin' big!

#87 worked for me & that was sufficient (with the tweaks I mentioned in #107). I think we should test it (or #109, haven't tried that one) & see if it solves the basic problem.

Adding countries can be a followup issue. This one's long enough as it is :)

Does anyone know if this has been committed yet?

There are so many patches being made for this module and unfortunately when a new DEV is released the added patches are not documented; they're only documented in the official releases.

I wrote this request to try and get more information about the latest DEV because I want to know if the patches I've already applied are included or not. Seems like noone is listening though.

I'm not sure if this has the information you need, but I think there is some info in the cvs messages (link at the bottom of the location project page). And usually when a issue has a patch that fixes the problem and it gets commited, there is a comment on the issue that links to the commit and the issue gets marked fixed. I think for this particular issue, nothing was committed.

It seems like this issue needs someone to do a code review on the patch, and it needs several people to test the patch, and probable a reroll against dev, or at least check to see if it still applies.

There are more and more people hanging out in #drupal-geo maybe if we get more there some progress might be made on some of these more complicated patches.

I know it frustrating, I'm not trying to dismiss you frustration. I'm just trying to think what we can do. And getting this to a RBTC would really increase the odds of getting anything committed.

Good answer. Needs review means needs review. It won't go in until it's reviewed, tested and marked as fixed. Unfortunately, none of my current projects require this, so I won't have time to be involved at this stage. =(

I seem to wind up saying this a lot, but I reiterate my comments everywhere else when a patch like this stalls. Keep the current patch clean and get it tested - then it can go in. If there is feature noise and patches on the patch it will stay in "needs review" limbo forever!

Right now comment #87 contains the candidate for testing. (#91 works, but EvanDonovan rightly remarks in #107 that we're already killing kittens and #91's functionality should move to a new issue). Here's what it is supposed to do:

- Allow postal code lookup for USA and United Kingdom
- It *may* work for other territories too, but not by design

Here's my suggestion to wrap this up:

1. Two more people review and test #87 only - this will then be enough tests to mark it "reviewed & tested"

2. vivianspencer re-rolls #91, removing the stuff in #87, and starts a new issue set to "needs review", where that patch can be tested in isolation and without noise (sorry vivianspencer, your patch is cool but let's save a kitten and review it separately?)

3. Any other new feature requests (including additional countries) should have their own issues created and start their own patches

I totally agree with this, I did think at the time that I should've created a new issue for #91, I'll re-roll the patch for it in a new issue when I get some free time.

Status:Needs work» Needs review

87 doesn't seem to work for me.

If I don't apply it and have proximity as a filter, then nothing shows up in my view except for empty text message.

If I apply it, and have proximity as filter, then all values show up as you would want if a pariticular filter is not being used.

If I apply patch, fill in zip and distance, nothing shows up (empty text is given for view).

I have setup my view with the cck location, my_location, as a relationship.

Proximity filter with relationship- doesn't work
Proximity filter without relationship- doesn't work

do I have to have proximity filter as a field also? I think I do according to the tutorial http://drupal.org/node/359463 (but it does not use cck location)

Edit: I am testing Zip codes in the US with cck location

Thanks for the patch. One more thing. I have the exposed postcode marked as "required" but when left empty and a search is made, results come back. My knowledge of views filters is limited, and I see where it checks in "function query" is the postcode is empty and returns if it is, but I dont see how I can throw an error rather than it running a query and returning all values.

Status:Needs review» Needs work

Ok, so back to "needs work" then. Specifically:

#126 - exposed filter is marked as required but behaves as though it is not required and returns all values - either remove the "required" bit or make it work.

Re: #125, I'm really not clear as to whether this is not working or just a configuration mistake. No offence, but I suspect the latter because too many people (including the comment straight after yours) report it working, so I think you might be doing something wrong. But I can't be sure.

REMEMBER - We're testing #87 ONLY here.

Thanks. =)

Thanks greg. any idea on how to make it truly required and return a form error if it is not filled out ?

In a normal Form API validation context you would use form_set_error()
http://api.drupal.org/api/function/form_set_error

It's probably the same for Views, but I can't be sure off the top of my head.

greg: I'm assuming though the validation should be done at some point before the "query()" function? looking at some other views code there is a value_validate function. I guess I should be using something like that ? Thanks for the advice.

Status:Needs review» Needs work

#127

what is the right configuration then?

I am testing cck location with US Zip codes or does it work only for UK postal addresses?

I applied the patch
I went through the steps I outlined in 125 and tried patch #87 in a number of different combinations

Thanks,
Chris

Chris, should work for US zip codes too. To be honest, it's now a few months since I used it and I have no time right now to dig out my notes! =(

You might be doing nothing wrong. I just have no way of knowing and it's weird it works for other people (but maybe they were all on UK postal codes?)

Issue tags:+australia

Australian zipcodes proximity search problem:
http://drupal.org/node/359463#comment-1804020

Please read #123 and start a separate issue for support of Australian zip codes.

Title:Proximity search views-filter - broken, or missing??Fixing exposed filters in Views for UK and US postal code proximity search
Issue tags:-australia

Just plugged this issue on Twitter, so more meaningful title and removed unnecessary "australia" tag (additional countries, please raise new issues with separate patches or this patch will get too big).

sub. Anyone have an easy way to show nodes nearby another node?

I applied the path in #87 and it's working

I just ran into a strange problem, if I use the link /shops_nearby?distance[postal_code]=2000&distance[country]=be&distance[search_distance]=100&distance[search_units]=km I see the map, if I click on 'Zoeken' the map disappears. The strange thing is that it's only happening with postal code 2000 not with others ....

Update: nvm is probably a caching problem

attkiks, have you used any other patches with the location module at all? And just to be clear, which version of location are you using?

Thanks,
C

The patch in #87 works (in a rough sense) as long as you don't use location_cck.

Status:Needs work» Needs review

Well, three people say this works and two people say it doesn't, so I'm not sure what to do with it, since the problems experienced could not be replicated. Inclined to set it to reviewed and tested. As Jody Lynn says above, this is a rough patch, but anything else would quickly get too large, so I'm for ending this and setting this to reviewed and tested with #87 as the proposed patch.

is this supposed to work with cck location fields?
can someone share exactly what steps they took to get it to work? This might be more a views setup question

thanks!
Chris

I have never tried it, but other replies would indicate it does not work with CCK Locations at this point. Probably need to raise a separate issue called "Make zip code proximity search work with CCK Location fields" and create a patch there.

Title:Fixing exposed filters in Views for UK and US postal code proximity searchFixing exposed filters in Views for UK and US postal code proximity search (not cck location)

I modified this title slightly. It is a long thread and it would be great to easily identify if this worked with cck location vs regular node location.

A

Category:bug» support
Status:Needs work» Active

Hi all,
I'm desperately in need of this feature but I don't know how to apply a patch. So I want to know whether patch #87 has been committed to the dev version.
Regards.

<?php

code lookup
.
      if (!empty(
$this->value['postal_code']) && !empty($this->value['country'])) {
       
$location = array('country'=> $this->value['country'], 'postal_code' => $this->value['postal_code']);
       
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $location['postal_code'], $location['country']);
        if (
$r = db_fetch_array($res)) {
         
$this->value['latitude'] = $r['latitude'];
         
$this->value['longitude'] = $r['longitude'];
        }
       
$coord = location_latlon_rough($location);
        if (
$coord) {
         
$this->value['latitude'] = $coord['lat'];
         
$this->value['longitude'] = $coord['lon'];
        }
        else {
          return
false;
        }
      }
      else {
       
// @@@ Implement full address lookup?
       
return false;
      }
    }
    if (empty(
$this->value['latitude']) || empty($this->value['longitude'])) {
      return
false;
    }
    return
true;
  }
  function
query() {
   
$this->value['country'] = variable_get('location_default_country', 'us');
    if (empty(
$this->value)) {
      return;
    }
    if (empty(
$this->value['postal_code'])) {
      return;
    }
    if (!empty(
$this->value['postal_code'])) {
     
// uk postcodes are weird - we need to make a special case:
     
if ($this->value['country'] == 'uk') {
       
$postcode = strtoupper(str_replace(' ','',$this->value['postal_code']));
        if (
preg_match("/^[A-Z]{1,2}[0-9]{2,3}[A-Z]{2}$/",$postcode) || preg_match("/^[A-Z]{1,2}[0-9]{1}[A-Z]{1}[0-9]{1}[A-Z]{2}$/",$postcode) || preg_match("/^GIR0[A-Z]{2}$/",$postcode)) {
         
preg_match('/^[a-zA-Z]*[0-9 ]+/', $this->value['postal_code'], $matches);
         
$this->value['postal_code'] = substr_replace(str_replace(' ', '', $matches[0]), '', -1);
        }
      }
     
$res = db_query("SELECT latitude, longitude FROM {zipcodes} WHERE"." zip = '%s' AND country = '%s'", $this->value['postal_code'], $this->value['country']);
      if (
$r = db_fetch_array($res)) {
       
$this->value['latitude'] = $r['latitude'];
       
$this->value['longitude'] = $r['longitude'];
      }
    }
    if (empty(
$this->value['search_distance'])) {
     
$this->value['search_distance'] = 1;
    }

?>

I don't believe any patch has yet been committed to the dev version. If you can, please review the patch in #87. Several people have stated that it works for them, but some have had issues. We need to get this one to the "reviewed" state in order to get it committed, and your review would help!

Please don't change the status, though, when there is a patch still waiting for review. And don't change a bug report to a support request - it is not helpful for the module maintainers. Thanks.

Helo,

I have finally been able to search based on proximity/distance and postal code (us) using the patch in #87.

Thanks all, I can now breath.

Cheers.

Status:Needs review» Reviewed & tested by the community

I think enough people have confirmed this works with standard location data to call it reviewed and tested...?

++

Works for me. Now all show when no zip code is entered and optional is selected.

The fix in #91 worked for me too but I'm having an issue that it seems no one else has come across and I can't figure out why.

I can search US zip codes just fine, get the proper results and everything. But Canada doesn't work for me at all. I've tried several different postal code lists and reintered my nodes several times for testing and no matter what I do I can't get a proximity search to work using Canadian postal codes. When I enter one in the view and preview it the query shows 'Unknown' where it normally shows the location equation. (see below)

-- CANADIAN POSTAL CODE --
SELECT location.lid AS lid,
location.name AS location_name,
'Unknown' AS location_distance_2
FROM location location
LEFT JOIN location_instance location_instance ON location.lid = location_instance.lid
LEFT JOIN node node ON location_instance.vid = node.vid
WHERE (node.status <> 0) AND (node.type in ('distributor')) AND (0) AND (location.latitude > -1.4457010075519 AND location.latitude < 1.4457010075519 AND location.longitude > -1.4457010075519 AND location.longitude < 1.4457010075519) AND ((IFNULL(ACOS(1*COS(RADIANS(location.latitude))*(1*COS(RADIANS(location.longitude)) + 0*SIN(RADIANS(location.longitude))) + 0*SIN(RADIANS(location.latitude))), 0.00000)*6378137) < 160934.7)
ORDER BY location_name ASC

-- US POSTAL CODE --
SELECT location.lid AS lid,
location.name AS location_name,
(IFNULL(ACOS(0.78800600415191*COS(RADIANS(location.latitude))*(0.042890871306988*COS(RADIANS(location.longitude)) + -0.99907976316134*SIN(RADIANS(location.longitude))) + 0.61566755430227*SIN(RADIANS(location.latitude))), 0.00000)*6370005.8356178) AS location_distance_2
FROM location location
LEFT JOIN location_instance location_instance ON location.lid = location_instance.lid
LEFT JOIN node node ON location_instance.vid = node.vid
WHERE (node.status <> 0) AND (node.type in ('distributor')) AND (location.latitude > 36.552895588716 AND location.latitude < 39.447988411284 AND location.longitude > -89.378873176432 AND location.longitude < -85.704686823568) AND ((IFNULL(ACOS(0.78800600415191*COS(RADIANS(location.latitude))*(0.042890871306988*COS(RADIANS(location.longitude)) + -0.99907976316134*SIN(RADIANS(location.longitude))) + 0.61566755430227*SIN(RADIANS(location.latitude))), 0.00000)*6370005.8356178) < 160934.7)
ORDER BY location_distance_2 ASC, location_name ASC

Any idea what could be going wrong?

@merzikain, please see the issue title - there is no intention of this patch working for Canada.

If you need Canadian postcodes, start a NEW feature request asking for it, as described here:
http://drupal.org/node/321114#comment-1780068

I wonder if any of the maintainers have any free time at the moment. There are a lot of issues in the queue and this patch as been "reviewed and tested" for ages.... =(

@greg.harvey: maybe someone can find one of them in IRC and ask?

Status:Reviewed & tested by the community» Needs work

The patch in #87 is reviewed and tested, but no longer applies to the latest dev snapshot. =(

If we want this in, someone needs to re-roll it. I will try and find time, but no promises. If someone else gets chance, please go ahead.

And PLEASE don't sneak any features in to a re-roll. We're desperately trying to keep this clean and not kill kittens. Thanks!

+1

Please reroll this because I'm looking to get proximity to work but can't currently.

Thanks!!

#86 applies cleanly against the current 3.x dev version. But it's relative to the handlers directory. I was going to re-roll it for you, but don't think it's probably necessary given that. I'll be happy to, but wouldn't want to muddy the waters.

Status:Needs work» Reviewed & tested by the community

So in that case I'll make it RTBC again.

@rfay: brilliant, thanks. I didn't actually try it. Someone reported on IRC that it didn't apply - with your additional instruction hopefully that will be enough. =)

StatusFileSize
new2.85 KB

Here is the patch from #87 rerolled. This one applies from the location directory (which is where it should be rolled from) against today's 3.x-dev. I don't actually have anything to say about whether it works or not. QuickGold could not apply #86 on freebsd.

Thank you to rfay for rerolling this patch. I got it to work against the current 3.x-dev version on FreeBSD. Additionally, I got the proximity function to work as well. Huzzah!

Great stuff - so #159, re-rolled by rfay, is the candidate. Now, where are those maintainers? =P

Is this module actually maintained anymore? Seems to be lots of unanswered issues, and patches that have been around for a while and not applied to the dev version. Is the maintainer around ?

bdragon is the maintainer of Location & Gmap and he did an excellent job for a long time. We'll have to see if we can find him in IRC or elsewhere. Probably, like many of us, other priorities have taken precedence.

Maybe if we could find a co-maintainer who also was familiar with the code.

It's a hell of a codebase. Too much for one person, IMHO. Unfortunately I already maintain a fist full of modules and can't take on any more.

subscribe

Status:Reviewed & tested by the community» Needs review

Patch still applies.
I was unable to get an exposed Distance/Proximity filter to work.
Also tried it over here but now completely the opposite is happening. After applying the patch, try as I may, I was unable to filter the data, all records are always displayed.

More testing required, bumped to needs review.

subscribe

subscribe

Subscribing

This is the only patch I have found for this module that hasn't failed in Terminal, (I'm on a Mac).

However, it hasn't fixed the bug for me.

Seems this issue has been around for a while. Has anyone had success getting an exposed filter to work using a parameter from the location module?

Have people reverted to using a taxonomy vocabulary instead?

yes,

completemytracks.com

Though the state/province autocomplete seems to be buggy. I sometimes get an error message, and sometimes it works fine. When it gives an error msg, users have to type the state name fully, autocomplete will not suggest/finish what was started to be typed

Anyone else have this problem?

@teremka, yes, lots of people had it working - that's why it was marked R&TBC. I'm not sure why so many people are having problems. The original patch worked fine for me and others too. =/

i'm not savy enough to apply patches yet...i'm a green check mark drupal user guy....paranoid about those red x dev versions too..
I suppose I need to create a test website and get my hands dirty eventually

With the patch from #159, the query always shows: location.latitude > -1.44570100755 AND location.latitude < 1.44570100755 AND location.longitude > -1.44570100755 AND location.longitude < 1.44570100755.

Always "1.44570100755", no matter what zipcode/country combination I enter. This doesn't make any sense.

Fix:

with patch from #159, on line 198 you see $this->value['country'] = variable_get('location_default_country', 'us');.

Uncomment that line! It makes no sense to set the cc to us again, because we already know we're in the uk.

-

Status:Needs review» Needs work

Fix in #175 needs rolling in to patch in #159. Setting to "needs work". Though all this feels a bit futile, in the absence of any obvious project maintainer. =(

I'm here, I'm just way behind on the queue.

Ah, welcome back! Good news.

Off topic, but you're on your own? Is there anything we can do to help? I don't think I have much time, but if you want co-maintainers, I can start drumming up some candidates for you? Location is a monster of a module to look after. =)

There are actually quite a few people who can commit, but I still end up doing nearly all the committing.

One big issue is I don't have my dev environment set up properly as I switched computers a while ago, so it's impossible at the moment to do "5 minute fixes". I'll get that sorted out soon though.

anyone get the following when running patch in #87 ?:

Hunk #1 FAILED at 167.
Hunk #2 FAILED at 195.

I reworked the patch from #159, removed the buggy line, and added a 'missing zipcode automatic lookup' feature. It will make your proximity filter work for the whole world. Even without zipcodes.xx.mysql databases. Find the patch here:
#662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes

Also notice my solution for Australian and Belgian zipcodes.xx.mysql:. The lon/lat columns were mixed up in zipcodes.xx.mysql files:
#661338: Longitude & latitude are swapped in zipcodes.mysql for BE and AU (location.xx.inc).

India and Norway zipcodes databases are also wrong (India has everything 0, Norway is simply wrong). Don't use them, use my patch for world-wide lookup feature instead.

Guys, I'm sorry for just busting in here, and questioning work that's apparently being discussed for more than half a year.... but I'm doing it anyway :-p

Are you sure you want that functionality (from a.o. patch #87 / #159) added to location_views_handler_filter_proximity?
I mean, as opposed to location_get_postalcode_data()?

Secondly, are you sure you want to be adding country specific logic to this file? That stuff should be in supported/location.CC.inc, right?

My take on this: in #3 /#4 of #662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes.
It unfortunately does need another API change. But IMHO that seems worth it. It eases confusion about which functionality should go where.

Category:support» bug
Status:Active» Needs work

YesCT: you are most likely correct about that patch being better. When I started using this in production, that patch didn't exist yet. I will test that one soon, hopefully.

Priority:Normal» Critical

OK. I dont know everything about the code, or about what Bdragon wants to do, but I guess it is a combination of both... for now.

See: http://drupal.org/node/662892#comment-2804114
in #662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes

I think we need a setting that will either geocode whatever is in the exposed filter, or use the zipcode/lat/long info (after it is fixed... and this issue is about fixing it, yes?)

What do people think?

What do we need to evaluate this patch?

...

If someone wants to help and has not reviewed a patch before:
How to review a patch: http://drupal.org/patch/review
Can someone do like a code formatting review? http://drupal.org/coding-standards
Can someone please try this with the coder module: http://drupal.org/project/coder

I think it needs to be rerolled against the March commits. (or at least can someone try it on the newest dev and say it patches with no errors?)

Will committing this break anything? (I think it says somewhere in the comments above about an api change.)

I need a general summary of the status of this patch. :)

And... pretend you were the location maintainer... what would you put in the log if this were committed, what would you add to the change log?

subscribe: note to self US postal code proximity search

Issue tags:+location bounties

for general module health there is good news. now 3 people making commits and I might drum up one more. Lots of bug fixes have gotten in in the last month. So it is no longer futile to review or propose patches! But the module needs a release now to give everyone a good starting point to tackle some of the hard issues. Please see if you can help with #606342: Views Argument Handler for Proximity It is mentioned in #664472: [master] Release of Location 6.x-3.1?

Dont give up hope, things are turning around!

subscribe

Subscribing, greetings, Martijn

Hello,

I tried the patch mentioned in #159, but it needs to be "re-rolled" again. The latest release doesn't fix the problem of the exposed proximity filter not having any effect on the results list. The patch in #159 can no longer be implemented because the code has changed and some of the lines to be modified don't exist.

I could really use this, I hope that there is still some interest in fixing this issue. I would be willing to contribute to a bounty for anyone interested in fixing this.

StatusFileSize
new9.82 KB

All I can do for you quickly, is post a diff between the 3.1 release of location, and my personal development tree. Could you test this? I have not extensively tested since 3.1 came out (but it seems to work for me).

This is not the above patch, but my take on things (#662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes)
It is the patch in comment #16 in that issue, rerolled.

I'm still here and will at some point go through all the comments > #16 in that issue, incorporate all their changes, and give a proper summary addressing a.o. YesCT's comments. Unless someone else beats me to it, in fixing this.

...someday 'maybe soon'. This just always seems to get pushed off my to-do list by 'stuff that needs finishing now' :)

subscribing

I think we should "won't fix" this issue in favor of #662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes. For me, at least, the postal code proximity filter is working in the 6.x-3.x-dev as of now.

The changes of that issue's #16 / the re-roll in #81 make sense to me, although I'm not entirely sure how they related to the (1=0) in the query bug that is also mentioned in there. I can't tell what #25/#28 adds that wasn't in the other patches - if someone could clarify that would be great.

If no one has a compelling reason why this issue should remain open, I will close it within a week.

Status:Needs work» Closed (fixed)

I haven't been able to reproduce this bug using the latest version of the module. It could be that this has been fixed more recently.