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
- Large, well established user base
- Stability
- Geocoding of addresses
Cons
- 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.
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
- 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.
Cons
- 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.
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.
- 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.
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!
- Lev's blog
- Login to post comments
Great write-up
Thanks for the write-up Lev. I didn't know about half of these mapping modules and even then it's tough for some folks to figure out what each does.
To be fair
Geo is no more or less stable than other solutions available, but it is hindered by documentation, support and PR. As an API, it is dependent on willing developers to provide outputs (e.g. Openlayers) or inputs (e.g. Postal, Addresses, Text, etc. + Geocode). It's really not fair to say "geo is in alpha so it sucks", without actually attempting to understand what it does and how it relies on other solutions.
It is trivially easy to store GIS data in the database. What is a challenge is allowing users to express it in meaningful ways, and use the collaboration of multiple modules to collect, store, query and present that information. Until we have an loose coupling of coordinated modules, we'll be constantly comparing monolith modules that are doing "almost but not enough".
This is similar to the deconstructionist approaches that replaced Event and Image modules with their Date/Calendar and Filefiled/Imagefield/Imagecache. At first it felt alienating and baroque, but it's really the only way to tackle discrete aspects of the workflow without duplicating a lot of effort.
Allie (I think?) - You make
Allie (I think?) - You make some great points, and I certainly meant no disrespect and appreciate all the hard work that went into the module. I also certainly didn't mean to imply that "it sucks" as you say. I actually did spend some significant time understanding the module, and used it on Save Our Gulf, mainly because we needed proximity views to found nearby pollution reports.
That said, during the development of that project and in my research and testing, I found many critical, and, in some cases, fatal problems that I felt went way beyond fringe case bugs and issues. E.g., problems with basic Views integration, empty geo fields returned as 0,0 ruining map views, calling node_save() wiping out the stored geo data, etc. Most of these are already documented as issues in the project's queue, and most are not getting much attention, even through they are clearly critical. I fully understand the challenges of maintaining modules on the "side", especially when they are complex, but that doesn't change the facts.
Hence my feelings that the module is simply not ready or stable enough to rely on for an even remotely sophisticated production site. If I had known all the problems I would run into ahead of time with Geo, I'm afraid to say I would not have used for the Save Our Gulf project. I hope the module matures and stabilizes and becomes the de-facto geo storage solution for Drupal, it's definitely needed.
When "giving back" means "taking control" of the situation...
That's fair. I have rejected various other modules for similar reasons, and I have even been known to fork, redo or workaround modules' deficiencies to stay on my own trajectory. But I've also been known to consult with a module's developer at their hourly rate, or fund development on the missing pieces. Why? because that helps me while helping a growing number of other users at the same time (who will hopefully help me out in the long run by making this imaginary module even better over time).
It's important to clear up what you're implying by maintaining modules on the "side". Our company works diligently to sustainably produce Drupal contributions. The key to sustainable, however, is being able to pay our people a living wage.
People generally assume that open source should be free and flawless without any sort of investment at all. And when it's not, the first move tends to be burning their resources on doing anything BUT making it better. Which is a huge shame, because we'd all be better off if we viewed open source as *leverage* - if everyone pitches in a tiny bit, we'd all have something pretty great.
Without a calling-out, which is not my intent, I have to wonder how much money goes into the analysis and implementation of GIS-for-Drupal solutions, and paid development on configuration, implementing workarounds, proprietary alternatives, or forks. If a fraction of these cumulative resources had been routed towards a sustaining a solution that supports more than one use case, the work you're describing could have been completed ten times over.
Thus, we're not "ignoring" Geo because it's not a priority for us, we're unable to get to it because it's not enough of a priority for anybody else to support its development. If we get bounties, small or large, we'll bend over backwards work them in. In the meantime, things we love and believe in are on the "side" while we spend 80 hours / week in the office to make ends meet while simultaneously trying to come at the funding problem from another direction.
By on the side I simply meant
By on the side I simply meant not paid being paid directly by a client or employer to work on a given module. I couldn't agree more on the sustainable angle to module development you mention, which is, especially at small companies, a huge challenge. One that I don't think there's a single solution to. But options include direct funding of module development, as you imply, leveraging the reputation you earn in the community for additional work, reusing modules/tools for higher margins when used on a recurring bases, or any combination of the above. I'm sure there are many more approaches I'm missing as well.
I think one of the challenges of paying for module enhancements as a developer/consultancy is dealing with big picture vision and direction of the module. While I assume we could agree on a specific set of requirements for a given project, that may not necessarily be what's best for the module in the long run, or the maintainer may decide to change directions in a future releases rendering my investment less useful. But that's certainly part of a bigger discussion. I certainly hope that Geo matures into the standard spatial storage solution for Drupal, and if I can help it along in anyway, I certainly will. I also appreciate the very thoughtful discussion.
Great writeup, and I agree
Great writeup, and I agree with most of the cons of the OpenLayers module (of which I'm a mantainer). Certainly performance could be improved, and it's initially more complex to set up a map than the others, although the approach yields a great deal of flexibility.
The only point I'd clarify is that the OpenLayers javascript library (a separate project from the module, of course), contains the Google Maps API rather than directly pulling map tiles from Google. The latter would certainly be a violation of the TOS and very risky default, but in fact OpenLayers only wraps the functionality provided - and displays the proper attribution - thus eliminating any kind of legal risk with Google.
And I'd agree with the other commenter that applying value to the 'alpha' status is not a good idea, since the distinctions are arbitrary and the choice of module maintainers more than anything else.
I'm certainly interested in polymaps, as it appears to be the first well-supported, fully-featured alternative to OpenLayers, which has a great deal of legacy code and abstractions that are no longer relevant to most users. Building the OpenLayers module so that it can also support polymaps is a real possibility for when polymaps progresses and we have hit a point release.
> "mantainer" Hmm, not the
> "mantainer"
Hmm, not the right word, but I guess that's also true.
Thanks for chiming in Tom. I
Thanks for chiming in Tom.
I really appreciate the clarification on OpenLayers' usage of the Google Maps API. I received the information about OL accessing the tiles directly second hand and took it at face value. But even a quick peak at the code reveals that it obviously renders GMap tiles via the API.
Also thanks for pointing out Polymaps, that wasn't on my radar. I assume this is the library you're referring to, from SimpleGeo, http://github.com/simplegeo/polymaps?
What are your thoughts on Mapstraction (the library, no the module)? The development is moving along very slowly, but I feel it does have a good start and the architecture in V2 is a big improvement.
Yes, that's the one. Though,
Yes, that's the one. Though, my focus is now on Modest Maps, since it has broader browser compatibility and a similar slim featureset.
Mapstraction is an interesting project, but I don't think it holds a lot of promise for big site builds. It definitely is cool for learning about mapping APIs, or even prototyping a 'better API layout'. The work that eliminates - switching map providers - is a corner case in most web development, and it places a layer of abstraction over the underlying APIs that prevents users from doing cool things. It's just a bit dated and solving problems for use cases that I don't have, and doubt others do.
Flash?
You don't find the Flash requirement for Modest Maps to be too big a handicap?
Really good points re: Mapstraction, and, to be honest, one of the main reasons we went away from it as well. It's great for simple embedded maps, but, in those cases, it's an extremely rare requirement / use case to switch underlying providers.
Ah - I'm referring to the
Ah - I'm referring to the javascript version - https://github.com/stamen/modestmaps-js
It's super-easy to find the other one (the flash and python ports), but the javascript one's where my energy is going, since it's a small but ingenious chunk of code, well-maintained by Tom Carden and inspired by a lot of the Polymaps work. Of course, it has some 'stunning feature gaps', the first of which is, currently, no core support for multiple layers, but these are relatively easily addressable, and things that we might eliminate as feature needs anyway.
Drupal 7
Still a relevant post in 2011. However Drupal 7 has been out for awhile now and support on several of these modules is missing. For example I would like to use Open Layers, which has an alpha 7 port, yet Geo is stuck back on 6 with no updates in nearly a year. Even the "gold standard" Mapadelic solution is lacking polish in 7.
A pity.
Er, I agree. (full
Er, I agree. (full disclosure: I no longer work on Drupal now that devseed has switched to nodejs)
The field system in Drupal 7 / Views made OpenLayers's job even more complex, and it ends up spending more time fighting against the structures of Drupal than it does making maps. I put in the time to do the initial port, and we created Geofield to address the data-input scenario, but it's a dim future until people start thinking about Drupal doing things other than small-scale content management. For large-scale geo use cases, I wouldn't recommend Drupal or any of its modules, even the one I love/hate/have worked on too long, OpenLayers.
geofield and openlayers
As Tom mentioned, while they may not be perfect, Geofield and OpenLayers are the best options for Drupal 7, at least for the time being. With devseed more or less moving on, it will up to the rest of us to step it up and evolve the Drupal mapping toolset. That's mostly a nudge to myself ;)
To me also!=) goldbet
To me also!=) goldbet