hey brandon,

another small improvement, this time for the file geocoding/google.inc - the google geocode function was missing a check to ensure that the result's country is matching the queried location's country.

Otherwise, it can happen the the geocoding for a non-existent zip in one country (like "12345, Germany") ends up to be "found" in a completely different country (like "Germany, WV 26884, USA" ... LOL, by the way ... and i also found out this way, that there do exist several "Deutschland"s in Switzerland and Austria, as well ... hehe ... <:).

The attached patch is solving this minor issue.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

Status: Needs work » Needs review

this looks like a good idea.

Can someone please review this? Then if it works for another person, we could mark it reviewed and tested by the community.

nickl’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1.11 KB

Patch did not apply and had to be re-rolled.

Tested and works very well!

rtbc

YesCT’s picture

Issue tags: +location geo-coding, +location bdragon consider commit

Oh, I could have swore, on of the many many issues I just read through was a duplicate or at least related to this. But now I cant find it.

ankur’s picture

There're a couple of issues I'd like to resolve before committing this:

(1) Country codes used by google might not match those used by location module
Google geocoding, when returning the CountryNameCode (see the patch file), uses the top-level domain for country codes. I just want to make sure the location module uses the same country codes. The country-code top-level domains use almost the same codes as defined by ISO 3166 with a couple of exceptions. I know the location module does the same (e.g., both location module and the google geocoder use 'uk' instead of ISO 3166's 'gb' for the United Kingdom).

(2) Also, I know that it's possible to call the google geocoder now with a "country bias" parameter. In other words, it's possible to make a call to the geocoding web-service and specify a parameter for the country in which the address should be geocoded (since city names and zip-codes can occur in more than one country). Finally, what if no country is stored in the location module address but the location module geocoder is configured to geocode all addresses via google? It'd be nice if we could still try to geocode the address. However, I think this patch might prevent processing of results returnedc by a call to the google web-service.

YesCT’s picture

Status: Reviewed & tested by the community » Needs work
YesCT’s picture

updating tags.

nickl’s picture

Status: Needs work » Needs review
FileSize
1.16 KB

In response to YesCT's post #343491-3: google.inc geocoding needs country-check
#584014: RTBC auto load geocode country list is definitely related to this patch but it is not a duplicate since this patch focuses on preventing results for countries not searched for, which can happen on occasion, by doing a comparison of the country code retrieved via google geocode to the country code of the address being geocoded for validity.
The aforementioned patch retrieves the available country list from google but makes no effort to ensure that the correct results are retrieved, for the country in question, when geocoding an address.

I haven't spotted any other similar issues in my travels here, but ymmv.

In response to ankur's post #343491-4: google.inc geocoding needs country-check

(1) If the country codes are retrieved from google automatically (addressed by patch from #584014: RTBC auto load geocode country list) this should not be an issue anymore because the country codes will be synced.

(2) There is no way to capture the gl parameter, as far as I know, with location module thus it will not be possible to pass the "country bias" parameter to the google geocode webservice and therefor no reason to check for it. I would like to suggest that this is outside the scope of this patch and should be addressed by a separate issue to enable this feature.

The attached patch is re-rolled against the latest DRUPAL-6--3 branch with an additional check to allow for the omission of the country code when attempting to geocode an address without a country code.

YesCT’s picture

side question... how did you link to a specific comment, but get the nice color coding and issue title? (I know [#nnnnnn] links to the issue as a whole).

nickl’s picture

Check the info under More information about formatting options.

References to project issues in the form of [#1234] (or [#1234-2] for comments) turn into links automatically, with the title of the issue appended. The status of the issue is shown on hover. If '@' is appended (e.g. [#1234@]), the user the issue is assigned to will also be printed.

YesCT’s picture

ah. sweet. thanks.

ankur’s picture

Status: Needs review » Needs work

I'd like to be able to test this. Is there a specific example for which this patch would fix the problem? In other words, does someone know of an address where geocoding returns results for the same address in a country different from the one intended?

rooby’s picture

This is probably a duplicate of the already committed #2072869: Google geocoding not always accurate for partial addresses

If someone wants to test the latest releases to see if it is fixd for them that would be helpful.

legolasbo’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)

Closing old D6 issues as D6 is end of life