For a project I rely on the proximity filter. I use it with a Gmap to create a store locator. Currently, location.module uses the zipcodes table with a set of zipcodes.xx.mysql files to pre-populate latitudes and longitudes.

But I needed a world wide store locator... So I thought, why not geocode missing zipcodes via the location maps API? I created a patch for the proximity handler and another patch for a small change to install.module:

- we lookup a zipcode in zipcodes table
- if found, OK
- if NOT, then lookup via location.module geocoding (e.g. Google Maps API)
- store the zipcode + country + coordinates in the zipcodes table
- from now on, we can find this zipcode in our zipcodes table

(Invalid zipcodes are never stored, because the geocoder would return empty data.)

Important: my patch includes the patch from comment 159 at #321114, with some re-working and bugfixing!

The zipcodes table also holds city, state, DST and timezone data. Of course that will not be populated automatically. So to make my patch work, the zipcodes table has to have NULL values for city and state. DST and timezone will be 0. Incorrect, but a small price to pay for Drupal's first world wide proximity filter.

I included the patch for location.install file (city state NULL in zipcodes).

This is my first Drupal patch by the way.

--
Check out my world wide store locator!
http://www.magentosites.net/stores/locator

Comments

SocialNicheGuru’s picture

how do I set the default to a user location of the user logged in?

roderik’s picture

StatusFileSize
new9.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cache-normalized-zipcodes.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Okay... I'm going to try and approach this issue from another angle.
I was trying to get the same thing to work, and got lost in the API and a number of different issues in this queue.
And in the end, decided to code & propose a different approach.

-----

My attempt at a summary - feel free to skip to the proposed solution:

What we have here is:
1 location_views_handler_filter_proximity->calculate_coords(), calling:
2 location_latlon_rough(), which calls
3 a country-specific function (location_latlon_rough_CC())

Things:
- This is the only call to location_latlon_rough() that is still present in the location codebase. The rest has already been converted to use location_get_postalcode_data(). Maybe we should do this at the same time.

- The patch in this issue (code which comes from #321114: Fixing exposed filters in Views for UK and US postal code proximity search (not cck location)) puts country specific logic in layer 1. That logic should be in layer 3 instead.

- Layer 2 has no code that tries to retrieve the postal code from the {zipcodes} table. At this moment, the code is in layer 3 which means that some countries (US, CA, DE at the moment) do and some countries don't have that functionality. This leads to:
- patches like the above, that try to add this functionality to layer 1, plus at the same time adding functionality for calling location_latlon_exact() and caching the resolved lat/longitude in the {zipcodes} table
- patches like http://drupal.org/node/73714#comment-2112578 which try to do the same things in layer 3
Both things lead to code duplication. Adding stuff in layer 3 makes it work only per country. In layer 1 it works only per 'calling function'.

- The reason why it's in layer 3 now, is that postal codes need to be properly 'normalized' before the database query can work.

-----

The only good solution I could come up with, involves creating new API functions.
Summary of what the patch does:
- separating 'zipcode normalization' from 'lat/lon retrieval from database based on zipcode'
- creating a new country-specific function for the first
- adding the second to location_get_postalcode_data()
- adding (optionally executed) code to location_get_postalcode_data(), to geocode a zipcode+country+... field, and cache this in the database.

Details:

1)
Added to location.inc: function location_standardize_postalcode(&$postalcode, $country = 'us')
which does almost nothing itself, but calls location_standardize_postalcode_CC(&$postalcode)

This normalizes a postal code for a certain country. I modeled it after location_standardize_country_code(), to modify the first argument and return TRUE/FALSE - but it may be set up in another way. (Also the second argument might be mandatory; I don't care.)

It should be its own function IMHO, because 'normalizing a postal code' is a general function that does not need to be entangled with e.g. retrieving lat/lon coordinates from the database.

2)
Added to location.inc:location_get_postalcode_data():
- call to location_standardize_postalcode()
- the standard code that looks into {zipcodes} to retrieve the cached lat/lon data.

NB: location_standardize_postalcode() does not actually need to be there; I could have called location_standardize_postalcode_CC() directly. But it seemed nice to have the function anyway.

3)
Added an optional 2nd argument to location_get_postalcode_data().
If set to TRUE, and the postal code is not found in {zipcodes}, the function will attempt to do geocoding (by calling location_latlon_exact()) - and after success, cache the postalcode/lat/lon values in {zipcodes}.

The default of this argument should be set to FALSE, because often the caller (most notably _location_geo_logic()) will already have called location_latlon_exact() before calling this function. So no need for duplication.

Whenever you call this with TRUE, the {zipcodes} table may end up with a new data row with empty city/state fields (if these aren't specified in the first argument) - just like the original message in this issue says.
And also with empty timezone/dst fields. In order to at least possibly be able to fill these, I created another 'API function': location_timezone_data_CC($location). I don't know how useful it is, but I didn't know where else to put it and didn't want to lose the 'functionality' (adding the value 1 for these fields) that is in the patch in http://drupal.org/node/73714#comment-2112578.

-----

The behaviour of the code before/after the patch, is the same... EXCEPT for the call from location_views_handler_filter_proximity->calculate_coords(): its behaviour is the same as after applying the patch above##. (i.e. it ends up filling {zipcodes} with empty city/state fields.)
Note that the postal code in the caller of location_get_postalcode_data() is not changed/normalized. Only the one in the database/retrieval code.

I'm not sure whether these changes sit well with other code, and with other planned API changes.
(For instance, the usefulness of location_get_postalcode_data_CC() is up for discussion after this patch. I could actually have deleted these functions from the location.CC.inc files after adding the location_standardize_postalcode_CC(). But I haven't done so yet.)

So I'm uncomfortable saying that this is how we want to go. I think it's kinda neat, though, and gets rid of some confusion in (or the need for) at least
#73714: Support for the Netherlands (NL) location.nl.inc location.xx.inc
#321114: Fixing exposed filters in Views for UK and US postal code proximity search (not cck location)
(#661338: Longitude & latitude are swapped in zipcodes.mysql for BE and AU (location.xx.inc) #3)

I can document the functions in location.CC.inc and location_API.txt - but only after I hear maintainers saying they agree with the approach.
(Note I'm saying that I'll do it, not _when_ ;) )

## P.S.: I notice that in the patch above, a default $this->value['search_distance'] = 1 is set.
That functionality I did not include in my patch; it's a separate issue IMHO.

roderik’s picture

StatusFileSize
new9.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cache-normalized-zipcodes_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Amending unnecessary comparison in location_standardize_postalcode_nl()

nyleve101’s picture

Hi morningtime,

I have implemented your patches but still can't get my proximity views search to work. Do you have step by step instructions on how you configured your postcode proximity search view for http://www.magentosites.net/stores/locator?

Any help is appreciated.

Thanks

Evelyn

aze2010’s picture

Hello Folks,

i do need a solutions like other people here, but i dont know how to implement.

I would like to have a filter: "A user with a user-profile an Coordinates should see in a Block/View, WHICH NODES are near by".
Summary: User-Location <-> Node-Location: User => Which Nodes are near by the user(-profile) coords.

How can i implement such a function/filter with Location and Distance?

Thank you in advanced and i finally hope you can help me and other people who dont know how to implement exactly such a thing.

Have a great day.

Regards, Axel

morningtime’s picture

Attached is my location_views_handler_filter_proximity.inc

- eliminates the use of zipcodes.xx.sql files
- by asking Google Maps API instead (you need GMap + Location)
- and saving the result in the database
- eliminating future Google hits for the same request

I advise to clear the zipcodes tables before using this. As said, I found many mistakes in the zipcode.xx.sql files, like mixed up lon/lat! http://drupal.org/node/661338

eddowding’s picture

@Morningtime -- that has worked a treat! Brilliant! Thank you!!

snufkin’s picture

Status:Needs review» Needs work

It doesn't seem to work when i select form mode: post code (assume default country), but it works great with the post code + country form.

SocialNicheGuru’s picture

@mornigtime, is there anyway to have the zipcode table as a backup incase I am not connected to the internet at the time of entering location based information?

Feonyx’s picture

Thanks morningtime worked like a treat!

tkoterwas’s picture

Thanks morningtime. This worked for me as well.

But, as mentioned above, post code (assume default country) doesn't seem to work. I think I've solved the problem or at least hacked it enough to shed light on it:

first, on line 165, you use 'site_default_country' rather than 'location_default_country'. I think we want to use the default country set in the location module admin?

second, i kept getting notices that 'country' was undefined on line 207, so i did print_r($this->value), and sure enough, it isn't there when using default country, but is there when you use postcode + country. So, i hacked it by simply copying the force default for country logic from lines 163-5 to just after the if statement on line 202, and now it seems to work.

I haven't dug around enough to figure out why forcing the default country on line 165 doesn't 'stick' - but it is probably an order of execution thing? ie query() is called before calculate_coords().

my hack is fine for me at the moment as I am on a deadline, but would be nice to know if there is a more elegant fix.

edit

--line 165:          $this->value['country'] = variable_get('site_default_country', 'us');
++line 165:          $this->value['country'] = variable_get('location_default_country', 'us');

copy lines 163-165
      // Force default for country.
      if ($this->options['type'] == 'postal_default') {
        $this->value['country'] = variable_get('location_default_country', 'us');
      }

to just after line 202:  if (!empty($this->value['postal_code'])) {

tkoterwas’s picture

also, roderik's logic makes sense to me. Has anyone else tried his/er patch? I stuck with morningtimes because there are several comments saying it works, and i needed something that at least has some level of verification.

roderik’s picture

Thank you for that acknowledgment, at least. For me it works; I'm using the patch in #4 on a site that is about to go live, and I'm willing to spend extra effort to get this thing committed in the official source tree. (I just need pointers. Or pointers to people to talk to.)

Because I was making my patch to be a 'stayer', not a 'quick fix'.

And I don't think Bdragon or another committer who cares about the long term health of the code, is likely to accept / be happy with patches that take country-specific functionality out of location.CC.inc.
(Or is that just me thinking that way?)

I know Bdragon is like really really busy and this project is in need of maintainers... but I figured, in over two months, at least one person stopping by one of the issues leading here, will comment on the approach.
Alas, no such luck, until you came by.

tkoterwas’s picture

Hey Roderik

The number of patches for this module is bewildering, with at least three different threads on this issue, and it is unclear what has been rolled into the dev version and what hasn't (yes, if you know how to look, you can find out). And thank you so much for doing it right and not starting yet another thread

I think it really comes down to salesmanship. People come to this thread because they need to do a postcode search and it isn't working. Usually we're on deadline or super busy and want the shortest, clearest path to a solution. Our first criteria is probably "does it work", and the second is "how much messing around with patches, etc does it take", and probably only then "is it the best way to do it."

So, I would humbly suggest making it as easy as possible for people to try out your solution by posting the following:
1) prerequisites - what version of Location are you using, along with any other patches you've already applied
2) instructions - do these things in this order
3) the patch AND a zip of the modified files - not everyone is comfortable applying patches - just make it clear that they do the same thing

If you make it crystal clear what needs to be done, I bet people will flock to your solution, because you made a compelling case that it is a better way from a code design perspective. You might have also sabotaged yourself, so to speak, with your laudible humility at the end of your comment, because you made it sound like you are not totally sure of your solution, and that we should wait for verification from the powers that be (the maintainers). Just my opinion, though

roderik’s picture

StatusFileSize
new27.51 KB
new9.56 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch cache-normalized-zipcodes-100123.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Thanks a lot for your comments. I guess I need some 'encouragement' to know I can hijack someone else's issue. So that's how we all work together to improve the code :-)

And you're right. It comes down to salesmanship.
So here's the short version, (Long story in #3 above.) I'll try to keep this updated against -dev versions.

The patch still applies to the 6.x-3.x-dev version from 2010-Jan-23. I only rerolled it to get rid of some 'offset' messages.

For people who don't know how to use 'patch':
- download the 6.x-3.x-dev version from 2010-Jan-23, from the project page
- unzip the attached zipfile, while inside the 'location' directory.

That's all. It works. No strings attached.

roderik’s picture

Status:Needs work» Needs review

Ah, heck. I'll just hijack the status too. (Sorry morningtime. It's time for this.)

Setting this to 'needs review'. I know the code isn't perfectly polished and commented, but it does need review from someone who 'owns the API' before I polish and comment.

tkoterwas’s picture

I've just tried roderik's patch on a fresh install of the current dev version of location, and it also works for me. nicely done.

tkoterwas’s picture

just one thing, though. I was initially happy to discover that I could get a result by entering a city in the proximity postcode search. I want to use the filter as "enter post code or city", so great! not a bug but a feature. Then I realized that these cities are being stored in the zipcodes table as zips. Not a huge deal for me, but I can see how it might be a problem for someone in the future. It would be best to create an option for "postal code or city" that first tried to validate as a postal code and if failed, geocode as a city - the result would then be cleaner as well - in this case ['postal_code'] should be empty and ['city'] should have the city name.

I'm not sure how to go about reliably validating the postcode field so that cities wouldn't validate. !is_numeric should work for us zipcodes. uk postcodes however might be a bit trickier. cant think of a uk city with a digit in it, and i think all uk postcodes have at least one (?), so that might be a way forward.

sethhavens’s picture

thank you, thank you, thank you! works a treat :-)

(also tried with the 3.1-rc1 release of Location, but didn't work)

roderik’s picture

@ tkoterwas: morningtime's patch contains code that uniformly formats a UK postcode. I assume that the same code can be used to validate postcodes and return an error if it's invalid.
I incorporated the code, but didn't return an error, since
- I don't really know UK postcodes
- I wanted to --at least initially-- create a replacement with morningtime's patch, which also does not give an error.

If you'd like to test this on my patch*, then please edit the file supported/location.uk.inc. The last line (in function location_standardize_postalcode_uk() ) says 'return TRUE;' and should be changed into 'return FALSE';
(Just above it, I made some comments that reflect your observation. :) )

* ( I don't know if it can be done with morningtime's patch)

But you're right; this means that city searches will fail. Which may not be desirable for your case - though I think that's the way it should be.

It's a good point about a 'city' field to search on. That hasn't been implemented. But I think that's a separate issue. (And: I believe Google will geocode a lot of things, not only city names. You could probably end up with a lot of cruft in the 'city' field in your database.)

tkoterwas’s picture

Hey Roderik

I've been working from your patch. The code from morningtime doesn't validate postcodes. Validation is quite a bit more complicated than that. I've worked it out from a uk gov standards website and a couple of other sources. I've also implemented city proximity searches and 'postcode or city' proximity searches which do not add cities to the db as zips (and in fact do add city and state (province) for postcodes). I've also implemented an argument proximity/distance handler that builds on your code and code from another thread. It works for postcode, postcode or city, city, and latlon as arguments. I will post code and patch when I've tested enough to be sure of it. In the meantime, here's the UK postcode validation:

<?php
function location_standardize_postalcode_uk(&$postalcode) {
  if (!
is_string($postalcode)) {
    return
FALSE;
  }
 
//capitalize it
 
$postalcode = strtoupper($postalcode);
 
// return true if it is a full valid postcode
 
$pattern = '/(^gir\s0aa$)|(^[a-pr-uwyz]((\d{1,2})|([a-hk-y]\d{1,2})|(\d[a-hjks-uw])|([a-hk-y]\d[abehmnprv-y]))\s\d[abd-hjlnp-uw-z]{2}$)/i';
  if (
preg_match($pattern, $postalcode)) {
   
// first change it so that only the outward (first) part and the first digit of the inward (second)
    // part are used (that's all google uses for licensing reasons - Royal Mail prohibits them from
    // providing full postcode geocoding data to third parties) - this will keep our db accurate
   
$postalcode = substr($postalcode, 0, strpos($postalcode, ' ')+2);
    return
TRUE;
  }
 
// return true if only the outward was entered and it is a valid outward
 
$pattern = '/(^gir\s0aa$)|(^[a-pr-uwyz]((\d{1,2})|([a-hk-y]\d{1,2})|(\d[a-hjks-uw])|([a-hk-y]\d[abehmnprv-y])))/i';
  if (
preg_match($pattern, $postalcode)) {
    return
TRUE;
  }
  return
FALSE;
}
?>
jrchew’s picture

Works like a charm, great work roderik!

roderik’s picture

Awesomeness! Thanks. Looking forward to that code :)
(Will reroll patch afterwards.)

If we're working on this together, I think we'll be more likely to be able to tug someone's sleeve and get a response about incorporating this into a -dev version.

tkoterwas’s picture

StatusFileSize
new27.61 KB
new3.3 KB
new27.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch location_tk_20100315.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

OK, so I'm attaching a patch and a zip of the files

What This Does: applies roderik's patch and adds some new features:

1) distance/proximity filter by city or by postcode_or_city
for postcode_or_city: if it cant validate a postcode it will try the field value as a city

2) distance/proximity argument
builds on code from http://drupal.org/node/357295 and http://drupal.org/node/606342#comment-2160156
but incorporates some of roderik and my changes

Details:

applied to location 6.x-3.x-dev from Jan 23, 2010

requires adding a new file to handlers (attached):
handlers/location_handler_argument_location_distance.inc

files touched:

handlers/location_views_handler_filter_proximity.inc
added the ability to filter by city, city_default, postcode_or_city, postcode_city_default

handlers/location_handler_field_location_distance.inc
added support for the argument handler

location.inc
modified location_get_postcode_data()
also gets city and province from the geocoder and adds them to the zipcodes table with the zip, lat and lon
added function location_get_city_data()
gets latlon from city (does not store resultsin zipcodes table to avoid cruft and confusion)
added function location_standardize_city()
to be honest, this function doesn't really do anything except maintain the standard set in the code. standardizing/validating a city is very hard. this simply trims the value and checks for any country specific implementations of the function. I have written a separate module that validates a city by checking the geocoding result against lat/lon boundaries - Google doesn't restrict your geocoding result to your country or map bounds, but simply uses that info to bias the results. you can set your country to UK and still get a geocoding result from Google for city = Beijing. We could implement strict boundary checking in the supported country includes, but that seems a bit over the top. I already have the bounds for uk and could write that function into supported/location.uk.inc if others think this is worthwhile.

geocoding/google.inc
returns city and province (LocalityName and AdministrativeAreaName) and postal code in addition to lat, lon

supported/location.uk.inc
validates the postcode using a regex from uk gov

location.views.inc
adds the proximity/distance argument handler

Instructions:

either
download handlers.zip and copy handlers/location_handler_argument_location_distance.inc into location/handlers on your server and then apply the patch location_tk_201000315.patch from the root of the location directory on your server
or
download location_tk_20100315.zip and replace the appropriate files in location on your server

then, please let me know if it works for you

Caveat: I have tested this only for UK locations, and not exhaustively, but I haven't had any problems so far, and there is nothing that should make it UK specific (except for if your county.inc file doesn't validate postcodes)

DanielJohnston’s picture

Unzipping location_tk_20100315.zip in #25 puts files in some pretty strange directories:

creating: location_tk_20100315/
creating: location_tk_20100315/geocoding/
inflating: location_tk_20100315/geocoding/google.inc
creating: location_tk_20100315/handlers/
inflating: location_tk_20100315/handlers/location_handler_argument_location_distance.inc
creating: __MACOSX/
creating: __MACOSX/location_tk_20100315/
creating: __MACOSX/location_tk_20100315/handlers/
inflating: __MACOSX/location_tk_20100315/handlers/._location_handler_argument_location_distance.inc
inflating: location_tk_20100315/handlers/location_handler_field_location_distance.inc
inflating: __MACOSX/location_tk_20100315/handlers/._location_handler_field_location_distance.inc
inflating: location_tk_20100315/handlers/location_views_handler_filter_proximity.inc
inflating: __MACOSX/location_tk_20100315/handlers/._location_views_handler_filter_proximity.inc
inflating: location_tk_20100315/location.inc
inflating: __MACOSX/location_tk_20100315/._location.inc
inflating: location_tk_20100315/location.views.inc
inflating: __MACOSX/location_tk_20100315/._location.views.inc
creating: location_tk_20100315/supported/
inflating: location_tk_20100315/supported/location.uk.inc
creating: __MACOSX/location_tk_20100315/supported/
inflating: __MACOSX/location_tk_20100315/supported/._location.uk.inc

I'm guessing that the way forward is to move the top two files over what they're meant to replace, and ignore the files in _MACOSX.

tkoterwas’s picture

yes. sorry about that. please do exactly what you said. the files should replace their original counterparts in the location directory. i've edited the instructions above to reflect this. will make proper zips when i have the chance

tkoterwas’s picture

StatusFileSize
new2.57 KB
new27.6 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch location_tk_20100315_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new37.02 KB

These should unzip properly (everything is the same as in #25 but they unzip into the appropriate places)

Instructions:

either
unzip handlers.zip in the root of your location directory and then apply the patch location_tk_201000315.patch from the root of the location directory
or
unzip location_tk_s0100315.zip in the in the root of your location directory

DanielJohnston’s picture

@tkoterwas - Once in the right places, the files in #25 worked just fine for me. Rock and roll! Now if only I could get the whole thing working with Feeds instead of Node Import...

tribe_of_dan’s picture

Perhaps someone can give me guidance here.

I have been trying to get a proximity filter view working by postcode (for Australia only at this point).

I am using Location 6.x-3.x-dev and have followed the instructions exactly from http://drupal.org/node/359463.

It returned no results. Therefore I started looking for answers and found this thread. I installed the zip and patched it from #28. (I also found the correct Australian zipcodes database as the one released with this version was apparently wrong.)

My view is still returning no results. Is there something else I should be doing? Can someone point me in the right direction?

tribe_of_dan’s picture

Ok I got it working!

It seems the problem was I was searching too large a radius (10000 kms). I'm not sure why it won't work at that distance but when I used 200 kms, it worked!

scalp’s picture

tkoterwas,
I've got the filter working perfectly. Thank you for putting this together! I'm having trouble finding the argument for proximity though. I've only go the city, country and province arguments available to me. I've checked and can see that the location_handler_argument_location_distance.inc file is in my handlers folder. Any ideas why this might not be working?

pero’s picture

A big "Thank you" @morningstar and @roderik. This worked great for me.

YesCT’s picture

putting this on my radar.

I see a lot of "code works for me". :)
What information do you think the maintainer needs before committing this?

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?

YesCT’s picture

YesCT’s picture

Priority:Normal» Critical
EvanDonovan’s picture

Thanks, YesCT for tagging this. I will try to test this soon, also.

YesCT’s picture

Status:Needs review» Needs work

Does this patch change it so it uses web-services to geocode a *zipcode* in an exposed filter? I think this has more chance of being committed if it does not break what is already there (for now)... so it should provide a setting to pick geocoding of the exposed filter.

Also, long term, the solution should be more generic (i.e., it should be configurable in a way where any geocode-able combination of location fields (not just zip code) can be used in the exposed filter for proximity filtering).

For now, can someone add the setting to choose an option of geocoding the exposed filter (and just for now, the it would only work for zip?) If there is no geocoding, then what: maybe what happens now... or #321114: Fixing exposed filters in Views for UK and US postal code proximity search (not cck location)?

What do people think?

YesCT’s picture

Issue tags:+location geo-coding

tagging

marcushenningsen’s picture

I tried out the solution in #28 with the latest dev release (4 April 2010), and basically it works. However, I've discovered one important bug so far:

When doing a proximity search by postal code and entering some obscure postal code in Denmark, even though I know it exists and even though entering the same postal code in Google Maps returns the right result, the search here is way off and the database gets filled with some Belgium postal code. It seems to me that the location_get_postalcode_data misses a check for country.

Also, it would be great to have some sort of validation of postal code, whether or not the postal code actually exists in a given country, but that might be hard to do this way.

For now, I'll just import a dump of Danish postal codes into the table manually.

Thanks for a great addition to the module.

Marcus

tkoterwas’s picture

sorry for my recent absence - I've been full bore on something else.

Thanks for tagging this, YesCT, I will work through your suggestions soon.

scalp @32: huh. are you still having this problem? it should show up in the available arguments as Location: Distance / Proximity. Just to be sure, you unzipped handlers.zip and also applied the patch? (or unzipped the whole thing: 'location_tk_s0100315.zip')? I assume you did, but only ask because it sounds like you might be missing the changes made to location.views.inc. - which registers the argument handler. (just unzipping handlers.zip wont work).

Marcus, The issue you are experiencing stems from the fact that Google does not actually restrict geocoding to the country you specify (or geographic bounds). Google merely biases the search, so that it returns results from the country if available but will also return results from elsewhere if not found. location_get_postalcode_data does indeed send the country to Google. Postcodes are validated in the country-specific inc file (mine is location.uk.inc - they are in the 'supported' directory). But the validation function for Denmark might just be a stub that returns true for everything. So, the way I've worked around this for my project is to implement the validation function in location.uk.inc with a regex i got from a uk gov standards website, and I've written a custom module to only return results if google sends back lat/lon within a lat lon rect (ie. a box around the UK). We could do this in the Location module itself - do a boundary check in the location.country.inc file, but i felt it was a bit beyond the scope. perhaps not? Having said that, it is indeed strange that you are enterring a valid Denmark postcode and not getting a Denmark result. Is it possible that the postcode is getting alterred somehow in the country include file? can you post the failing postcode here?

marcushenningsen’s picture

The failing postcode is 6940, where I grew up in Western Denmark! There seems to be no validation function in the location.dk.inc. It is strange that the function doesn't return the Danish postal code, because of you do a search in Google for "6940 Denmark", the right result turns up.

As I said, the problem is minor, since I got around by supplying the module with a list of Danish postal codes (zipcodes.dk.mysql in the 'database' directory). (If someone is interested in this file, it can be found here: #245641)

If you need more information, let me know. Thanks for taking the time to answer.

Marcus

YesCT’s picture

here is the issue Marcus referred to as a link (using the [#nnnnnn] notation to make it link automatically which is pretty cool for anyone new to the issue queue stuff)

#245641: Zip codes for Denmark

dpatte’s picture

subscribe

zen_lunatic3’s picture

StatusFileSize
new83.13 KB
new156.52 KB

Hello All,

I am running in circles on this. When I get it to work all I see is the form.

I have used the patch from comment #28 with the latest dev version from drupal.org:

http://drupal.org/node/662892#comment-2734502

My URL is this:
http://localhost/demos/locator_drupal/locator?distance[postal_code]=9740...

I am using GMap, Location and Views. I have been following the tutorials, painstakingly step by step.

Are there any gotchas that are common knowledge that I may have missed?

Thanks for you attention to this,
Kyle (Zen Lunatic)

kmadel’s picture

Subscribing

zen_lunatic3’s picture

Hello again,

I have started a fresh build of Drupal with only Gmap, Location and Views.

I am using this build of Location:

location-6.x-3.x-dev.tar.gz
Last updated: April 20, 2010 - 05:10

gmap-6.x-1.x-dev.tar.gz
Last updated: April 8, 2010 - 17:06

and the most recent release candidate of Views downloaded using drush.

I am using the patch from comment #28, #comment-2734502, from this thread.

I am attempting to build a store locator like this page discusses:

http://svendecabooter.be/blog/implementing-location-proximity-search-for...

When I use the Location: distance/proximity filter on my View, I get only the form. If I delete that form then I only get the map with my nodes on it.

I am using location_cck as opposed to using nodes.

I have noticed this in the preview query at the bottom of the Views UI:

'Unknown' AS location_distance,

My URL passes these values: distance[postal_code]=97401&distance[country]=&distance[search_distance]=100&distance[search_units]=mile

Can someone point me in the right direction?

I have reviewed all my permissions, I have read so many threads about this, I feel cross eyed.

Thanks for your time and attention,

Kyle

PS As for the patch mentioned in #28, it does not work for the functionality I am working on.

zen_lunatic3’s picture

NOTE: I changed the actual values in the longitude and latitude fields to some_float_value.

The query underneath the preview in the Views UI is this:

SELECT node.nid AS nid,
   'Unknown' AS location_distance,
   location.latitude AS location_latitude,
   location.longitude AS location_longitude,
   node.title AS node_title
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
WHERE (node.status <> 0) AND (node.type in ('shop')) AND (1=0)

When I run it, as is, against my database,

mysql> SELECT node.nid AS nid, 'Unknown'  AS location_distance, location.latitude AS location_latitude, location.longitude AS location_longitude, node.title AS node_title 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  WHERE (node.status <> 0) AND (node.type in ('shop')) AND (1=0);

I get this output:

Empty set (0.00 sec)

I thought the issue was with the 'Unknown' part of the query. Then I looked closer and saw the last AND. "AND (1=0);"

I have never known 1=0, mysql and I both agreed.

So I removed and ran a query against the database without it:

mysql> SELECT node.nid AS nid, 'Unknown' AS location_distance, location.latitude AS location_latitude, location.longitude AS location_longitude, node.title AS node_title 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  WHERE (node.status <> 0) AND (node.type in ('shop'));
+-----+-------------------+-------------------+--------------------+-----------------------------+
| nid | location_distance | location_latitude | location_longitude | node_title                  |
+-----+-------------------+-------------------+--------------------+-----------------------------+
|   4 | Unknown           |   some_float_value |        some_float_value | Shop1 |
|   6 | Unknown           |   some_float_value|       some_float_value | Shop2               |
|   5 | Unknown           |     some_float_value|        some_float_value | Shop3              |
+-----+-------------------+-------------------+--------------------+-----------------------------+
3 rows in set (0.01 sec)

Then I ran this query, replacing 'Unknown' with 50 and got this:

mysql> SELECT node.nid AS nid, 50 AS location_distance, location.latitude AS location_latitude, location.longitude AS location_longitude, node.title AS node_title 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  WHERE (node.status <> 0) AND (node.type in ('shop'));
+-----+-------------------+-------------------+--------------------+-----------------------------+
| nid | location_distance | location_latitude | location_longitude | node_title                  |
+-----+-------------------+-------------------+--------------------+-----------------------------+
|   4 |                50 |         some_float_value |       some_float_value | Shop1        |
|   6 |                50 |         some_float_value |        some_float_value | Shop2              |
|   5 |                50 |         some_float_value |        some_float_value | Shop3             |
+-----+-------------------+-------------------+--------------------+-----------------------------+
3 rows in set (0.00 sec)

Where does the "AND (1=0);" get added to the end of the query?

Where does the 'Unknown' value get set?

Thanks again for your attention to this,

Kyle

zen_lunatic3’s picture

Well I still don't know how 1=0. Though I realized that I had not imported my zipcodes database. Now that I have imported the zipcodes, this patch works as advertised.

so +1 for this patch works.

Thanks,

Kyle

NigelC’s picture

zen_lunatic3: I thought the puspose of this patch is to not require zipcodes database. Maybe the table didn't exist until you imported?

NigelC’s picture

Anyone know if this will make it into the release. I hate having to merge every time I get a new update.

NigelC’s picture

The 1=0 occurs in the latest release if coordinates cannot be calculated. code from handlers/location_views_handler_filter_proximity.inc

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'], "1=0");
}
}

Your lack of zipcodes would therefore be the problem.

YesCT’s picture

Will this get into the next release? I dont know, but I think not... BUT check out #664472: [master] Release of Location 6.x-3.1?, it says we will likely get a new release when #606342: Views Argument Handler for Proximity gets a fix. After that release gets out... anything could happen! I think now is the time. Things are really moving. Odds will improve for getting this in, by keeping the code here up-to-date with a patch. See http://drupal.org/patch/create. I can help anyone learn how to make a patch, and so can others. Pop into irc and say: "I want to help a module and make a patch. It will be my first one. How do I do this?" And people will be happy to help! http://drupal.org/irc

The best thing for this issue will be to get a patch here that is tested by someone else, "reviewed" by someone else and when it looks like it works, mark it RTBC, Reviewed and Tested by the Community. http://drupal.org/patch/review

Some people feel like they cant make patches or cant review patches... because they are not experienced enough. There is always a first time. There was a first time for me! I'll help anyone interested.

g4b0’s picture

Patch #28 works perfectly on location-6.x-3.x-dev 30/04/2010!! Thanks to everybody!!

Hint: if you would like to have both a map and a list of place display two views into the same node, using views_embed_view into the header of the first view, like the example showed here: http://drupalcontrib.org/api/function/views_embed_view/6

I really hope that this functionality will be included into the next release...

EvanDonovan’s picture

@g4b0: Or you can just attach the one view to the other view (using the "Attachment" display style).

g4b0’s picture

@EvanDonovan: in the view page? Where is it? (Views 6.x-2.10)

EvanDonovan’s picture

You would create a new display of the "Attachment" type. You can select that from the dropdown on the far left.

YesCT’s picture

I think we need a new summary of the status here, with details about what changes are being made by the patch and how it effects things. Also, we need a patch re-rolled with the recent suggestions. Then we need a review.

With some focus, I think this issue could get committed. But it needs to be done in a way that it wont alter the way sites are already working (the settings and defaults have to be handled carefully).

ahimsauzi’s picture

subscribing

roderik’s picture

Assigned:Unassigned» roderik

@YesCT: Totally.

I think it's up to me to answer some questions starting your #34 (and a reply from me has been long overdue).
Unfortunately my life isn't as dedicated to Drupal as I'd like it to be ;) It can take at least 2 weeks... but they'll be answered.

idmacdonald’s picture

The patches in #28 have worked for me, using the latest 6.x-3.x-dev version of the location module. Many thanks to tkoterwas and roderik! Hopefully we can get this committed to an upcoming version of the module.

-Ian

Summit’s picture

EDIT: I fixed my own issue, it was a error out of scope, so deleting it here, greetings, Martijn

DanielJohnston’s picture

Patching against latest dev (same as location-6.x-3.1) failed miserably:

/sites/all/modules/location$ patch -p0 < location_tk_20100315_0.patch
patching file location.inc
Hunk #4 succeeded at 662 (offset 34 lines).
patching file location.views.inc
Hunk #1 succeeded at 54 with fuzz 1 (offset 3 lines).
Hunk #2 succeeded at 318 (offset 6 lines).
patching file geocoding/google.inc
patching file handlers/location_handler_field_location_distance.inc
Hunk #1 FAILED at 40.
Hunk #2 FAILED at 105.
2 out of 2 hunks FAILED -- saving rejects to file handlers/location_handler_field_location_distance.inc.rej
patching file handlers/location_views_handler_filter_proximity.inc
Hunk #1 FAILED at 22.
Hunk #2 FAILED at 57.
Hunk #3 FAILED at 131.
Hunk #4 FAILED at 185.
Hunk #5 FAILED at 208.
Hunk #6 FAILED at 272.
6 out of 6 hunks FAILED -- saving rejects to file handlers/location_views_handler_filter_proximity.inc.rej
patching file supported/location.ca.inc
patching file supported/location.de.inc
patching file supported/location.nl.inc
patching file supported/location.uk.inc
patching file supported/location.us.inc

I'm just reinstalling with 3.1 now to make sure it fails on that as well, then I'll edit it in manually. I may even try to reroll it myself, which will be something of a first! Should I roll against 3.1 or dev though?

DanielJohnston’s picture

Can't figure out where the code should be going in the failed patches. Anyone else want to try for a reroll?

YesCT’s picture

patch against dev.
I'm not sure about the difficulty in finding where to put the code. Are you trying to use the patch from #28??

DanielJohnston’s picture

I've gone back to my old patched dev as I need to get the site live but will come back to this later. I didn't get further than handlers/location_handler_field_location_distance.inc - The .rej file was almost unrecognisable compared to the current dev. Suspect I'd do better comparing the new dev against the old patched dev to find the right places to put the code in.

YesCT’s picture

Thanks for the update. :)

didymo’s picture

I hope this is appropriate here:

The modules tested:
Location 6.x-3.x-dev (2010-Jul-11)
Location 6.x-3.1 (2010-Jul-07)
Views 6.x-2.11
GMap Module 6.x-1.1

I have an exposed post code filter. It is marked as "optional".

When a Post Code is entered into the search box then the search returns the map correctly.

If the Post Code exposed filter (which is optional) is blank then the AND (1=0) results in no results.

Thanks to #52 I found in the code where this is called.

However how do I allow this to return a result when the filter is optional and no value is put into the search? Am I missing something? Is it a bug? I am trying to trace back through the code and keep getting more than a little lost.

Any help appreciated.

Regards,

Ashley

YesCT’s picture

Title:Reworking of proximity filter handler to automatically geocode zipcodes» (1=0) in query and Reworking of proximity filter handler to automatically geocode zipcodes
didymo’s picture

StatusFileSize
new0 bytes
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es).
[ View ]

This is an ugly hack however gets me over the problem, in #68.

Anybody know where to find how to get the "option" switch in views to be respected by location?

Regards,

didymo

YesCT’s picture

attached patch is empty. :) Please try attaching it again.

Powered by Dreditor.

kyle-drupal-org’s picture

Has anyone got a newer patch? I'm trying to take the patch in [#comment-2734502] and apply it to the latest (July) full release without any success. There were a lot of code changes and the patch definitely does not apply. I thought I got it close, but I still get something but "WHERE 1=0" no matter what I choose.

I have applied the patch chunks manually as best I can, but functions have changed and the code moved around a lot. I'm very new to PHP and Drupal, so I have no idea what I'm doing.

kyle-drupal-org’s picture

StatusFileSize
new27.88 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch location-krh.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

For what it is worth, here's the patch I've come up with. It is a patch against location 3.1 (not dev!). I took the patch in #28 and updated it for the way that the code is written now. This has not been tested much at all. I only use the 'Postal Code and City'option. Note that it will take any address that the geocoding service recognizes, not just a city and state/province. That was what we needed anyway. YMMV.

Hopefully this is useful for someone who understands PHP and Drupal better than I do.

Edit: This is not completely functional. I am using this with Views 2.11 and GMap 1.1. I get results back, but the distance from the entered city and state is always blank. I have no idea what I'm doing so I'm going to stop and roll back to the patches in #28. The search part does seem to work.

jerry’s picture

subscribing

roderik’s picture

@ #72:

http://drupal.org/files/issues/321114-662892-intermediate.patch

That's a patch I pulled from my own repository - it's a diff from the current 3.1 to #16 above, not to #28.

I should still be going through all issues > #16, look at & incorporate all changes, and give a proper summary addressing a.o. YesCT's comments. Unless someone else beats me to it.
I'm sorry for not pushing this through - I'm really swamped with paid projects (and resulting patches to other contrib modules ;) ) at the moment.

crystaldawn’s picture

subscribe

crystaldawn’s picture

Ok, so the patch from #25/28 isnt perfect. It's "Suppose" to return a geocoded zipcode and save it if it's not found in the database. However, it does NOT do this and here is why. I've also included a tiny fix for this, do with it what you will but it should be fixed.

Line 117 in location.inc states the following:

<?php
if (function_exists($country_specific_function)) {
    return
$country_specific_function($location);
  }
  else {
   
   
// Check whether postalcode data is present in zipcode table
    //. . . continues on to create the db new geocoded entry I guess.
}
?>

This code STOPS it from doing any geocoding at all if the zipcode doesnt exist in the database!!!!!!

It SHOULD do the following instead:

<?php
 
if (function_exists($country_specific_function))
  {
   
$return_data = $country_specific_function($location);
  }
 
  if (
$return_data)
  {
   return
$return_data;
  }
  else
  {
      
// Check whether postalcode data is present in zipcode table
      //. . . continues on to create the db new geocoded entry I guess.
 
}
?>

This is just 1 bug I've found in this patch. I PURPOSELY started with an EMPTY zipcode database. Just to see if it would actually populate it, which it did NOT do. This patch still needs work. I'm sure I'll run into more bugs as I attempt to get this thing working and I'll post them here as I go along.

EDIT: Well thats it. There is only this 1 bug that I've found with this patch. Get that one fixed and it should be good enough to roll into a DEV release.

YesCT’s picture

crystaldawn, can you re-roll the patch with your fix? Then someone can review it, and then we can mark it RTBC. :)

vosechu’s picture

Shouldn't this be two issues? The 1=0 thing seems pretty clear:
distance is specified but not coordinates because:
coordinates just aren't there (they didn't enter a zip, their user doesn't have coordinates, etc)
coordinates can't be looked up because the zipcode database is empty

I think this should be fixed but it should be in a different issue and it's confusing people who are looking for the 1=0 thing.

buzzman’s picture

hi,
i urgently need to fix proximity etc bugs mentioned & resolved here. does anyone have the location -dev version from either of these dates plz:

location-6.x-3.x-dev 30/04/2010
location-6.x-3.x-dev 04/04/2010
location-6.x-3.x-dev 23/01/2010

i want to apply the patch from #28 but it's noted to only work on the above date's -dev version releases as I gather from reading the entire thread. the latest -dev release therefore is no good until these patches apply to it. so sumone plz attach the zip.

thnx a gazillion :-)

roderik’s picture

StatusFileSize
new9.54 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 662892-based-on-16.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Synced my own repository with location -dev, and extracted the differences.

The below patch against the latest -dev is based on #16, not on #28. I didn't think, I didn't test.

Please tell me if there are things in #28 which are not in #16, which you need.

EvanDonovan’s picture

Status:Needs work» Needs review

Thanks, roderik. Code seems sane from a quick review, though I had to apply the patch manually (possibly because it was made from the Drupal DocumentRoot, and I was in the sites/all/modules/location directory). It applied to the latest 6.x-1.x-dev with just some fuzz though.

I think the reasoning from #16 makes a great deal of sense, although I'm not entirely sure how they related to the (1=0) in the query bug that is also mentioned in here. Is that also resolved by the patch? (I am wondering also, as with #79, whether this should be split into two issues.) Also, are the other issues mentioned in #16 rolled in as part of the fixes in this patch?

I can't tell what #25/#28 adds that wasn't in the patch from #16 and the re-roll in #81 - if someone could clarify that would be great.

I've bumped this up to "needs review" since it seems to work for me in the US and the UK, although it wasn't working for me on a Toronto postal code: M4B 1B3.

I think what we need to do to get this committed is to create a site with a bunch of Location data around the world (imported from feeds, or something), apply this patch, and then test it systematically to see what works.

phunster’s picture

Finally got it working, so happy I found this thread and read it through.

So here are the details: location 6.x-3.x-dev 2011-Feb-25
gmap 6.x-1.x-dev

Applied the patch in #28 by tkoterwas, changed the proximity filter to city or postal code assume default country, saved the view and proximity search worked.

Kudos to tkoterwas!!! Great Job!!!

aniebel’s picture

Many thanks for everyone's hard work on this. I think I might have missed something so please explain. With this patch/thread is there or is there not a need for the zipcode dbs? It seems like what's being proposed is to use gmap instead of the db to retrieve that information. Sorry for my ignorance.

I can say that I have tested this patch in #81 and have found a few things to note. Whether they pertain to this thread or not, I do not know.

1. Canadian postal codes only validate with a space between the first 3 and last three characters. If no space, it returns nothing.
2. While, a Canadian postal code returns the closest US results, it does not return anything from Canada.

Location 6.x-3.x-dev (2011-Feb-25)
Gmap Location 6.x-1.x-dev (2011-Mar-10)
Views 6.x-2.12

EvanDonovan’s picture

@aniebel: The patch uses the Google geocoding API instead of a zipcode DB, if I am not mistaken.

aniebel’s picture

StatusFileSize
new1.84 KB

THanks, EvanDonovan. I emptied my zipcode db and now I get no results whatsoever. Is there any chance that somebody can explain exactly how this works? I'd be happy to supply an export of my current View for reference.

Also, I'm unclear where $geocode_in_db is being called from.

aniebel’s picture

I'd like to know if I'm asking this in the wrong place? I am up against a deadline and need to get this working so any help at all would be greatly appreciated. If I'm in the wrong area of the site to ask, please advise.

Many thanks!

peggysmouse’s picture

watching. +1 for not needing a canadian postal code database table.

tkoterwas’s picture

StatusFileSize
new1.81 MB

I received a private message requesting that I upload my full working version of the location module so that someone else might run with it. This is the full module patched with 25/28 above. It works well in my particular case and others seem to have it working as well.

A few things to note:

#77 above. I took a closer look, and the reason it was working fine for me was that there is no country-specific hook in the UK include file, but there is one for the US and for Canada (which explains the recent Canada-specific issues). These do a bit of country-specific input normalisation and query the db. So, the logic is indeed incorrect and should be something like the following which groups together the country specific db query and the generic one and returns the result from either if there is one. If not, it proceeds with the geocoding:

<?php
 
if (function_exists($country_specific_function)) {
   
// get the postalcode data from the country_specific_function, which returns null if no data found
   
if ($postal_code_data = $country_specific_function($location)) {
      return
$postal_code_data;
    }  
  }
  else {  
   
// Check whether postalcode data is present in zipcode table
   
$result = db_query("SELECT * FROM {zipcodes} WHERE country = '%s' AND zip = '%s'", $location['country'], $location['postal_code']);
    if (
$row = db_fetch_object($result)) {
     
// We can't be absolutely sure that city/province are filled in the database, but some callers use it
      // TK edit: also return the 'postal_code' for completeness sake and to make sure the return array is uniform
     
return  array('lat' => $row->latitude, 'lon' => $row->longitude, 'city' => $row->city, 'postal_code' => $row->zip, 'province' => $row->state, 'country' => $row->country);
    }
  }

  if (
$geocode_in_db) {
?>

The above is NOT in the attached zip file and has not been tested. It would need to replace lines 117-129 in location.inc (minus the php tags).

#82 EvanDonovan: My work built upon Roderik's who deserves the lion's share of the credit for getting things working. I described what I added/changed in #25 above, the most significant being the views argument handler, but also some UK-specific postcode handling, an option to handle "postcode or city" as a views argument, and some tidying-up/standardisation of the data array you get back from geo-coding.

Sorry for my absence on this thread. I've been terribly busy and unable to add anything meaningful to what I originally posted. I anticipate that the person who contacted me will have some updates in the near future as he seems very keen to get a new patch committed.

Cheers,

Ted

ankur’s picture

Status:Needs review» Closed (fixed)

I think there have been commits recently that make the module fallback on geocoding when there isn't any data in the zipcodes table. The results of the geocoding get stored as well.

cosmos11’s picture

Thanks for the great patch! It has been working for me for over a year.

But I am having problem once I upgraded GMap module to 6.x-2.x last week. Does the patch work with the latest Gmap module with Google Maps API v3? Thanks!

cosmos11’s picture

Status:Closed (fixed)» Needs review

I have been using the patch from tkoterwas (#28); it has been working fine until I upgraded to the latest GMap module because Google V2 API will stop to work on May 19, 2013.

Anybody having issues after upgrading Gmap? Thanks!

Status:Needs review» Needs work

The last submitted patch, 662892-based-on-16.patch, failed testing.

podarok’s picture

Version:6.x-3.x-dev» 7.x-3.x-dev
Assigned:roderik» Unassigned
Priority:Critical» Normal

All feature requests should be rolled against latest 7.x-3.x-dev and after pushing em to repo - backported to 6.x
Thanks!

marcushenningsen’s picture

I'm experiencing the exact same problem. Did you find a solution?

DamienMcKenna’s picture

Reading through the codebase, I think there's a bigger issue.

When a postal code lookup is being performed it should IMHO perform the following tasks:

  1. Obtain the country code.
  2. Obtain the postal code.
    • If necessary, use a per-country function to tailor the postal code to the official format for that country.
  3. Check against the known {zipcodes} table.
    1. If found, return the results.
    2. If not found, do a geocode lookup to obtain the details from any API that is supported.
      • If any data is found, update the database and return the results.

The problem is that the tweaking / massaging of the postal code is being lumped into a per-country lookup function, so the entire geocode lookup is being ignored just because a country might have its zipcode in a different format.

The quick solution will be to change all of the per-country location_latlon_rough_* functions to just customize the postal code value as necessary and then defer to location_latlon_rough_default() for the actual query. The best solution, though, would be to change the API itself to get rid of the per-country location_latlon_rough_* functions,
move the location_latlon_rough_default() logic into location_latlon_rough() itself, then add per-country location_latlon_rough_postal_code_* functions as necessary to only adjust the postal code and not touch anything else.

Patch forthcoming.

DamienMcKenna’s picture

Oh, I guess I should have finished reading the entire discussion before posting. I'm glad I came to the same conclusion as everyone else ;-)

DamienMcKenna’s picture

Issue summary:View changes
Status:Needs work» Needs review
StatusFileSize
new5.28 KB
PASSED: [[SimpleTest]]: [MySQL] 425 pass(es).
[ View ]

None of the last patches would apply, so..

This provides a MUCH simpler approach to the problem than the previous patches. As I suggested earlier, I've just made some changes to the per-country location_latlon_rough_CC() function so that they rely upon location_latlon_rough_default() for the actual query. Also, it removes location_latlon_rough_ca as it didn't serve any purpose any more - the postal_code value wasn't modified, rendering the function useless.

DamienMcKenna’s picture

Version:7.x-3.x-dev» 6.x-3.x-dev
Component:Location_views» Code
StatusFileSize
new5.64 KB
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es).
[ View ]

A D6 version of the patch.