Integration with geofield

This would be more then welcome!

The link between postal adresses and geographic coordinates is what is generally called a "geocoder". It should be fairly easy to implement that as a separate module that links the two fields together, querying external geocoding services like Google Maps.

We are having the same discussion over at the geofield module issue cue: http://drupal.org/node/1093402

To sum up: A D7 version of geocode is here: https://github.com/phayes/geocode - let's clean it up and make it work with addressfield.

Ha, we posted that response at the exact same time!

There are several projects that geocode data one way or another. It would be nice if we could list them and categorize things we like and things we don't like about them. I have a sandbox installation of Drupal 7 with about 8 different modules that geocode using several different services. The two that have the most to offer in terms of knowledge to contribute to a Drupal 7 geocoder is openlayers geocoder (http://drupal.org/project/openlayers_geocoder) and the Drupal 7 Geolocation Field (http://drupal.org/project/geolocation).

The openlayers geocoder uses the Drupal 6 autocomplete widget to query Google Maps Api server side and returns a JSON object to change the $('input').value on fields on the node form. I think it's biggest strength is Token support to rename fields. A disadvantage to doing it this way is 15,000 per day cap on geocode queries to Google Maps Api per a single server without having to pay Google $10,000 a year for the service.

I answered a forum post about filling CCK fields in Drupal 6 with information gleaned from a third party here http://drupal.org/node/1044286#comment-4062056 outlining the technique in the Openlayers Geocode module. Of course, using the Drupal 7 Ajax framework this process would be a thousand times easier.

The Geolocation Field module is looking very promising. It creates a widget that has a single field for the user to type in an address. Then the user clicks the Geocode button and the widget through a client side script queries the Google Maps Api which returns the geocoded data for that address. The address it self can have spelling mistakes and the country placed before the street or city and Google will still do a godo job returning Geocoded information. However, the module only saves the Latitude and longitude information. Also, each user or client gets 2500 queries per day per ip address which doesn't effect the other user's 2500 queries to Google Maps Api

It makes a lot of sense to have this widget a part of or at least an extension module of the Address Field module where a script is added and two fields for latitude and longitude. Rather than having a button that will geocode the address just make a query on every keystroke. Also make it so the marker is movable by click and drag just in case it's an isolated location that someone is trying to geocode. This is how the geocoder works on yelp.com for adding business listings.

I've been going over the Google Maps Api v.3 and think that it might be a very straight forward process.

Have been trying to read up on different projects and issues. Pls. correct me if I'm totally lost here.

• http://drupal.org/project/openlayers_geocoder does not seems to ever happen for D7 then it relies on openlayers_cck that is deprecated in http://drupal.org/project/openlayers 7.x branch.
• http://drupal.org/project/addressfield store addresses and does it well.
• http://drupal.org/project/openlayers performing a spring cleaning and are aiming on only doing presentation.

So on my desk I'm left with two, to me, quite similar projects http://drupal.org/project/geofield and http://drupal.org/project/geolocation that to me have quite similar goal?

Note that we are using the xAL format for address fields precisely to ease integration with geocoding and address validation services.

@steinmb

I don't think that http://drupal.org/project/geofield is very similar to http://drupal.org/project/geolocation. Geofield is just a way to input geo coordinates into Drupal independent of actual addresses as a point, line or polygon and focuses on the math to handle those. Geofield would be good if a website was keeping track of areas of deforestation or concentrations of fish populations (polygon). Geofield would also be good to track migration patters of tagged sharks or birds (lines) or to track the location of caught fish. Perhaps, if I wanted to create several points on a map of where a blue marlin was caught, I would use geofield.

Although, an address is a point, it might not be best to use Geofield to manage addresses. Currently Geolocation manages creating a point of an address very eloquently using the Google Geocoding Api and saving the coordinates. That is mostly what it does. Yet, it doesn't do two very important things: manage the address information like the Address Field module does or the math to manage the points like the Geofield module does.

I think that the two similar modules are Geolocation and this one, Address Field. I think that they are actually two of the three parts of the same address management paradigm. Address Field manages address string data and formats it for display and the Geolocation module augments address string information by adding two more fields to it, latitude and longitude. The map widgets in the Geolocation module are just secondary to the management and storage of the lat and long fields.

These two functions should be consolidated into one system even if for the sake of simplicity they are two separate modules that can integrate seamlessly.

The third function of the address management paradigm is the proximity search functionality which is the math. The Geofield module manages math and should be responsible of create sets of points that are within an arbitrary polygon, for example, or math to calculate the intersection of two lines. These types of functionality are far beyond the scope of any address management module which doesn't need anything more than the math to do proximity searches.

On second thought, the Geofield module might have application in an E-commerce website. Polygons can be created for different postal regions and a geocoded address point which falls within the bounds of a region can determine the price of shipment in real time. Nevertheless, the extent I have seen of address information on the web doesn't go much further than proximity search whether it is a real estate website that displays schools nearby based on proximity search or an airline purchasing site which shows the ticket prices of neighboring airports too.

In Drupal 7 OpenLayers and http://tilemill.com/ will manage presentation of geolocation data. Geofield will manage the storing geographic data as points, line and polygons and manage the math associated with them. And, there will be a niche for a module that manages addresses of which the lat/lng is a part that standardized address fields, geolocation lat/lng fields and methods to work on those fields. An address module should also extend itself through contrib modules to integrate with OpenLayers and Geofield.

@Adam S.
Thank you for your lengthy and extremely informative reply, I really appreciate it :)

So what about http://drupal.org/project/geotaxonomy? Projects like this might get deprecated in D7 then taxonomy terms are fieldable in D7 and all we then need is to stuck a "geo-kinda) field to get the same functionality?

The purpose of geotaxonomy terms is to define a bounding box or polygon by taxonomy term. This is great if you have three different terms such as Spain, France, and Italy. On the Spain taxonomy page all points associated with Spain can be shown as they lie within the Spain taxonomy term's bounding box. This doesn't have anything to do with addresses so it should not be in the scope of an Address Module. This is selecting points that fall within a bounding box and the math to do this is in the Geofield Module so I think it would sensible to extend that module.

Consider the Address module database table:

ID | Country Code | Provence Code | City
------------------------------------------------------
1 | United States | Florida | Palm Beach
2 | United States | Florida | Miami
3 | United States | New York | New York
4 | Canada | Nova Scotia | Halifax
5 | United States | Florida | Miami

You do not need taxonomy terms or to do math equations to show a page with all results of addresses located in the United Stated, for example. A database query that SELECTS * FROM {address} WHERE country code = United States will very eloquently return those results. Because Google Maps API returns the same spelling of geocoded results it's possible to force the returned values from the Google services query to write to the local database to insure security with granularity as far as city.

With Views integration a country code or province code can be passed to views as an argument. That is to create a page with an argument of Florida (/myPageAlias/{Florida}) and get three nodes returned in a Views page according to this example.

I have two issues with the purported scope of the Address Field module is not.

• A silly fork of an old 4.6-area US-centric location solution that tries to do to much
• A way to store and manipulate geographic coordinates or to integrate with GIS systems

Just throwing out all the years of knowledge contained within an old 4.6 module might not be such a good idea. Joel Spolsky makes a good point when he says the single biggest strategic mistake a software company can make is rewrite code from scratch. Location module has two features that the Address Field would be well served to implement, Views integration and the country codes to drive the cleaver use of the new Ajax framework in Drupal 7 which is used in the Address Field Module.

Also, because proximity search can use Google Maps API geocoding and is very strongly tied to addresses it should be within the scope of address management.

All the code and ideas expressed here and others such as Rules module integration to make nodes aware of other nodes based on proximity have been implemented sometimes well and other times not so well in several other modules in Drupal 6. I would like to see the better parts of all these modules intelligently ingrated using all the cool new API features of Drupal 7 Core.

I really wanted my thoughts to be in the Geolocation Group at GDO so I just cross posted. http://groups.drupal.org/node/137049

Let's continue this discussion over on the g.d.o

How can i add build to my drupal site placeitlocal.com, geotaxonomy like this website have ziplocal.com, what kind of Module do i need for drupal 6
Ajax framework in Drupal 6 which is used in the Address Field Module
where do i get this Module so i can download it