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 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.
- Large, well established user base
- Geocoding of addresses
- Location paradigm of collecting addresses is not applicable for more diverse use cases.
- Geocoding has some problems when updating addresses.
- You can't change between a fields and node based approach. Since fields is by far more flexible, and the future, there's lots of code debt to the pure nodes approach that most people don't need.
- Gmap uses the legacy v2 Google Maps API.
- Configuration and customization of the Gmaps output can be difficult.
- You're locked into using Google Maps.
From the project page,
- Well thought out architecture and API allowing for many use cases.
- Comes bundled with OpenLayers CCK, a WKT field which can store point, linestring, or polygon data in a single field. It also comes with a "map picker", allowing users to enter data via a map interface.
- Ecosystem of supporting modules such as OpenLayers Proximity, OpenLayers Geocoder, Geo Taxonomy, and MapBox.
- Provides a set of tools to mash your Drupal data with external sources, E.g., KML files.
- OpenLayers is open source, unlike the proprietary map scripting APIs from Google, Yahoo, and Bing.
- The flexibility translates to a complicated setup and configuration.
- Views integration is particularly non-intuitive, as you have to create at least 2 views. One for your data and another simply as a "vehicle" to carry your preset along.
- Still in alpha and there are some stability issues.
- The OpenLayers library slows to a crawl with more than 500 or so features on a map.
- There are potential licensing issues when using tiles from proprietary providers like Google. Basically, OpenLayers directly accesses the map tiles of a given provider without going through their APIs, and that's against Google's TOS unless one gets express permission. Not to mention Google could easily shut down access to it's tiles by OpenLayers, not that there's any indication they would do that.
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.
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.
- It has LOTS of dependencies.
- Still using the deprecated V2 of the Google API.
- The whole proprietary provider thing.
- On the plus side, it implements Google Static Maps API which, returns a single map graphic when passes a set of points and other parameters.
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.
Note that this article was originally published by Lev at http://www.levelos.com/blog/2010/08/mapping-drupal.