08.05.2010 Technology and Innovation

Mapping with Drupal

compass I've recently become more involved with map scripting in my work on LCREP, Save Our Gulf, Geomeridian, and a few others in the works. One commonality amongst all the projects was the need to display geocoded data on a map, a problem solved many times over. When I began work on the first of these projects this past spring, the state of mapping in Drupal boiled down to these tools.

Mapedelic

Mapedelic is the name given to the powerful and well established duo of Location and Gmap. The former stores address and coordinates as either CCK fields or in its own schema and can geocode addresses when called upon. The latter then renders those locations on a Google map. Gmap also plays well with Views. Both these modules have large install bases and have been in use for some time.

Pros

Cons

OpenLayers

From the project page,

The OpenLayers Module and its submodules bring the OpenLayers JS library into Drupal. They enable users to combine maps from different map providers with data from Views and CCK input. The OpenLayers JavaScript library is open source, making it flexible and capable across standards as well as proprietary APIs.

Pros

Cons

Geo

I really want to love this module, as it stores geo data natively in a spatially enabled databases, PostGIS and MySql Spatial specifically. This allows for powerful and efficient spatial queries, such as, do these set of points fall in this polygon, or do these two linestrings intersect and, if so, where? It also provides support for proximity filters within Views. Unfortunately, though, I've found that it's just not ready for production, is very unstable, and difficult to work with. It has also been stuck in alpha for nearly a year, with no new releases since April. One of the challenges that Geo, or any module wanting to implement native spatial data storage, is that the Drupal schema API doesn't support a spatial datatype, although there are some work arounds.

GMAPS

This project integrates the Google Maps API and Google Static Maps API. It makes possible to add addresses and/or coordinates (points) to nodes through CCK fields, display these geographical informations on node pages as text or interactive map or static map and use them on GeoRSS feeds. The project provides style plugins and row style plugins for views to build both interactive and static maps. This project is an independent competitor for the Location and GMap pair (also known as Mapadelic), and this is the successor of the Google Client Geocoder project.

I have to admit that I have spent the least amount of time working with this module, but the feature set does look very promising. A couple of things that jump out.

Mapstraction

When we began working on maps.lcrep.org, I decided that using the Mapstraction library was the best option, and in the process I took over the development and maintenance of the module and released a 2.x branch, which uses the newest version of the API and adds many other improvements.

This module delivers support for the Mapstraction javascript library, which provides an abstraction layer for the various map providers including Google, Yahoo!, and MapQuest. It allows you to quickly display maps on your site from multiple providers and switch between providers without worrying about differences in their APIs. The module provides a Views style plugin and an API for developers to use maps elsewhere. When the Views style is used, it will display nodes as points on a map. The latitude/longitude points, info balloon contents, map icon, and one or more attributes can be provided by any view fields, including those from CCK. Other settings can be seen on the attached screen shot.

The architecture of the module is very simple. Aside from a set of core API calls developers can use in their code to render maps, it exposes a Views style plugin which has options for mapping fields to coordinates, tooltips, map icons, and attributes. The last item is a nice feature of Mapstraction. Any point on a map can have an arbitrary collection of attributes, really name/value pairs, which can then be used to filter the map with a simple Javascript call. That's how we're doing the map filtering on maps.lcrep.org. We also used an updated version of the module, with Google V3 integration, on Save Our Gulf. The module is in fairly active development, and is plotting along with the Mapstraction library. So when an official release of that will be made, I'll do the same with the module.

Conclusion

In the end, the right mapping tool of course depends on the requirements. For complex interfaces that display lots of different data, I think OpenLayers might be the way to go, at least if your rendering less than 500 points on a single map. For fairly simple requirements such as plotting points on a map, I think Mapstraction is a great fit, but, of course, I'm biased towards it. All of the tools discussed here are excellent, and, I have to stress, are evolving rapidly, so what might be unstable one day may be polished and ready for production the next. And they all point to the powerful mapping features that can be built with Drupal. I have also begun work on two additional mapping related modules. A dedicated Google Maps Javascript API taking full advantage of the V3 feature set and a fields module integrating with SimpleGeo. Early suggestions welcome!

Note that this article was originally published by Lev at http://www.levelos.com/blog/2010/08/mapping-drupal.

Get In Touch

Questions? Comments? We want to know! Drop us a line and let’s start talking.

Learn More
Get In Touch
Tags: Drupal mapping