Feature Talk: Prof. Sergio Rey talks about PySAL, Open Source & Academia

We’re really pleased to announce that on Wednesday, 22 February Professor Sergio Rey, of the School of Geographical Sciences and Urban Planning at Arizona State University will be discussing the Python Spatial Analysis Library (PySAL). His talk will provide an overview of PySAL and illustrate key components of the library drawing on examples from regional inequality dynamics and urban analysis.

Future plans for PySAL and related projects will also be outlined. Lessons learned in directing a distributed, open source project will be shared with a particular emphasis on the challenges and opportunities found at the intersection of open source and the academy.

The talk will be followed by drinks and a chance to speak informally with Prof. Rey, or just to mingle and chat with other researchers.


Wednesday 22 February at 5:30pm


Room S-3.20, Strand Building, WC2R 2LS


Download the flyer: serge-rey-talk-22-february.

Aspect-Slope Maps in QGIS

While working with Naru to design our new 2nd year GIS methods training course (with parallel QGIS and ArcGIS streams!), I came across a rather striking map on the ESRI blog that managed to combine both slope (steepness) and aspect (direction) in a single representation. This post explains both a problem with the way that the colour scheme was specified and how to replicate this type of map in QGIS (with style sheet).

The Inspiration

Here’s Aileen Buckley’s Aspect-Slope map in all its glory – this is a the area around Crater Lake, Oregon, and you can see that it neatly captures both the direction of slopes (aspect) and their steepness (degree). So features like the crater stand out really clearly, as do what I assume is evidence of lava flows and such, while lesser features gradually fade towards grey, which means flat.


So these maps combine two properties:

  • The direction of the slope is expressed in the hue – different directions are different colours.
  • The steepness of the slope is expressed by its saturation – steeper slopes are brighter colours.

Rather than just jump into providing you with a style sheet, I think it’s useful to trace this back to its constituent parts as it turns out that ESRI has made a mistake in setting up their colour maps.

Aspect Mapping

Aspect maps give the viewer a sense of the direction in which various slopes derived from  a Digital Terrain Model (DTM) lie – typically, we do this by dividing the angle of the slope into eight quadrants: North, Northwest, West, Southwest, South… well, you get the idea.

Here’s an example of what the standard aspect map out of ArcMap looks like as posted by the Rural Management and Development Department of Sikkim:


This, helpfully, gives us the ranges that we’ll need for our aspect-slope map. Note, however, that we don’t really have any idea how steep any of these obvious hills are.

Slope Mapping

Slopes maps are, obviously, intended to fill in the gap in terms of how steep an area is. Typically, we can measure this as either a degree value from one raster cell to the next of the DTM or as a percent/ratio (1-in-10 gradient = 10%). Here’s a nice example looking at the link between coffee bean growing areas and slope in Costa Rica:


Unlike the aspect map, the divisions used in the slope map seem to be largely arbitrary with no real consensus on the mapping between measured steepness and terminology. The clearest guidance that I could find came from The Barcelona Field Studies Centre and looked like this:

Slope (%) Approx. Degrees Terminology
0.0–0.5 0.0 Level
0.5–2.0 0.3–1.1 Nearly level
2.0–5.0 1.1–3.0 Very gentle slope
5.0–9.0 3.0–5.0 Gentle slope
9.0–15.0 5.0–8.5 Moderate slope
15.0–30.0 8.5–16.5 Strong slope
30.0–45.0 16.5–24.0 Very strong slope
45.0–70.0 24.0–35.0 Extreme slope
70.0–100.0 35.0–45.0 Steep slope
> 100.0 > 45.0 Very steep slope

A Better Aspect-Slope Map Scheme

In order to create an aspect-slope map, we need to combine the two data ranges into a single number that we can use as a classification, and  this is where the ESRI blog approach goes a bit off the rails. In their approach, the ‘tens column’ (i.e. 10, 20, 30, …) represents the steepness – so 0–5 percent slope=10; 5–20 percent slope=20; and 20–40 percent slope=30 – and the ‘units columns’ (i.e. 0–8) represents aspect – so 0–22.5 degrees=1; 22.5–67.5 degrees=2; etc.

The problem with this approach is that you have a lot of problems if you want to add or remove a steepness category: in their example the highest value is 48, which means ‘highest value’ and an aspect of Northwest. But what if decide to insert a class break at a 30 percent slope to distinguish more easily between ‘Extreme’ and ‘Steep’? Well, then I need to redo the entire classification above 30… which is really tedious.

If we switch this around such that aspect is in the tens column (10–80) and steepness in the units column (0–9) then this becomes trivial: I just add or remove breaks within each group of 10 (10–19, 20–29, etc.). No matter how many breaks I have within each aspect class, the overall range remains exactly the same (10–89 if you use the full scale) regardless of the steepness classification that I’m using. It’s not just easier to modify, it’s easier to read as well.

Implementation in QGIS

For all of this to work in QGIS, you need to generate and then reclassify a slope and an aspect analysis from the same DTM. You can do this using outputs from the raster Terrain Analysis plugin (that’s the point-and-click way), or you can build a model in the Processing Toolbox (that’s the visual programming way). I personally prefer the model approach now that I’ve finally had a moment to understand how they work (that’s a topic for another post), but one way or the other you need to get to this point.

Regardless of the approach you take (manual or toolbox), once you’ve got your two output rasters you then need to reclassify them and then combine them. Here’s the mapping that I used to reclassify the two rasters as part of a model. You would copy these lines into text files and then use the GRASS GIS reclassify geoalgorithim while specifying the appropriate reclassification file.


0.0 thru 22.499 = 10
22.5 thru 67.499 = 20
67.5 thru 112.499 = 30 
112.5 thru 157.499 = 40
157.5 thru 202.499 = 50
202.5 thru 247.499 = 60
247.5 thru 292.499 = 70
292.5 thru 337.499 = 80
337.5 thru 360.5 = 10

Slope-Reclassify.txt (for percentage change)

0.0 thru 4.999 = 0
5.0 thru 14.999 = 2
15.0 thru 29.999 = 4
30.0 thru 44.999 = 6
45.0 thru 100.0 = 8

So that’s a 5-class steepness classification, but you could easily set up more (or fewer) if you needed them.

Once you’ve reclassified the two rasters it’s a relatively simple matter of raster layer addition: add the reclassified slope raster to the reclassified aspect raster and you should get numbers in the range 10–88.

Here’s the model that I set up (as I said above, more on models in another post):


Specifying a Colour Map

Taking the ‘Aspect Slope Map’ output, all we need to do now is specify a colour map. I took the colours posted by ESRI in the colour wheel (as opposed to the ones specified in the text) and converted them to hexadecimal since that was the easiest way to copy-paste colours. I think, however, that I’ve ended up with a slightly ‘muddier’ set of colours than are in the original Crater Lake set as you’ll see with my ‘Sussex Aspect-Slope Map’ below:

Sussex Aspect Slope Map

And, finally, the QGIS style sheet file is here (sorry about the zip format but .QML is not a recognised style type):

Aspect Slope Style – Close to Original.qml


I’m sure that this style sheet could be further improved (and may even try to do so myself, though I’d also welcome submissions from anyone with some time on their hands), but at least this gives users and easy way to combine representations of slope and aspect in a single map using a reclassification scheme that is simple to extend/truncate according to analytical or representational need. Enjoy!

‘GeoCUP’: Linux System-on-a-Key for Geospatial Analysis Project

We have received funding to develop a system for managing and distributing a full Linux system-on-a-key to students on our new undergraduate pathway. We are looking for an Informatics student (PhD, MSc, or BSc) to research, recommend, develop and test an appropriate solution that meets our needs. Read on for more information.


This Autumn, the Department of Geography is launching an innovative new undergraduate ‘pathway’ in Geocomputation and Spatial Analysis (GSA). The pathway responds to a recognised gap not only in our own module offerings, but across the offerings of UK universities as a whole: the need for geographers with the programming skills to process ‘big geo-data’ using Free and Open Source Software (FOSS) and able to tackle pressing geographical challenges in commercial, governmental, and third-sector data analysis and visualisation.

Effective delivery of this pathway will require students to store and manipulate large data sets, to install and manage new ‘code libraries’ and applications on-demand and as-needed, and to be able to collaborate flexibly on- and off-line across multiple platforms (mobile, personal, and institutional). Within the constraints of managed IT infrastructure these needs can only be met through the use of ‘bootable’ USB flash drives that provide a platform on which open-source geocomputation and spatial analysis tools can be hosted and run.

To meet this need this project will develop the GeoComputation USB Platform (GeoCUP). GeoCUP will allow students to manage and run a Linux-based operating system over which they have full administrative control. This capability is integral to successful learning on the GSA pathway as the innovative nature of student assignments and independent projects requires the use of compiled open source software libraries and tools.

This project therefore seeks to research, configure, develop, and test a management strategy to support this bootable USB flash drive approach so that it: i) enhances student experience of the College’s computing environment; ii) minimises the maintenance demands on staff as this approach cannot be supported by central IT; and iii) creates opportunities for other staff to deploy a similar system when flexibility and agility in computing are called for.

Swiss Army knife with USB key (swissarmy365.co.uk).


There are several overarching objectives for how GeoCUP will improve the student learning experience:

  1. An operating system over which students have full control will allow them to maintain and customise their individual instance of GeoCUP to suit their personal computing needs. As the students develop competence in programming and analytical techniques, they will begin to pursue separate, distinct challenges requiring the ability to compile and install code libraries, or even entirely new applications, on-the-fly. This is impossible to achieve in a traditional, tightly-managed computing environment context.
  2. We will be able to maintain and update the ‘master version’ of GeoCUP so that incoming students to the pathway will always be working with the most up-to-date system possible. In addition, should a student lose a USB drive or suffer some other type of data loss, we will be able to quickly provide them with a fully-functioning and up-to-date version of GeoCUP from which to recover. We will also be able to enforce data-protection requirements such as the use of encrypted partitions to ensure that the USB flash drives are unusable and inaccessible without the student’s password.
  3. GeoCUP will be configured with the full set of programming support tools needed to ensure the development of computational (spatial) data analysis skills, including not only Enthought Canopy and QGIS, but also open collaboration and development tools used by technology firms such as PayPal and Google. Many of the required tools are not available at all through managed IT systems, these include: the GitHub versioning tool; the Postgres+PostGIS spatial database; the routino routing application; the RStudio IDE; Dropbox; and the Slack collaboration tool, amongst others. Our intention is to promote students’ employability by grounding their experience in a realistic computing environment as used by commercial and other organisations.

As a result of the ‘real world’ environment GeoCUP will provide, incidental – but by no means insignificant – benefits to student experience, including:

  1. The ‘Slack’ collaboration system functions on all computing platforms, including all major mobile ones, and creates a series of ‘channels’ across which students and staff can communicate in a way that more closely mirrors student preferences: content (including code) is ‘pushed’ in real-time to all devices, can be categorised using hashtags, and serves as a instantly-searchable archive of interactions. This complements the 1-to-1 and 1-to-many format of email and the KEATS ‘broadcasting’ tool, and is expected to encourage dynamic peer support and collaboration, while avoiding repeated “Can you tell me…” messages to staff.
  2. The GitHub version control platform is now the de facto standard for collaborative programming projects in all sectors. It also brings the additional benefit of mitigating data loss in the event of corruption, loss of a USB flash drive, or other unforeseen events. We will therefore be reinforcing for students the importance of integrating code-management into their workflow.
  3. Students will also be able to take advantage of more open, platform-independent cloud-computing resources such as Dropbox and Amazon Web Services (AWS), which is not possible on the existing Microsoft-based SharePoint solution.

More Information

Selected researcher will be paid in accordance with King’s College London guidelines. Project work can begin immediately and must be complete by late-August.

For more information about the project timeline and for expressions of interest (by Thurs 25 June), please contact Jonathan Reades or James Millington in the Department of Geography.