Building the ultimate street address management system and geocoding module for Drupal 7

Adam S's picture

There are several modules in Drupal 6 that manage addresses, geocoding and geospatial points. I would like to see a discussion about them and their better parts to base the construction of an address management system in Drupal 7. I am pulling comments I made in the Address Field module for Drupal 7 module issue queue as I originally wanted to express the ideas here in the the Geolocation Group to make them available to a wider audience. The original thread is at

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 (and a Drupal 6 sandbox of OpenLayers Geocoder) 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 ( and the Drupal 7 Geolocation Field (

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 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 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.

I don't think that is very similar to 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 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.

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.


Three brief comments...

alarcombe's picture

a) Decouple the geocoding service from the module - make it pluggable. Google won't be the right choice every time for geocoding.

b) Conceptually, decouple the front-end from 'address'. Let someone type in some 'thing' which has a related geographic 'value' (polygon, point whatever) which populates some geo field via a lookup to a service (hell, even something in Views 3). I might want to type in 'Route 66' and store a multi-polyline.

c) "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"
In that case you may be correct, but to build a general purpose solution you do need to do some form of geographic operation on a point and polygon. An address is just one way of describing a location and are volatile. My current location is in two counties depending on who I'm talking to - 'Middlesex' if you want to mail me something, 'Surrey' for tax/local services. The two are non-coincident (ie some people in Middlesex are not in Surrey and vice versa). The only way around this is to take my lat-long and compare it to whatever county (described as a polygon) I'm interested in.



I'm pretty specific about a

Adam S's picture

I'm pretty specific about a module that just focuses on addresses which means lines (many points on a map when connected make a route or railroad track) and polygons are out of scope. I'm defining an address as on these two webpages, and Managing "a mark with a destination" would be a good phrase to describe the scope of an Address Field module.

If you put into Google Maps (or Yahoo, Bing or Geonames) a single country, city or street you only get one single point returned. There is a reason why these massive location servers only deal with single points that way and I want a field in Drupal that manages them well.

Marine job board with Drupal 7 at

A different idea

phayes's picture

bdragon and I thought a lot about this during drupalcon and this is the idea that we came up with.

Separate out the following functionality:
- Address storage. Store in either Address Field ( or a textfield
- Geo Storage. Likely using geofield as it is a little more powerful than geolocation. I'd like to talk to the geolocation folks and see how these two projects can better co-ordinate and co-operate together.
- Geocoding. There is a start of a D7 port of the geocode module here: . It needs some love, but the basic architecture is good. It has pluggable source and destination compatibility. Right now it can geocode from a textfield or a filefield (gpx, EXIF image data etc) and store it in a geofield. We would just need to write additional plugins so that it can talk to address-field and geolocation
- Display. OpenLayers and GMap.

Since we are keeping all of these separate maintainability and depth should be good. It also provides a lot of flexibility to site administrators. However, this has one huge drawback: It's not a simple turnkey address / lat-lon solution.

bdragon and I thought we could re-engineer Location module to be a "turn-key" solution that pulls all these component pieces together. In this module Location becomes a new entity type that by default contains an address-field (or address textfield), a geofield, and the geocoding middlewhere that pulls it together. Location would be dependent on the above modules so we retain all the goodness of having a flexible system.

What do you think?

I'm thinking ..... add two

Adam S's picture

I'm thinking ..... add two columns to the Address Field database schema for latitude and longitude. Alter the 150 lines of JavaScript for the geocode widget in the Geolocation Field module for the client side geocoder. Use the data returned in JSON from Google to populate the empty fields in the Address Field (county, state/province, zip, county, lat, lon, ect.). Since this data is very similar to the Location module data, port the Location module Views support without the zipcode filters because that seems messy. Add a widget that geocodes a location string in a Views exposed proximity filter like in the Openlayers Geocoder and be done with it.

All the code is there in all these several modules. I just need to put it together.

Marine job board with Drupal 7 at

Not a sustainable approach

zzolo's picture

@phayes and @bdragon's ideas are good in my opinion. Tacking on a lat/lon onto the Address Field would be a very negative approach in my opinion:

1) Address is a different set of data than a geospatial feature (though closely related).
2) Lat/Lon is very limited and is not the only way to describe an address
3) Geocoding can happen many ways, and that should be a pluggable architecture.
4) Creating many different storage mechanisms for geospatial data makes it very hard for mapping solutions to support all of them.

Yes, most people want to just install one module, but installing a few modules is not that big a deal if documentation is adequate, or if there are solutions like what is described for the future of Location (possibly).

The approach you describe @AdamS is very much against how Drupal core and most of the successful Drupal modules go about architecting solutions. The kind of approach you describe leads to the module soup problem where no one knows what is the best way to do things and what things work together. It's much more sustainable and extendable if different modules focuses on certain tasks well, and then there are distributions, documentation, features, etc that allow people to connect them together easily. This is the approach in many software projects.

Also, if you suggested this to the maintainers of the Address Field, my assumption is that they would say the same thing. And looking back at the original post, this is what he was in support of in the first comment of the post.


The wider issue is many

Adam S's picture

The wider issue is many Drupal module developers are working on similar and overlapping projects independently without communication with each other.

What I would like to see are the developers of GeoField, Gmap, Google Map tools, OpenLayers, Address Field, GeoLocation Field, Location, ect., ect., ect. (and the list could go on) getting together and communicating.

Marine job board with Drupal 7 at

What I would like to see are

strk's picture

What I would like to see are the developers of GeoField, Gmap, Google Map tools, OpenLayers, Address Field, GeoLocation Field, Location, ect., ect., ect. (and the list could go on) getting together and communicating.

That is the aim of the drupal-geo mailing list:

I think @phayes and @bdragon

steinmb's picture

I think @phayes and @bdragon are on the right track BUT I'm behind @zzolo on not including lat/long in Address field. Keep it nice and clean, people are able to install multiple modules, just look on soup. Good documentation, features support perhaps?, so a turnkey ready solution could be to install a feature and your done but still got the flexibility if you want to change stuff.

Stein Magne

A core API needed?

drew reece's picture

Is it time some kind of mapping API got into core? Or had some overseers co-ordinating the user interface & data management and presentation? It all needs tying in correclty to rdfa & I suspect that is where most site admins will fall down.

It may not need to get into core, e.g. look at the like the new D7 media module that has unified file management, major improvements via the UX team's research.

Maybe this needs an 'initiative owner' (see Dries 2011 keynote) to coordinate generating something for Drupal 8?

ps @emilcohen, if you have a job request try creating a job at[]=303 otherwise no one will see it when you cross post in unrelated threads.

Not so sure about that

heivoll's picture

To be honest, I think there's more than enough in core already. I disagree that geolocation and mapping is something that is absolutely necessary for a CMS to contain.

edit: Maybe I misunderstood how much functionality you actually meant should be put in core. Never mind this post ;)

happening slowly

zzolo's picture

I have been trying for some time to get people to work together in some fashion to make things a lot more interoperable. I think I need to pivot and try a different approach to this as it is not happening all that quickly, but still is happening.

As far as getting stuff into core, I proposed this GSOC 2011 idea:


Discussions are being had - let's just keep it up

phayes's picture

I think there is a lot of willingness on the parts of module maintainers to talk, and the response to this thread is indicative of that. There was also some good discussions and code-sprints at drupalcon. The main problem is that geospatial stuff is hard and complex - there are lots of moving parts and considerations. We seem to be heading the right direction for Drupal 7 - there are less module and more lots of discussions happening now. We just need to keep it up.

As for drupal-core support. Here is the relevant issue:

I've got a half-working patch submitted there, but it could use some love.

Lots of great work

zzolo's picture

@phayes, definitely. The work you and @bdragon have done is great. I want to write it up into a wiki page soon to provide a geospatial community-direction doc. My comment was more about how personally my efforts have not seen great results, and it is probably a fault of how I have been trying or not trying to do things.

Drupal 7 does offer a good opportunity to rethink things a bit.

This is a bit off topic, but concerning geospatial data types in core, should we think about a contrib module that provides a patch for core since it won't happen in D7 and could be years before D8 comes out? It's quite a shame that with all those database improvements in D7, extending the data types was not put in there. :(


Good idea zzolo

phayes's picture

@zzolo. Yes, I think that might be a good idea. It sucks to have to patch core, but working with native geometry columns is going to be hugely beneficial.

I would start by getting a patch committed to D8. Once that is in, then we can back-port it to D7 and go from there. If we do it this way, we know we aren't colouring outside the lines too much since it would be a back-port that we know will remain the same once D8 comes around. It also means that the patch has been vetted by the drupal-core team.

Since we started discussing

steinmb's picture

Since we started discussing D8 and native db geospatial support might regarding the Geo project, from #14 and down is the interesting read.

Stein Magne

There are some huge

Adam S's picture

There are some huge initiatives in Drupal right now such as the Media module and the Commerce module both taking advantage of the Drupal 7 framework by retooling and consolidating the better parts of each that preceded them in D5 and D6.

Perhaps what we need is a formal initiative like Dries discusses in the podcast.

Does anybody have a list of geolocation use cases already implemented in Drupal. How do people already try to use Drupal to map something? It would be worth while to start here because with such a list any idea somebody comes up with will have to satisfy each use case in some manor even if it's obtuse.

Marine job board with Drupal 7 at

Geo use cases

zzolo's picture

Hey @AdamS. There is this wiki page for Geo use cases:

More like this (with good formatting) would be awesome.


wiki page

zzolo's picture

Please note that I have page a Drupal Geo Stack wiki page to re-organize and re-collect some of the Geo CMS thoughts. It is very incomplete, so feel free to add to it.


Your link does not seem to

SkyWombat's picture

Your link does not seem to work.

"Page not found"

Corrected link

zzolo's picture

Somehow, an extra 0 got put on there. Here is the correct on: Drupal Geo Stack wiki page.


Address Field should be a component.

lloydpearsoniv's picture

I am somewhat forced to use the addressfield module since drupal commerce depends on it so I am completly behind the idea of Geofield & geolocation projects integrating with to avoid repetition. It allows for a more integrated experience of site owners & endusers.

As far as turnkey solutions, thats what the features module & installation profiles are for. Modules should be atomic. This is what makes drupal better fitted for more customized solutions then cms systems like joomla & wordpress which are not modular. I like having control & the ability to customize my site to my liking & I strongly dislike modules that want to make all of the decisions for you.

address entity - relationship model

ccardea's picture

I'm just scratching the surface of this but I thought I'd put my two cents out there anyway. I've been thinking about the entity relationship model between address and other geo information (lat/lon). If your main concern is the address, then the address is the entity and the lat/lon pair is an attribute of that address. An address will always have a lat/lon pair associated with it, but the lat/lon pair conceivably could have more than one address associated with it. It takes every field of the address to form a unique key. Depending on your application, the lat/lon field need not have a value.

On the other hand, if you are describing geographic locations in general, the lat/lon pair is unique and may or may not have an address associated with it. It seems to me that it does make sense to have a lat/lon field as part of an address system, but as more of a foreign key and not the primary storage mechanism for the geography information.

Taking it a step further, the lat/lon pair can have other types of information associated with it, and each type of information is probably also an entity with a lat/lon attribute. The result of that line of thinking is that in a normalized relational database, the lat/lon field would be the primary key in a table, possibly with no other attributes, and every other entity with a lat/lon attribute would have lat/lon as a foreign key.

In a system that is only concerned with addresses and not other types of geography, there's no need to have a separate table for the lat/lon pair. it should be possible to create a storage mechanism that is tailored to that system. The geocoder then is a method of data gathering, a widget. The address system does not need to be tied to any particular geocoder, and the geocoder does not need to be tied to a particular storage mechanism. Am I right about that?

As I said I'm just scratching the surface and I don't know how these types of things have been implemented in other systems. Can anyone shed some light?

I know - I think too much

ccardea's picture

The question then becomes how do these two systems work together. This is what I think. The geocoder modules need to provide a widget and possibly an interface that sort of says: here's what I provide. The address system might need to provide a spec or its own interface that says: here's what I need. Maybe there has to be a connector that can translate between the two. What do you guys think?


phayes's picture

@ccardea . I think you are on the right track. Geographic and address data need to be treated as separate but related. The same could be said of, for example, a KML file. The KML file contains a-lot more than just geographic information, it also contains feature-data, styling-data, etc. We would want to keep this KML file seperate from the geofield - we would want to keep the KML in a filefield. However, we would also want to preserve a relationship between the KML file and a geofield that describes it's geographic data. This is analogous the relationship between addressfield and geofield (the only real difference is that a KML file specifies it's location unambiguously).

I personally believe that the location module should be the one to preserve this relationship. As stated above, perhaps location should be it's own entity that "ties" together a bunch of different (but related) geographic data (addressfield, geofield, phone numbers, fax numbers etc. etc.) into a nice package that can be easily deployed and attached to other content.

Of a different note, I've spent all of yesterday making a major update to my D7 port of geocode.

It should now work with addressfield. It requires the latest version of the geoPHP library (

There is still work to be done in terms of finishing off the transition to ctools and polishing off some of the interfaces. It think the basics of the architecture are now in place. Comments and criticisms appreciated.

Location should be its own entity

ccardea's picture

I agree. Location is a higher level of abstraction and an address is a particular type of location.


lloydpearsoniv's picture

phayes, excellent work.

Still thinking

ccardea's picture

phayes, I haven't looked at your module yet, still thinking conceptually and I have to correct myself, because an address could also be described by the boundaries of the property, which would be a collection of points and not a single point representing roughly the center.

Looking at the definition linked to earlier:
1. A description of the location of a person or organization, as written or printed on mail as directions for delivery: wrote down the address on the envelope.
2. The location at which a particular organization or person may be found or reached: went to her address but no one was home.

So on second thought, the concept of an address is tied to directions for where someone or something can be found, and correct me if I'm wrong, but always associated with a street or some kind of thorofare. So really a single point is what we are after. The boundaries of the property would be an attribute of the address.

@phayes just looking at your project page it looks like a lot of nice work, but I really need to take a closer look at Geofield and the other modules being discussed here.

The boundaries of the

lloydpearsoniv's picture

the concept of an address is tied to directions for where someone or something can be found, and correct me if I'm wrong, but always associated with a street or some kind of thorofare. So really a single point is what we are after. The boundaries of the property would be an attribute of the address.

I would have to disagree with you here for numerous reasons.
An address is a specific point. This can be illustrated if you look at the maps of some of the bigger cities. A great example is Chicago which has a very organized grid system. If a building takes up an area where you are able to fit 2 or more houses, then the address reflects the change on the next builing or house that follows. So if the addresses run like 202, 204, 206 & 208. If building A's address is 202 Some Street, and it takes up 2 houses worth of area, the next address would be 206 instead of 204.

Think of Google maps. When you enter an address, it locates the address & gives you directions based on your start point. The actual directions would be the route to get to the address, not the address itself.

Directions are calculated based upon the start & endpoints(which could be addresses) but direction are not the start and end points themselves.

Maybe I wasn't clear

ccardea's picture

I don't disagree with anything that you said. I'm not sure what the point about Chicago is. They apparently mapped out lots and blocks before structures were built and assigned numbers to the lots. In their system they assign a single address to a single structure. It's also possible to have multiple structures assigned to the same address, or multiple addresses assigned to the same structure. The point is that, for an address system, you need a single point to be assigned to the address, which can then be used to locate someone or something.

Point or Polygon?

phayes's picture

Just to throw a little more confusion into the mix: What about the following addresses:

"RR4, Old Remo Road, Terrace, BC, Canada" (This used to be my postal address.)

"General Delivery, Quadra Island, BC"

Are these points or are these polygons?

What about the (non-deliverable) address: "Chicago IL"

I think the correct answer is we let the site-builder decide whether to geocode an address as a point or a polygon depending on their needs. As module builders we should build in capability for both and let site admins go from there.

Rather than waiting to share

Adam S's picture

Rather than waiting to share what I've been working on in a week or two when I'm done, here is my synthesis of the Geolocation field and Addressfield modules.

I have not added the formatters from the Geolocation module yet because I don't feel that is necessary to the discussion and concept right now. It would take me about an hour to do.

What is important is a Geocoding widget has extended the Addressfield almost entirely on client side.

Things that I would like the widget to do.

  1. Rather than have a button that needs to be pressed, add an event handler for keypress to trigger the JSON call to Google so it geocodes on the fly.

  2. Add to the client side geocode script a check box for reverse geocoding. The default will be off which allows people to geocode the address while typing and then move the marker on the map if they don't agree with the geocoded lat/lng results. However, moving the marker does not update the address fields. When the checkbox is marked, typing in the address fields will not make a JSON call which will update the marker and when moving the marker the lat/lng will be reverse geocoded to update all the address fields.

  3. Graceful degredation. If a person doesn't have javascript running the address fields should be sent to the Google geocoder by the server. It also might be worth while to force Country, City and State and using hook_field_presave_field() intercept the $form_state values, send them to be geocoded for the sole purpose of getting sanitized results to store in the database. If a person submits New Dork, it will then be saved in the database as New York. It would be great to have some form of validation or sanitation.

  4. Use all the good Views integration from location to add Views integration here. There is no reason there shouldn't be an almost straight port.

  5. Refactor the code that enables the Geocoder widget into a separate module. This module will have dependencies on Addressfield and Geofield so the Address information will be stored in the addressfield database table and the geographic information will be stored in the Geofield module. This will allow the Geofield module to act on the information in the several ways that it does natively.

Marine job board with Drupal 7 at

I fixed the bug with the

Adam S's picture

I fixed the bug with the geocoder not working and added two more formatters which show a map and address with map. I still need to make it work when the country form state changes and add a checkbox to toogle the reverse geocoder.

Marine job board with Drupal 7 at

The Addressfield module would

Adam S's picture

The Addressfield module would change the form based on country to conform to the formatting and naming of addresses in different countries. This would be great to use because the geocoder can map the appropriate address fields. (see However, my Javascript skills can't solve the bug of changing the countries dynamically and not breaking the geocoding widget. So I just removed all that fun stuff and made a plain version of module. It's on Github at

Please, try it out and tell if there are any noticeable bugs and other things it needs. I'm going to start researching how to implement Views integration.

Marine job board with Drupal 7 at

Well, I went ahead and

Adam S's picture

Well, I went ahead and created some Views integration borrowing from the location module. Of course, if you use this you have to name your field 'address' or none of it will work. I don't really have any JS or PHP skills so I'm just mucking around. However, I think that module is cleanly solving a particular niche in Drupal 7.

My next task is to learn javascript so I can create dynamic ajax rendered maps. Wish me luck :)

Marine job board with Drupal 7 at

You guys are awesome.

lloydpearsoniv's picture

seems quite interesting. I guess I will try it out once I am able to get the addressfield & geocode that phayes is developing working on my system. Then i can do a comparison and see which approach seems to be best.

A place for both

phayes's picture

I think there might a place for both of Adam S's and my solution to the geocoding issue.

We are differing in approaches and I think they might both have their place.

In Adam's solution, everything is done on the client side, so this allows for some interesting user interactions where the user can dynamically interact with the geocoding. This seems a little less extensible and brittle (most things client-side are), but allows for some cool UI.

My approach is entirely server-side. This is more extensible and robust and has a pluggable architecture so other module developers can add aditional geocoder handlers (bing for example), but provides exactly zero user interactions.

What might be interesting is if Adam's client-side solution can make use of my server-side architecture as a service to allow for more than just google based handlers.

Why can't the widget query

Adam S's picture

Why can't the widget query the Geocode module instead of Google? Then on submit the Geocode module goes about it's business just the same because it's secure.

Marine job board with Drupal 7 at

Indeed, that would be cleaner

phayes's picture

Indeed, that would be cleaner from an architectural perspective. However, there is the disadvantage that you hit google 10,000 geocodes a day when you force it to go through the server. You don't hit this limit when you do it all client-side.

Having said that, anybody who is building a website with more than 10,000 geocodes a day can likely afford to build their own solution!

For my case, all geocode

Adam S's picture

For my case, all geocode services do a poor job of my area of concern. Fifty percent of the time they will return the correct coordinates for the address, but there also needs the ability to -- after the address is typed in -- move the marker on the map to the correct spot. Most people will know the bay, inlet, hill, road, or land mark they are geocoding so they can move the marker on top of it on the map but they won't know in radians their lat and lng.

The best I can do is a client side geocoder that allows the user to move the marker to set the lat and lng fields.

Marine job board with Drupal 7 at

D7 Geocode module just had a big update

phayes's picture

Okay - another big update to the D7 geocode module:

All the architectural changes are basically done. The only thing left to do is fix up some of the geocode handlers. See:


rickmanelius's picture

This seems like a very important conversation. Did it die out or move to another location? Is there a clear path forward yet or does there still need to be a lot of discussion?

I'm still trying to wrap my brain around how I want to do locations/addresses in Drupal 7. I'm presently using the address field by itself, but would love if location could wrap around and/or related to it with some longitude/latitude goodness as well!

Freeze or proceed?

rickmanelius's picture

In addition to my previous comment, I guess a more important question is whether or not it makes sense for all these geolocation modules to keep developing while this is figured out, or would it make sense to just fire up an email-sprint like discussion and hash this out, making a clear path forward...

It's clearly not an easy problem, but there are definitely some good ideas in this thread. It's just a matter of trying to figure out which approach will give us the best long term solution while not requiring ridiculous configurations on the part of the users...

Just died, at least from what

steinmb's picture

Just died, at least from what I know. A few of us tried to sum things up in on this wiki page, Thanx for kicking the tread again.

Stein Magne

That's a shame.

rickmanelius's picture

It seems an issue like this needs a significant amount of momentum, focus, and coordination simply to get through the planning stage. But once that is done, it could be a boon for everyone.

My only fear of not getting this done right is all the coding time that might get wasted this year if it all has to get chucked for an API solution that everyone can plug into. When will be the next chance for a push? Drupal 8?

For now, I know I have a solution that can work for myself personally. But with more microdata formats now charging out (, this seems to be all the more important.

In reviewing the summary thread you linked, there appear to be a lot of questions. If we were to say, discuss and decided upon one at a time, would that be enough to have a plan once the hard choices have been made?

I honestly, am a newb when it comes to location handling, so I would not be of benefit short of helping organize and/or provide feedback. But still, this would be cool.

I'll be at drupalcamp denver if anyone wants to meet up and chat. Thanks

Subs. Interested in the

Alan D.'s picture

Subs. Interested in the direction, particularly if address module maintainers do not try to include every possible feature and end up with big bloated modules!

I needed an address field for a D7 project that I was working on, and I actually wrote one from scratch. I then integrated it into hCard formats by creating a new formatter for name & text fields that represented either the org / n attributes. The formatter mapped the other hCard properties to other fields on the instance and pulled these in. So I mapped two address hCard properties within the name field to the existing work and postal address fields on the instance.

Some images may help with this explanation:

I'm not releasing these into the already crowded mix of modules, but the concept for connecting bridges between individual components is the way to go. All instance / formatter settings have access to the entity and it is trivial to pull out this data. The issue is how to map and format the next step with one easy to use UI. Maybe we should be looking at modules like, microdata, ...

Glad to see people are still

Adam S's picture

Glad to see people are still discussing this. It looks like someone is working on the OpenLayers Proximity module Drupal 7 port. Once again I doubt that there is much communication between developers.

Marine job board with Drupal 7 at


deeve's picture

Hi Adam,
what combination of D7 modules did you use to achieve the Proximity Search you have over on (I'm assuming it's your design, as is on your signature).

I made a custom module that

Adam S's picture

I made a custom module that is based on hi-bred of Addressfield, Geofield, and Location modules. It sucks that we aren't all building stuff together.

Marine job board with Drupal 7 at

one GeoCMS to rule them all

zzolo's picture

Just to speak about the idea of working together (though I thought this was more about just trying to get a sense of what people are doing).

The conversation about how to structure Drupal and contributed modules has been going on for about 5 years now.
(and many more)

The GeoCMS is difficult because there are a lot of moving parts, and a lot of unique situations, and there are currently not too many people devoting significant amount of resources towards the problem. This is why we have the situation of lots of smaller modules filling specific use cases. This is not a bad thing at all; this is how much of Drupal contrib works. But you run into a lot of pitfalls, especially around interoperability, and then you get confused users.

I don't know how to solve this problem. I have been trying to help organize the GeoCMS and the spatial community in Drupal for some time but to not much avail. This doesn't mean it can't be done, but we have to push for different approaches than what has been tried already.

As suggested throughout the Drupal community, helping out on existing modules instead of writing new ones is a good thing. But I have been around long enough to know this is not something that can be followed perfectly.

I would highly suggest that people help to maintain the list of spatial modules in Drupal as this is the only way to start to collect data on functionality of modules and will be very helpful to end users.


good catch buddy - you deserve monster congrats!!!

unleash's picture

an adress-module is wanted and needet! Well to be frank - i cannot wait to get started with this!

Let us see where we can see first code snippets and the prelimniaries of an extensible adress-module.


Any progression on this

pinkonomy's picture

Any progress on this module?I am definitely interested in this!

Things are progressing nicely

phayes's picture

Hi @pinkonomy

There has been great progress in this realm over the last couple of months. The potent combination appears to be:

  1. Address Field -
  2. Geocoder -
  3. Geofield -
  4. OpenLayers -

I feel like with all the awesome new drupal talent helping out, geospatial in Drupal is really shaping up!

I was wondering if anyone has

gateway69's picture

I was wondering if anyone has a nice module to reverse geocode the address, city and state?

That might be a good feature

phayes's picture

That might be a good feature request to the geocoder module - to ask for reverse geocoding capabilities

Hi @phayes, you mean we

pinkonomy's picture

Hi @phayes,
you mean we should use the above list of modules,or is going to be released a new module with the combination of these?

All different modules

phayes's picture


Those are all different modules that have been built to work together nicely. But yes, they are all different. Think of them as a "family" of modules that love each other. :-)

So there will be not any

pinkonomy's picture

So there will be not any general module that combines all the above right?

Take a look for an

drew reece's picture

Take a look for an installation profile if you need to install a site with geolocation in one go.

I doubt there will be a module that combines all of these - not everyone needs all the features, and lumping them all together would make maintenance & updates slower.

Is there an installation

pinkonomy's picture

Is there an installation profile?

I don't know, the search page

drew reece's picture

I don't know, the search page is …

There may also be ones not on so try Google, or there may be features or a drush make file that contain them. Personally I think it is easier to just install the 4 modules but you haven't explained how or why they need to be self contained so it's difficult to see what your aim is.

Ok thanks ,I will try those 4

pinkonomy's picture

Ok thanks ,I will try those 4 modules

New book - Mapping with Drupal

tinem's picture

Maybe this new book can help somebody. Mapping with Drupal - Navigating Complexities to Create Beautiful and Engaging Maps I just bought my pdf-copy and hope to learn a lot.

I just got mine, too!

databoy's picture

Thanks for the pointer!

Location and Mapping

Group organizers

Group categories

Wiki type

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week