Geocode one computed address from multiple fields

Hi zmove,

That point off the western coast of Africa is actually the coordinates (0, 0). It may mean that no geocoding occurred at all, or it may mean that your field formatter is not displaying it properly.

To see if it's your field fomatter, go to "Administer -> Content Management -> Content Types -> [your content type] -> Display Fields" and select a formatter other than a map one. Well Known Text, for example. When you view your node, you should see something like POINT(123, 123). If you see POINT(0, 0) or nothing at all then it's on Geo/Geocode's side.

If you see something that looks more responsible then you should file an issue with whatever module is providing that mapping output.

Thanks!

Hi zmove,

You can check the multiple boxes, but this means that geocode will attempt to use these fields *sequentially*, until it gets a result, and does not combine them. You're right in thinking that a particular field type needs to accepted by the geocoder.

Please test this for me:

On line 75 of geocode.module, change this code:

    'field types' => array('postal_field', 'postal', 'text'),

To this:

    'field types' => array('postal_field', 'postal', 'text', 'compound'),

If that works for compound fields i'll make that change.

Thanks!

They have a difference if you store or not the computed field in the database?

Can you see if this works better with the latest version of Geocode? (alpha2)

@Allie They should be work with computed field module or without?

Using computed_field.module works great with geocode 6.x-1.0-alpha2 with the change in #6 (should be computed, not compound).

NOTE: You need to make sure that the Geo field is ABOVE the Computed field in the Manage fields list, or nothing gets geocoded. You'd think it was the other way around, but hey.

NOTE 2: Actually, that might not be true. It seems that the node needs to be saved twice. Once to get the computed field saved, once more to get the computed field geocoded.

I made a very rough hack of the geocode widget that adds a checkbox in the widget field settings, that allows to use the default sequential geocode behaviour. This version uses all of the values that are checked in the field settings at once as an input for the geocode function.

It should work with select lists and input fields as cck fields, but defaults to "point" for type and the handler of the last checked field.

I created a patch which changes a little bit the existing functionality and adds a new one.
It adds a new column in the Geospatial data's configuration page - Field type.
Now if we have a content type with several address fields and one "Geocoded value another field" field, in the configuration page of the "Geocoded value another field" widget we can set all these fields to be used in computing the coordinates and we can set the type of each field: generic, street, street number, zip code, city, country. That way when the user fills in for example a zip code field and a country field, he automatically gets the coordinates from these fields. If the "generic" type is used, then the user fills in the whole address in only one field and the coordinates are calculated from this field.
The patch is tested and it works fine. It is created against HEAD.
I've attached the patch and a screenshot of the settings page.

simosda's patch from #16 works great for me, thank you!

I have a lot of address data already stored in nodes; is there anyway to trigger a mass geocode of all the nodes? At the moment, the only way I can see is to save each one again manually.

I tried using Views Bulk Operations to accomplish this, but any bulk operation seems to have the reverse of the desired effect -- the geodata is completely wiped!

I like patch in #16 too

#16 can't not applied anymore on head

replacing the geocode widget module with the code from #15 worked great for me. I am using geocode 6.x.1.0-alpha2.

Thanks @archnode :)

@simosda - I'd love for geocode to be able to do what your patch does. I've tried using Addresses and Postal but both are limiting and have required extensive tweeks via custom modules to accomplish what I need. It would be a lot easier to just use CCK fields. (Based on some of the comments in Postal, it will be much more useful once fully developed, but it's just not there yet.)

I'm using 6.x-1.0-alpha2 and the patch in #16 is not working. I get a lat and lon, but they're slightly off, about a mile or less.

Does no one else have this issue? I have a Street Number, Street, City, and Zip Code field, each are text fields with the corresponding field type assigned. I tried with and without a Country field.

When I enter the same address using a Postal field with a 'Generic' field type on the same node, I get the correct lat and lon.

For anyone who wants to test their coordinates without setting up a full map, here's something that help with that: http://itouchmap.com/latlong.html

Oops. Didn't mean to change the version

Subscribing

Thanks for all your pointers in this thread. I finally got it to work. I applied the computed field patch from #6. Then I ran a bulk update on a geocoded field generated from a computed field, which in turn was generated by multiple address cck text fields. I also used the snippet here: http://drupal.org/node/905814#comment-3513678

http://drupal.org/project/addresses also work now with geocode can be an alternative...

As an aside, I gave up on this approach and ended up writing Rules Geocoder to solve this problem on our sites.