Drupal and OpenLayers

In the web team we have been experimenting with and building some web-based geographic interfaces that enable websites to collect, store and display content that has a geographic element.

This content is typically things like buildings in an urban environment, content which has an important location-based dimension and thus requires geographic data-handling techniques.

We have built a website using the Drupal 7 Content Management System (CMS) and the OpenLayers API which supports the ability to build interfaces to collect and store geographic data, and to visualise that data (see image to the right). OpenLayers is a very useful open-source JavaScript Geographic Information System (GIS) tool that is not a formal part of the Drupal CMS but has been imported into Drupal with the OpenLayers module.

This module allows a Drupal website to:

• use the full functionality of OpenLayers to display dynamic map data (using ‘tiles‘ from a WMS server) as a ‘basemap‘ in an interface (or ‘widget’) on a website
• make use of the standard features and behaviour of current web-based mapping provided by Google Maps (satellite and topographical basemaps, ‘dragging’ the ‘slippy’ map) or OpenStreetMap (or any other ‘public’ or locally-managed WMS-compliant server) that users are familiar with
• overlay the basemap with a data ‘layer‘ consisting of Drupal node content that has been ‘tagged’ in Drupal with latitude/longitude and placename geographical or ‘spatial’ data
• use the OpenLayers API to easily build map interface options such as a scale bar, zoom and pan icons, marker icons, popup windows and a basemap data layer selector

Storing the data model in the Drupal database (we use MySQL) in this way (as ‘spatial’ data) allows:

• proximity search query interfaces to be built (e.g. find all data within 10km of a supplied location)
• graphical map interfaces to be displayed with markers that show the location of the Drupal node content (with special icons for data that is spatially ‘clustered’ together)
• spatial data to be associated with non-spatial (‘attribute‘) data such as images, dates and textual descriptions

The Drupal OpenLayers module is used with the Drupal Views module to achieve this. As well as the Drupal OpenLayers module this ‘spatial’ functionality is also enabled with the Drupal modules Geofield, geoPHP and Proj4JS.

Alongside the graphical map interfaces for this website we also built a gazetteer interface – the gazetteer uses the Drupal core Taxonomy module to create a hierarchical list of 1380 city, town and county (local authority) placenames from the Ordnance Survey ‘official’ list (the OS 1:50,000 Gazetteer database, available from Edina’s Digimap service), and uses a Drupal view to allow the user to expand the hierarchical tree and scroll through the placenames to find Drupal content that has been tagged with the associated placenames. It is also possible to support with this system ‘alias’ placenames (such as alternative historical placenames).

Google Charts

We’ve also used the Google Charts API for data visualisation. The Google Charts suite of tools contains the Geochart visualisation tool (along with lots of other useful types of visualisation) – and because the emphasis with Google Charts is on numerical data visualisation, this is not strictly speaking a formal ‘map’ (in the way that Google Maps or OpenStreetMaps are, for example), this matches more closely with the requirements of some websites in which the focus is on the data and not necessarily the ‘map’. Google apparently calls this interface a ‘Geochart’ rather than a ‘map’, to make the distinction.

We have built a website that has these requirements and uses some numerical student data, specifically the numbers of students from a country of origin, and displays this data using the Google Charts API (see image below).

The Google Charts map tool offers a basic world basemap (which is a SVG image) and the ability to display a data layer on this map. It’s a good compromise between functionality and ease of setup combined with simplicity of use. It’s not a web-based map of digital ‘layers’ in the way that Google Maps or OpenStreetMap is, with multiple hierarchical raster/vector map data layers that are retrieved dynamically from a WMS server and which can then be zoomed and panned, but it allows the data to be ‘visualised’ in a more ‘lightweight’ way much more simply and with little technical overhead – we experimented with using circles whose diameter and colour was proportional to the numerical data being visualised.

This works very well and it can be set up very simply – there is no requirement to sign up for a Google Maps API key, the interface does not set cookies on the client browser, the data can be stored on a locally-managed server (this is useful for managing DPA issues) and it just uses a Google JavaScript class library and some simple JavaScript configuration for all the functionality. It is also very easy to embed this map into a Polopoly CMS web page.

Summary

These websites that we built are not strictly speaking offering fully-featured GIS functionality such as that supported by applications such as ArcGIS (that offers the ability to perform complex spatial queries and visualisations using sophisticated spatial data storage and indexing techniques), but they offer some GIS functionality for relatively little technical and licencing overheads.