Location and Geo modules in Drupal

Matt Zytaruk's picture

While working on a business directory today, I came to a stark conclusion - The state of GIS (Geographic Information Systems) in Drupal 6 is in a sorry, sorry state - despite being very important to a lot of people. I had implemented similar projects in Drupal 5 before without difficulties using the Location module, so I was expecting this to be a piece of cake. Unfortunately this was far from the case, because every GIS related module out there (as of today) is either lacking necessary (in my opinion) features, or is broken in some major way.

The Location Module

The first module I looked at was the location module, which has been around for many years. Despite the fact that I was never a fan of how it was designed and the fact that it's got some huge bloat going on, it was tried and true and had all the important features (to me anyways) that a project of this type needed. Unfortunately, the upgrade to Drupal 6 was not a pretty one and it looks like the maintainer has pretty much abandoned working on it. The last release was 3.1 RC1 which was released in March of 2009 and the last dev release (the last time anything was committed to the project) was July 31st. Despite this lack of activity on the code front, the issue queue is quite active (and gigantic). There are some extremely broken features in there, and many of them have patches available on the issue queue, but nothing is being committed. The main issues for me were the fact that proximity searching (a must in my view) was broken, and several things to do with using Location CCK also were broken. Also, the way location does proximity searches (doing trigonometry in the select query) performs badly and won't scale to too many nodes, and proximity searches are limited to only searching by postal code which also needs to have huge postal code database and only comes with US codes, meaning proximity searches will only work on US locations.

The Google Maps Tools (gmaps) Module

This was a module I'd never used before but it looked pretty nice from the description, and held some good promise. Unfortunately they don't have any stable releases, and I couldn't get proximity searching using the views filter to work at all. The one thing I really liked about the project is the cck widget for adding locations. It has a autocomplete field which links up to google, so you just start typing in your address and then select it when it pops up, and the widget automatically fills in all the fields. Very nice! The downside of the widget though is the labels of the fields. Hardly anyone is going to know what to put in for things like 'locality' or 'administration area'.

The Geo and Geocode Modules

These modules were meant to be a replacement for the location module, fixing the things that were bad in the design of it:

  1. using mysql and postgresql's built in geo extensions rather than trigonometry in the query, for better performance
  2. separating the modules to allow swapping of some of the components
  3. using cck for everything
  4. allowing more GIS related features like storing paths and shapes rather than just points.

It also has some nice features like geocoding your search query so you don't need to have the longitude's and latitudes of everything you are searching for - so you can search for any address and get the distance each of the results are from that address (though of course this part doesn't seem to work yet as the proximity searching seems to be broken). It also integrates with Openlayers (http://drupal.org/project/openlayers) which seems pretty neat. This seems to have a lot of promise and I like how it's designed, but unfortunately it looks like the projects were sort of left for dead for many months, only finally just recently getting some updates again and having some of it's features fixed. There are still some big bugs in there, such as views filters that don't work at all when using the geocode widget. Also, I wanted to be able to search by city or state that is already added in the database, so I tried using the postal module (which is integrated with the geocode module) but half of the stuff doesn't seem to work, or is very unfriendly for users.

The Verdict

Well, this is a tough one. I really like how Geo is being designed and the features it should have...but it's in a barely usable state at this point. I'd like to use it as a starting point for my business directory, and add features as they get fixed, but even a basic starting point doesn't seem workable at this point (at the very least users should be able to pick a state/province from a list, and autocomplete on the city field, so that you don't get a million variations on the same entry). At least with the Location module, I can add a bunch of patches in the issue queue and have the basics work (even if I'm not a fan of how it works).

Well, all the modules use

Matt Zytaruk's picture

Well, all the modules use Google's geocoding API... but only for some things. The Geocode module (for use with the Geo module) uses it for everything, but of course a bunch of it doesn't work. The location module uses it when saving location enabled nodes, but doesn't use it for geocoding search requests (for proximity searches), which it reallllly should do. Postal code only searches is pretty lame, and so is having to hold a big giant postal code database in your site.

With regard to the spatial extensions, the ease of implementation isnt the issue, it's just a matter of database performance.

I agree though, the user interfaces for all these modules need a heckofa lot of work, for user facing sites.

Spatial Extensions

Dan's picture

The only problem I have with the spatial extensions isn't performance it's that the OpenGIS implementation (at least AFAIK) is incomplete. For example, the last time I checked there were no functions for determining distance or proximity. However, it would be worth implementing to at least standardize the storage formats and there are a few useful functions. However, I haven't looked at them for a long time, so there might be a full implementation in mysql now, I'm not sure. Part of the usefulness I could see in full OpenGIS implementation is being able to use GML and document transformers to transcode location data into GPX files or xmlrpc responses. It would be nice to have all of the location methods abstracted in a service (although if they were well standardized in a module it would be trivial to extent them in a service).

I'm also really frustrated with these modules

Dan's picture

First of all how does a person even decide what modules to help with? Any one of them could be left for dead or abandoned.

Personally, I don't think these modules should try and reinvent the wheel. Google's geocoding API is pretty rich and can do relatively accurate lat/lon estimates from anything from basic city information to zip codes to street data. I use it all the time in Flex when I need mapping or geocoding in a RIA app. Any module that implements geocoding should just use either google or yahoo's geocoding API. Ideally a flex widget or ajax widget would allow a person to type in the relevant data and attempt to geocode it into lat/lon and failing that could manually choose their location on the map (which would populate the required form variables with the lat/lon data).

I think using the spatial extensions in mysql could be interesting, but the trig to do the lat/lon distance is pretty basic and well standardized (haversine formula) so it should be trivial to implement in any module as long as the standard was followed.

One of the biggest problems I find with most of these modules is in the user interface portion, they're so damn confusing for the average user they need to be a cyborg to enter in a simple address. The developer side is equally frustrating. Too much is being re-invented or attempted in archaic methods when there are highly advanced rich technologies that could easily be mashed into a solid geo module.

If we had unlimited time, I'd just love to roll our own since we could easily achieve 99% of what we needed with a Flex/ GMAPs enabled widget and some AMF back end service calls.

Anyway, nice blog, thanks for the info!

Post new comment

  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options