New staff profiles content type launched!

One of the recent addition to the main University website content management system (EdWeb) is a new content type – staff profile. The CAHSS Web team has worked on this in close collaboration with Information Services .

Staff profle imageHow did the new staff profile come to the world?

Around the College of Arts, Humanities and Social Sciences, and beyond, throughout the University, each and every School had a slightly different way of presenting staff profiles Often, staff profiles used different systems depending on the University unit. The key goal was to standardise this but in a way that allowed flexibility and variation.

Continue reading

Integrating a Drupal 7 website with the University’s EASE authentication service

ease1In the web team we recently took over the technical maintenance and development of the Edinburgh College of Art (ECA) website. Part of this development work involved integrating the University’s standard authentication service (EASE) with the Content Management System (CMS) used by the ECA website, Drupal 7.

Although the Drupal CMS has been used for many years throughout the University, it has not been widely used with EASE. The only exceptions that I am aware of are work I did myself in collaboration with Colin Higgs on the School of Engineering website to implement EASE authentication on a Drupal 6 plaftform in 2010, and which has subsequently been updated to Drupal 7 by Billy Rosendale, and, built using Drupal 6. The University Website Programme (UWP) are currently developing Drupal 7 for use as the main University CMS and part of this development process is support for EASE authentication – and this EASE integration work was used by the web team as a model for the ECA website.

Continue reading

ECA Degree Show website

The Edinburgh College of Art Degree Show opens on 24th May, and we were tasked with developing a new website for it. In many ways this is a dream project, as there is so much fantastic content! When you have such rich content, the job of the website is simply to showcase it with an unobtrusive design. Nicky Regan at ECA produced attractive designs, based on the new ECA branding, and we brought it to life as a Drupal website.

Home Page

Home Page

Drupal was chosen mainly as it’s what the new ECA website is built on, and will ultimately be the CMS for the new University website. It made sense to give admins a similar interface as the ECA site, and it was also an opportunity to further our own technical knowledge of Drupal.

Continue reading

Building websites with ‘lightweight’ GIS functionality

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.

Drupal OpenLayersAPI mapWe 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).

Google Charts API mapThe 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.


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.