Google just depreciated v2 of it's geocoder, and made a new one... Blog post http://googlegeodevelopers.blogspot.com/2010/03/introducing-new-google-g... and specs now at http://code.google.com/apis/maps/documentation/geocoding/

So some changes may be in order, but I guess not urgent?

Comments

gagarine’s picture

Nice.. it's more easy to parse, They remove this "no end" array.

I think the change is really easy to do but as you say is not so urgent.

So I just want to keep an eyes on this issue :)

steinmb’s picture

+1 from me

mr.baileys’s picture

Status: Active » Needs review
StatusFileSize
new5.29 KB

Attached is a patch that replaces the now deprecated Google geocoding API v2 implementation with version 3.

Overall, this change is backwards compatible except for one issue: While ThoroughfareName in v2 contained the street + street number as one element, the new API returns these as separate elements. Since different countries use a different order for these elements ("1600 Pennsylvania Av" versus "Rue Montoyer 100", we can't just concatenate the street and number.

I've added "street_number" to the items returned by get_field_postal(), and I've added an additional property called "formatted_address" to the geocode_google class, allowing clients to request the full formatted address. This way they can request the full address without having to piece it together from the field_postal elements, and without having to worry about where to stick the street number.

gagarine’s picture

Status: Needs review » Needs work

work ok except line 104

'lng' => $result->geometry->location->lng,
need to be
'lon' => $result->geometry->location->lng,

I'm not a big fan of the 3 foreach. I will see if I can improve that.

cwithout’s picture

Applied patch in #3 with changes suggested in #4.

Seems to work well except for the 3rd foreach gives "Invalid argument supplied for foreach()" warnings.

I'm using it as an exposed filter in a view with filter function set to distance and widget set to Google API: textfield.

I'm seeing the $google_type variable set to 'political', which isn't present in your $translate_map array. You can get rid of the warning by type casting $translate_map[$google_type] to an array, but not being that familiar with the geocode module or the API, I'm not sure if political should be used for something.

Note: I applied the patch to version 6.x-1.0-alpha2, because it's more recent than the 6.x-1.x-dev version. Should this issue be set to the dev or alpha2 version?

gagarine’s picture

Version: 6.x-1.x-dev » 6.x-1.0-alpha2
Status: Needs work » Needs review
StatusFileSize
new5.2 KB

based on #3

This patch integrate what I say in #4. It's also replace the "translate_map" and foreach with a switch. A switch will be more flexible and easy to understand. As a side effect it's correct the warning bug #5.

I also move the all attributes in the main class (street_number and formatted_address).

I can see some improvement (like language) but the patch target is only to pass from the API v2 to v3.

gagarine’s picture

StatusFileSize
new5.2 KB

upload fail apparently with # in the name... so same patch

gagarine’s picture

OMG... I saw now (after my vacation) than their are a big mistake in those patch.

So I quickly fix it but I'm not sure is the right way. I can provide a patch but want to take more time to check if this is all right.

    $this->result = $result;

    // Store the formatted address if present.
    $this->formatted_address = $result->formatted_address;

    // Translate the values returned by the Google Geocoding API to values used
    // by the Geocode module.
    foreach ($result->address_components as $component) {
      switch ($component->types) {
        case in_array('postal_code',$component->types):
          $this->zip = $component->long_name;
          break;
        case in_array('country',$component->types):
          $this->country = $component->short_name;
          $this->country_name = $component->long_name;
          break;
        case in_array('administrative_area_level_1',$component->types):
          $this->state = $component->long_name;
          break;
        case in_array('locality',$component->types):
          $this->city = $component->long_name;
          break;
        case in_array('route',$component->types):
          $this->street1 = $component->long_name;
          break;
        case in_array('street_number',$component->types):
          $this->street_number = $component->long_name;
          break;
        default:
          break;
      }
    }

BenK’s picture

Subscribing... is anyone interested in a D7 version of this? I know I am! :-)

--Ben

hypertext200’s picture

sub

jerdavis’s picture

Status: Needs review » Fixed

I've made a few updates to #7 & #8 and pushed changes. Look for this in a new snapshot release shortly. Thanks all

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

steve hanson’s picture

I've started using the 6.x-1.x version of this and it seems to work fine but is causing a maddening behavior ---

My use case is to take a Postal field and use geocode to put the points from the postalf fields and shove them into geo.

The dev version seems to be doing the following --- making Geo return the proper point AND return a point in downtown Kowloon. POINT(114.177987 22.321702) --

Trying to revert back to using the release version of geocode now seems to break editing of the pages, since saves seem to be producing an error of "unable to parse wkt" -

Any suggestions here? Dev seems to work fine if you want to get only one point back and ALWAYS want to geocode - but I always get back one more point than I ask for, and it's in Kowloon --- Maybe I'm doing something stupid, but I don't see it.