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?
Comment | File | Size | Author |
---|---|---|---|
#192 | 321114-662892-intermediate.patch | 9.82 KB | roderik |
#159 | location_proximity_rerolled_321114.patch | 2.85 KB | rfay |
#109 | location_views_handler_filter_proximity.357295.inc_.txt | 11.08 KB | juicytoo |
#100 | nl_postal_db.zip | 51.17 KB | libeco |
#91 | location_views_handler_filter_proximity.inc_.patch | 5.89 KB | vivianspencer |
Comments
Comment #1
danielnolde CreditAttribution: danielnolde commentedComment #2
danielnolde CreditAttribution: danielnolde commentedbtw: 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?
Comment #3
YesCT CreditAttribution: YesCT commentedin 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."
Comment #4
lee20 CreditAttribution: lee20 commentedIn 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'])) {
Comment #5
YesCT CreditAttribution: YesCT commentedthe release notes for rc2 might say something about this issue.
Comment #6
dharmanerd CreditAttribution: dharmanerd commentedyeah, what's the deal w/ this?
Comment #7
bdragon CreditAttribution: bdragon commentedOops!
I forgot to implement the zipcode stuff. DOH!
Coding it now.
Comment #8
bdragon CreditAttribution: bdragon commentedWhat the hell? I forgot to implement the nice distance too?!?
For the record, it's accepting distance in METERS, of all units.. *sigh*..
Comment #9
daneyuleb CreditAttribution: daneyuleb commentedCan some more info be given on the state of this?
Is it in the current dev? And...if so...how generally is it accessed?
Comment #10
kenwen CreditAttribution: kenwen commentedSubscribing
Again, this is a much wanted feature (especially if it will work in UK!) and we are willing to pay for this as well :)
Comment #11
dynamite CreditAttribution: dynamite commentedHi, 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
Comment #12
danielnolde CreditAttribution: danielnolde commentedBrandon, 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...
Comment #13
theabacus CreditAttribution: theabacus commentedSubscribing
Comment #14
bdragon CreditAttribution: bdragon commentedErr, I think I did development in my second staging install and forgot to finish it. Looking into it.
Comment #15
lyricnz CreditAttribution: lyricnz commentedI 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.
Comment #16
danielnolde CreditAttribution: danielnolde commentedhey 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...
Comment #17
danielnolde CreditAttribution: danielnolde commented[double post]
Comment #18
lyricnz CreditAttribution: lyricnz commentedYes, 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).
Comment #19
danielnolde CreditAttribution: danielnolde commented> 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.
Comment #20
danielnolde CreditAttribution: danielnolde commented[double post]
Comment #21
YesCT CreditAttribution: YesCT commentedthe 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
Comment #22
danielnolde CreditAttribution: danielnolde commentedyes, 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.
Comment #23
daneyuleb CreditAttribution: daneyuleb commentedHow 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?
Comment #24
YesCT CreditAttribution: YesCT commentedI'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!
Comment #25
lyricnz CreditAttribution: lyricnz commenteddanielnolde. 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.
Comment #26
YesCT CreditAttribution: YesCT commentedI 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.
Comment #27
1kenthomas CreditAttribution: 1kenthomas commentedAlso does not seem to be working in 5.x-3.x at this time. Is this correct?
Comment #28
Matt Townsend CreditAttribution: Matt Townsend commentedRe: #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.
Comment #29
lyricnz CreditAttribution: lyricnz commentedIt'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.
Comment #30
bdragon CreditAttribution: bdragon commentedAlmost 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.)
Comment #31
bdragon CreditAttribution: bdragon commentedCommitted 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!
Comment #32
1kenthomas CreditAttribution: 1kenthomas commentedSome kudos to bdragon for headbanging... ;)
Comment #33
YesCT CreditAttribution: YesCT commentedbdragon rock on! I'm gonna go try it out!
Comment #34
jerry CreditAttribution: jerry commentedSubscribing.
Comment #35
danielnolde CreditAttribution: danielnolde commentedshweeet :))
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
Comment #36
daneyuleb CreditAttribution: daneyuleb commentedThanks 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.
Comment #37
danielnolde CreditAttribution: danielnolde commenteddaniel (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.
Comment #38
theabacus CreditAttribution: theabacus commentedHmm...
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.
Comment #39
SilenceEchoed CreditAttribution: SilenceEchoed commentedI'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.
Comment #40
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedproxiity 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.
Comment #41
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedthis 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
Comment #42
Anonymous (not verified) CreditAttribution: Anonymous commentedIs 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.
Comment #43
zirafa CreditAttribution: zirafa commentedI 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).
Comment #44
kenorb CreditAttribution: kenorb commentedI 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.
Comment #45
DesignWork CreditAttribution: DesignWork commentedHi 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.
Warm regards from cologne
Dirk
Comment #46
DesignWork CreditAttribution: DesignWork commentedHi 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.
Dirk
Comment #47
zirafa CreditAttribution: zirafa commentedDirk,
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.
Comment #48
DesignWork CreditAttribution: DesignWork commentedhi 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
Comment #49
jrosen CreditAttribution: jrosen commentedI 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.
Comment #50
ohira CreditAttribution: ohira commentedHi 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
if Google API is not responding.
Oliver
Comment #51
d.clarke CreditAttribution: d.clarke commentedJrosen's patch in #49 of DesignWork's code posted in #46 resolved the issue for me. Can we get this committed to the project?
Comment #52
keva CreditAttribution: keva commentedInstalled 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.
Comment #53
cedrix CreditAttribution: cedrix commentedhi,
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
Comment #54
bdragon CreditAttribution: bdragon commentedWoah, location_latlon_rough is totally broken.
Comment #55
bdragon CreditAttribution: bdragon commentedI take that back, I had forgotten to load my zipcode table.
(The api still sucks though. :P)
Comment #56
daneyuleb CreditAttribution: daneyuleb commentedSince 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.
Comment #57
DesignWork CreditAttribution: DesignWork commentedhi 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
Comment #58
DesignWork CreditAttribution: DesignWork commentedHi daneyuleb,
describe a bit more what you wanna do? I´m willing to help.
Dirk
Comment #59
spyderpie CreditAttribution: spyderpie commentedThis 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
Comment #60
bjalford CreditAttribution: bjalford commentedI'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?
Comment #61
YesCT CreditAttribution: YesCT commentedcould 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?
Comment #62
burgs CreditAttribution: burgs commentedsubscribing
Comment #63
scottrigby#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
Comment #64
dionysio CreditAttribution: dionysio commentedI 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.
Comment #65
keva CreditAttribution: keva commentedIt 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.
Comment #66
jrglasgow CreditAttribution: jrglasgow commented@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.
Comment #67
jrglasgow CreditAttribution: jrglasgow commentedThis 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()
If coordinates are not available, but if the distance is set we force noting to match.
I changed the code to look like this:
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
Comment #68
YesCT CreditAttribution: YesCT commentedTagging.
Comment #69
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedis 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
Comment #70
internets CreditAttribution: internets commentedI 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.
Comment #71
YesCT CreditAttribution: YesCT commentedTagging 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.
Comment #72
YesCT CreditAttribution: YesCT commented#172020: How to filter nodes by street, postal code, city, country
#212943: Distance Searching / Location proximity filter
marked as duplicate
Comment #73
YesCT CreditAttribution: YesCT commented#189755: Location:Proximity Exposed Filter Error
marked as duplicate
Comment #74
YesCT CreditAttribution: YesCT commentedmarked #354755: Location Search a duplicate of this issue.
Comment #75
greg.harveyStill 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:
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:
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. =(
Comment #76
greg.harveyForgot to change status...
Comment #77
scottrigby@greg.harvey: did you try the patch in #63?
Comment #78
greg.harveyI 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! =)
Comment #79
scottrigby@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)).
Comment #80
greg.harveyGreat - 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! =)
Comment #81
YesCT CreditAttribution: YesCT commented#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.
Comment #82
greg.harveyHmmm, 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:
Problem is here:
$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?
Comment #83
greg.harveyGot 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 bewhere zipcode = 'NG22'
.As such, I've added a little to your patch:
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?Comment #84
iThinkWorks CreditAttribution: iThinkWorks commentedsubscribe
Comment #85
vivianspencer CreditAttribution: vivianspencer commented@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
Comment #86
dzepol CreditAttribution: dzepol commentedsubscribe. Tested it out. Works great.
Comment #87
vivianspencer CreditAttribution: vivianspencer commentedComment #88
greg.harvey@vivianspencer: Sorry, I got lazy - it wasn't a requirement for me. ;-)
Thanks for fixing!
Comment #89
greg.harveyPs - anyone got thoughts on that redundant function? Seems it ought to be updated and used or deleted entirely...!
Comment #90
YesCT CreditAttribution: YesCT commentedtagging
Comment #91
vivianspencer CreditAttribution: vivianspencer commentedComment #92
vivianspencer CreditAttribution: vivianspencer commentedSorry, 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
Comment #93
YesCT CreditAttribution: YesCT commentedre #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?
Comment #94
YesCT CreditAttribution: YesCT commentedre #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?
Comment #95
vivianspencer CreditAttribution: vivianspencer commentedThe 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"
Comment #96
YesCT CreditAttribution: YesCT commentedThanks!
Comment #97
libeco CreditAttribution: libeco commentedTried 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
Comment #98
greg.harvey@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.
Comment #99
libeco CreditAttribution: libeco commentedHmm, didn't realise they both fixed different problems. I'll try it out right now!
Thanks!
Comment #100
libeco CreditAttribution: libeco commentedI'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)
Comment #101
greg.harveyAh, 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. =(
Comment #102
vivianspencer CreditAttribution: vivianspencer commentedThe 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
Comment #103
greg.harvey@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!
Comment #104
libeco CreditAttribution: libeco commentedThanks, but both the Netherlands and Belgium are supported it says on that page.
Comment #105
greg.harveyOk, 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! =)
Comment #106
libeco CreditAttribution: libeco commentedOK, 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!
Comment #107
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #108
mrtoner CreditAttribution: mrtoner commented#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.
Comment #109
juicytoo CreditAttribution: juicytoo commentedHi,
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
Comment #110
glass.dimly CreditAttribution: glass.dimly commentedTutorial 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.
Comment #111
YesCT CreditAttribution: YesCT commentedjuicytoo (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. :)
Comment #112
juicytoo CreditAttribution: juicytoo commentedYesCT: done ;-) http://drupal.org/node/473246
Comment #113
YesCT CreditAttribution: YesCT commentedsuper!
... I'm just adding [#nnnnnn] notation:
#473246: location bounty - get proximity search working
Comment #114
webanalya CreditAttribution: webanalya commentedHi,
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!
Comment #115
andrewsuth CreditAttribution: andrewsuth commentedI'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?
Comment #116
greg.harveyI think it should be in a separate feature request! ;-)
But it's valid. =)
Comment #117
andrewsuth CreditAttribution: andrewsuth commentedFeature request for
Country
+City
added: http://drupal.org/node/489904Comment #118
greg.harveyThanks. =)
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!
Comment #119
EvanDonovan CreditAttribution: EvanDonovan commented#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 :)
Comment #120
Phil Wolstenholme CreditAttribution: Phil Wolstenholme commentedDoes anyone know if this has been committed yet?
Comment #121
andrewsuth CreditAttribution: andrewsuth commentedThere 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.
Comment #122
YesCT CreditAttribution: YesCT commentedI'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.
Comment #123
greg.harveyGood 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
Comment #124
vivianspencer CreditAttribution: vivianspencer commentedI 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.
Comment #125
SocialNicheGuru CreditAttribution: SocialNicheGuru commented87 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
Comment #126
exobuzz CreditAttribution: exobuzz commentedThanks 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.
Comment #127
greg.harveyOk, 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. =)
Comment #128
exobuzz CreditAttribution: exobuzz commentedThanks greg. any idea on how to make it truly required and return a form error if it is not filled out ?
Comment #129
greg.harveyIn 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.
Comment #130
exobuzz CreditAttribution: exobuzz commentedgreg: 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.
Comment #131
SocialNicheGuru CreditAttribution: SocialNicheGuru commented#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
Comment #132
greg.harveyChris, 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?)
Comment #133
joodas CreditAttribution: joodas commentedAustralian zipcodes proximity search problem:
http://drupal.org/node/359463#comment-1804020
Comment #134
greg.harveyPlease read #123 and start a separate issue for support of Australian zip codes.
Comment #135
greg.harveyJust 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).
Comment #136
niles CreditAttribution: niles commentedsub. Anyone have an easy way to show nodes nearby another node?
Comment #137
attiks CreditAttribution: attiks commentedI applied the path in #87 and it's working
Comment #138
attiks CreditAttribution: attiks commentedI 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
Comment #139
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedattkiks, 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
Comment #140
Jody LynnThe patch in #87 works (in a rough sense) as long as you don't use location_cck.
Comment #141
greg.harveyWell, 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.
Comment #142
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedis 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
Comment #143
greg.harveyI 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.
Comment #144
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedI 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
Comment #145
tamasco CreditAttribution: tamasco commentedHi 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.
Comment #146
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #147
tamasco CreditAttribution: tamasco commentedHelo,
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.
Comment #148
greg.harveyI think enough people have confirmed this works with standard location data to call it reviewed and tested...?
Comment #149
Nathaniel CreditAttribution: Nathaniel commented++
Works for me. Now all show when no zip code is entered and optional is selected.
Comment #150
merzikain CreditAttribution: merzikain commentedThe 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?
Comment #151
greg.harvey@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
Comment #152
greg.harveyI 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.... =(
Comment #153
EvanDonovan CreditAttribution: EvanDonovan commented@greg.harvey: maybe someone can find one of them in IRC and ask?
Comment #154
greg.harveyThe 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!
Comment #155
DrupalKing CreditAttribution: DrupalKing commented+1
Please reroll this because I'm looking to get proximity to work but can't currently.
Thanks!!
Comment #156
rfay#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.
Comment #157
rfaySo in that case I'll make it RTBC again.
Comment #158
greg.harvey@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. =)
Comment #159
rfayHere 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.
Comment #160
DrupalKing CreditAttribution: DrupalKing commentedThank 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!
Comment #161
greg.harveyGreat stuff - so #159, re-rolled by rfay, is the candidate. Now, where are those maintainers? =P
Comment #162
exobuzz CreditAttribution: exobuzz commentedIs 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 ?
Comment #163
EvanDonovan CreditAttribution: EvanDonovan commentedbdragon 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.
Comment #164
greg.harveyIt'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.
Comment #165
drumnjo CreditAttribution: drumnjo commentedsubscribe
Comment #166
nickl CreditAttribution: nickl commentedPatch 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.
Comment #167
fletch11 CreditAttribution: fletch11 commentedsubscribe
Comment #168
kpojeta CreditAttribution: kpojeta commentedsubscribe
Comment #169
resynthesize CreditAttribution: resynthesize commentedSubscribing
Comment #170
solona CreditAttribution: solona commentedThis 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?
Comment #171
drumnjo CreditAttribution: drumnjo commentedyes,
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?
Comment #172
greg.harvey@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. =/
Comment #173
drumnjo CreditAttribution: drumnjo commentedi'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
Comment #174
Anonymous (not verified) CreditAttribution: Anonymous commentedWith 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.
Comment #175
Anonymous (not verified) CreditAttribution: Anonymous commentedFix:
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.
Comment #176
drumnjo CreditAttribution: drumnjo commented-
Comment #177
greg.harveyFix 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. =(
Comment #178
bdragon CreditAttribution: bdragon commentedI'm here, I'm just way behind on the queue.
Comment #179
greg.harveyAh, 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. =)
Comment #180
bdragon CreditAttribution: bdragon commentedThere 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.
Comment #181
drumnjo CreditAttribution: drumnjo commentedanyone get the following when running patch in #87 ?:
Hunk #1 FAILED at 167.
Hunk #2 FAILED at 195.
Comment #182
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #183
roderikGuys, 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.
Comment #184
YesCT CreditAttribution: YesCT commentedany reason to just say wont fix on this and point everyone to #662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes?
post your use case now for why you need this and cannot use #662892: (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes.
Comment #185
EvanDonovan CreditAttribution: EvanDonovan commentedYesCT: 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.
Comment #186
YesCT CreditAttribution: YesCT commentedOK. 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?
Comment #187
chriscalip CreditAttribution: chriscalip commentedsubscribe: note to self US postal code proximity search
Comment #188
YesCT CreditAttribution: YesCT commentedfor 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!
Comment #189
sgallen CreditAttribution: sgallen commentedsubscribe
Comment #190
Summit CreditAttribution: Summit commentedSubscribing, greetings, Martijn
Comment #191
nasheet CreditAttribution: nasheet commentedHello,
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.
Comment #192
roderikAll 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' :)
Comment #193
jerry CreditAttribution: jerry commentedsubscribing
Comment #194
EvanDonovan CreditAttribution: EvanDonovan commentedI 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.
Comment #195
ankur CreditAttribution: ankur commentedI 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.