OpenLayers Technical

OpenLayers 3


As a learning exercise, I been trying to “migrate” my recent #indyref map from OpenLayers 2.13.1 to the very new version 3.0.0 of the popular mapping API. It seemed a good time to learn this, because the OpenLayers website now shows v3 as the default version for people to download and use. Much of my output in the last few years has been maps based on OpenLayers, so I have considerable interest in the new version. There are some production sites using OpenLayers 3 already – for example, the official Swiss map.

I use the term “migrate” in inverted commas, because, really, OpenLayers 3 is pretty much a rewrite, with an altered object model, and accordingly requires coding from scratch a new map rather than just changing a few lines. It has so far taken me four times as long to do the conversion, as it did to create the original map, although that is an inevitable consequence of learning as I go along.

I’ll update this blogpost as I discover workarounds.

Shortcomings in v3 that I have come across so far:

  • No Permalink control. This is unfortunate, particularly as “anchor” style permalinks, which update as you move around the map, are very useful for visualisations like DataShine where people share specific views and places, and I can inject extra parameters in. The site linked above suggests this is a feature that should not be in the core mapping library, but instead an additional library can query/construct necessary parameters. Perhaps, but I think layer/zoom/lat/lon parameters are such a key part of a map (as opposed to other interactive content) that they still deserve to be treated specially.
  • The online documentation, particularly the apidoc, is very sparse in places. As mentioned above, there is also some mismatching in functionality suggested in the online tutorials, to what is actually available. Another example, the use of “font” instead of “fontSize” and “fontStyle” for styles. This will improve I am sure, and there is at least one book available on OpenLayers 3, but it’s still a little frustrating at this stage.
  • Label centering on the circle vectors is not as good as with OL 2. This is possibly due to antialiasing of the circle itself. You can see the labels “jump” slightly when comparing the two versions – see links below.
  • Much, much slower on my iPhone 4 (and also on a friend’s Android phone). This is not what I was expecting! This is the “killer” problem for me which means I’ve kept my map on OL 2 for now. Wrapping my vector layer in an Image layer is supposed to speed things up, but causes the layer not to display on my iPhone. Disabling the potentially expensive mousemove listener did not make a difference. Adding a viewport meta tag with width=device-width speeded things up a lot so that it was almost as fast as OL 2 (without the meta tag) but then I would need to rewrite my own UI for mobile – something I don’t need to do with the OL 2 version!
  • No support (yet) for UTFGrids. These are a form of vector tiles, for metadata rather than geographic features, which I use on the DataShine project.

Things which I like about the new version:

  • Smooth vector resizing/repositioning when zooming in/out on a computer. (N.B. This is only when using a Vector layer and a Vector source, rather than Image layer with an ImageVector source that itself uses a Vector source.)
  • Attribution is handled better, it looks nicer.
  • No need to have a 100% width/height on the map div any more.
  • Resolution-specific styling. I’ve used this to hide the labels when zoomed out beyond a certain amount.
  • Can finally specify (in a straightforward fashion) a minimum zoom level.
  • Point coordinates and extents/bounds are specified in a much simpler way.
  • On a more general note, the new syntax is more complete and feels less “hacky”. The developers have taken the opportunity to do it “right” and remove inconsistencies, misplaced functionality and other quirks from the old version. For example, separating out visual UI controls and interaction management controls into two separate classes.
  • Drag-and-drop addition of KML/GeoJSON vector features. Example (use this file as a test).

Some gotchas, which got me for a bit, but I was able to solve:

  • You need to link in a new ol.css stylesheet, not just the Javascript library, in order to get the default controls to display and position correctly.
  • Attribution information is attached to a source object now, not directly to the layer. A layer contains a source.
  • Attribute-based vector styling is a lot more complicated to specify. You need to create a function which you feed in to an attribute. The function has to return a style wrapped in an array – this may be the closure syntax in Javascript that I have not come across before.
  • Hover/mouseover events are not handled directly by OpenLayers any more – but click events are, so the two event types require quite different setups.
  • Minor differences between the debug and regular versions of the library. The example I noticed is that the debug version allows ol.control.ScaleLineUnits.METRIC to be specified as an attribute for the ScaleLine control, but the non-debug version needs to use an explicit string “metric”.
  • No opacity control on individual styles – only on layers. This means I can’t have the circles with the fill at 80% opacity but the text at 100% opacity. Opacity can be set on styles, but has to be specified as part of the colour, in RGBA format (where A is the alpha, i.e. opacity, you want) rather than as a separate attribute. This is contrary to the tutorials on the website. Layer opacity can continue to be specified as seperate attributes.

My OpenLayers 3 version of the #indyref map is here – compare with the OpenLayers 2 one. Note that, since first writing this blogpost, I’ve subsequently updated the OpenLayers 2 one to change the cartography there further.

BODMAS OpenLayers

DataShine Travel to Work Flows


Today, the Office for National Statistics (ONS) have released the Travel to Work Flows based on the 2011 census. These are a giant origin-destination matrix of where people commute to work. There are various tables that have been released. I’ve chosen the Method of Travel to Work and visualised the flows, for England and Wales, on this interactive map. The map uses OpenLayers, with an OpenStreetMap background for context. Because we are showing the flows and places (MSOA population-weighted centroids) as vectors, a reasonably powerful computer with a large screen and a modern web browser is needed to view the map. The latest versions of Firefox, Safari or Chrome should be OK. Your mobile phone will likely not be so happy.

Blue lines represent flows coming in to a selected place, that people work in. Red lines show flows out from the selected location, to work elsewhere.

The map is part of the DataShine platform, an output of the BODMAS project led by Dr Cheshire, where we take big, open datasets and analyse them. The data – both the travel to work flows and the population-weighted MSOA centroids – come from from the ONS, table WU03EW.

View the interactive map here.


Conferences OpenLayers

FOSS4G 2013 Conference


Well, that was good.

September this year was Maptember with numerous conferences with a geographical flavour taking place in the East Midlands. The undoubted highlight for me was FOSS4G 2013, the annual conference for OSGeo which travels around the world, this year it was conveniently in Nottingham, so I was able to make it along relatively easily. FOSS4G is Free and Open Source Software for GIS and as such the conference is a good mix of open-source technology and geography.

As I will be spending some time this month writing a book chapter on open source GIS, the conference was an unmissable event for me, even though a clash with another conference (ECCS) abroad meant logistics were tricky – in the end, a 6am wakeup call necessitated and lots of freshly ground coffee (very big thumbs up to the conference for that – a first) helped me out.

Just over 800 people attended the conference and there were up to 9 parallel streams. With many talks sounding very interesting it was often hard to pick a track to follow, not least as there was a 10 minute walk between the two main conference venues. I had brought my bike up from London, which helped.

Highlights of the conference for me were:

  • A keynote by Ben Hennig of Worldmapper fame on the need for the Open Source geospatial software community to remember about the cartography – the gist being just because you have the tools to map, doesn’t always mean you jump straight in without thinking about the better picture.
  • IMG_4959Keynotes by the two top sponsors at the conference – the Ordnance Survey and the Met Office. Both sponsors knew who they were talking to, and pitched the technical level appropriately. At both organisations, the open source ecosystem is pushing in from the sides and slowly becoming a core asset. Both also have large open datasets ready for crunching in your open source GIS of choice.
  • QGIS 2. This was launched at the conference. I’ve always been a fan of this open source GIS in particular (there are others available, including the venerable GRASS, uDIG etc), in no short part because of its excellent integration with PostGIS, that it works well on the Mac and that it is extendable and drivable with Python. Also, excitingly for the project in the longer time, the developer time and effort has ramped up recently – it’s reassuring to be using an open source application with a large and enthusiastic team beside it. Also – it’s not called Quantum anymore, although it’s going to take me a while to stop accidentally still calling it that.
  • OpenLayers 3. The first beta of this was also launched at the conference. I have long been a fan on OpenLayers, having regarded it as a richer and more powerful web mapping API than the Google Maps API, and have used its vector styling capabilities extensively. However, it has somewhat had its lunch stolen from it by Leaflet and by Google Maps continuously innovating, so it was due a rewrite – and OpenLayers 3 looks to be that rewrite!
  • IMG_4956PostGIS/PostgreSQL. There were a number of PostGIS talks, almost all of which were massively oversubscribed – not sure why they were in one of the smallest venues – one even got a representation later! PostGIS is another enormously impressive bit of open source technology, and the rapid-fire demonstration of what was new made me realise I really need to move forward and update my old version! (& do more cool stuff with it.)
  • The final talk before the closing session was by a tech person at ESRI. He had an awful lot to say in 20 minutes, and consequently overran, but had numerous interesting things to say on JavaScript geo libraries, many of which he lamented hadn’t been covered much (or at all) in the conference – I agree, but the conference did have to pare down nearly 400 submissions to under 200 at the event – such as TopoJSON, Node JS, JS Topology Suite, Shapefile.js, or D3. He did bash QGIS a bit which didn’t go down very well, but to be fair some of the QGIS talks had previously bashed ESRI a lot, which wasn’t called for… Good for ESRI for making the effort to come, even if (or indeed because) QGIS is rapidly becoming a serious competitor.
  • The conference food – it was excellent.
  • Catching up with a bunch of people in the community, not just the OSMers – e.g. Rollo (OS), Addy (Edina), Andy, Ben. Andy showed me some new OpenStreetMap renderings which use some advanced cartographic techniques in Mapnik and look great. Mapnik was another topic that I missed from the conference.
  • Evening tour of Nottingham by SK53 (actually just the leg from the curry house to the Ye Olde Trip To Jerusalem, but we went an interesting way.) SK53 has also written up in detail a blog post based in part on a comment I made!
  • IMG_4944The CASA iPad Wall (which was the other reason I was there) was showing, Ken Burns style, the various submissions to the map competition. In the end, the wall pretty much ran itself, thanks to careful stewardship by the Ordnance Survey who had requested it, and some high quality code that had been written for the display. Interestingly, Wired covered the conference, and focused on the iPad Wall, which really was quite a minor, albeit cool, part of the conference.
  • Winning a green glass globe paperweight for my submission to the aforementioned competition, namely the global version of my Bike Share Map – “Best Web Map”. This was completely unexpected, indeed I was already on a train back to London, having left just before the announcement, and found out through Twitter. “Singing” legend Gregory is, I hope, keeping careful stewardship of the globe and I will grab it in due course.

There’s a lot I didn’t get to see – Cartopy/Iris, more CartoDB, plus lots of interesting sounding papers presented on the integrated academic track.

This could have been the best conference I’ve ever been to. Ever. Well done to the organising team – I know they worked incredibly hard to deliver, but it was very definitely worth it.

Mashups OpenLayers

Rise of the Colourful Circles – Election 2010 Visualisation


I’ve fixed and tidied up a visualisation I created back in 2010, which showed the results of that year’s General Election in the UK. Newer versions of OpenLayers had broken it (specifically the use of addUniqueValueRule with a custom context resulted in no circles appearing) and also the UI looked rather rudimentary. Now it has rounded corners, transparency, more spacing and a prettier font!

Although it was my first “coloured circles” visualisation (the Bike Share Map followed on from it a few months later when London’s system launched) it was my most sophisticated, with the circles having different coloured areas and borders, and changing in size – plus a view where the colour itself is calculated from the numeric values – select the “Constituency Colour” from the first pop-down.

The key benefit of the circles other the traditional “colour in the constituency” election map is that sparsely populated rural areas did not dominate the map. It also means that, when viewing the results from individual parties, that each pixel of each colour represents exactly the same number of votes – whether in central London or the Highlands of Scotland.

The background map is not great at all – a mess of greys and names. At the time, I was strictly keeping colour out of it, so that the only colour was the data being visualised. The early Bike Share Map also had the uninspiring background, with a dark grey river flowing past lighter grey lands. These days I’ve relented – a small amount of colour is OK, as long as the shades are pastel and appropriate, and the key data’s colours are vibrant.

You can see the map here.

Data Graphics OpenLayers

Rank Clocks and Maps: Spatiotemporal Visualisation of Ordered Datasets

Rank Clocks are a type of visualisation invented by Prof Michael Batty here at UCL CASA. They are time-based line charts, wrapped around a clockface – with the start date at the top, wrapping around clockwise to the end date. The lines on the clock show the change in ranking of the items being visualised. By effectively wrapping a line chart around itself, certain patterns, that would be otherwise hard to spot, become clearer.

Starting from Prof Batty’s Rank Clocks application (written in VB), I created a web version that has a subset of the application’s features, but also includes a map, allowing both temporal rank changes, and location, to be shown. A future enhancement would also be to show the change in location with time as well (an example would be how football clubs have moved around in London over the years and how their relative rank in the leagues has also varied) but for now each item in the dataset has just a single point location that remains constant with time.

Live Rank Clock site here.

The “classic” Rank Clock is of New York skyscrapers – looking at the clock allows bursts of skyscraper development to be easily spotted, and as New Yorkers have been building skyscrapers for over a hundred years, and have many of them, it is a rich dataset. I have curated a London equivalent from various sources including Wikipedia. It includes the many residential towerblocks of the 1960s/1970s, many now knocked down, but is not quite the same as New York’s.

The website is written in Javascript, using OpenLayers both for the map (with OpenStreetMap background) and for the rank clock itself. For the rank clock, I am doing some basic trigonmetry to calculate the coordinates needed to show the lines and converting from polar coordinates to “native” screen coordinates. This is a novel but not particularly efficient use of OpenLayers, but I used it as I am quite familiar with using OpenLayers, particularly for showing lines as vectors, rather than using a Javascript vector-based charting API which would be the more obvious choice.

My interpretation of the Rank Clock concept has plenty of flaws – in particular, data can often be easily obscured, and spotting patterns in noisy (frequently changing rank) data is difficult. It’s difficult even to select lines (to see their caption) if other lines are nearby and overlaying them. Nonetheless, it can provide an unusual way of looking at some interesting datasets.

For one of the datasets in the sample website (US baby names) I have repurposed the map to effectively show a 2D graph indicating beginning and ending (in time) positions of the names – so here OpenLayers is being used to show two “maps” – but neither are actually maps.

I’ve also linked into the Google Earth browser plugin (installation maybe be required), replacing each dot on the OpenStreetMap map, with a column of varying height (and colour) based on the initial rank, with an extent appropriate to the data set. Google Earth can be refreshed by supplying new KML information – and it turns out that OpenLayers has a rather nice KML conversion and export feature for any geometry in it, which allows Google Earth to be driven in this way. This is done when clicking on a Rank Clock line, allowing the equivalent feature in Google Earth to be redrawn with a thicker border. Unfortuantely events cannot be captured from Google Earth and back into the OpenLayers map, so clicking on a pillar in the former will not highlight the corresponding Rank Clock line in the latter. Still, it’s a nice way of linking spatialtemporal information and then visualising it in 3D.

I carried this work out quite a while ago, but haven’t mentioned it to now, as it’s not complete. There are only a limited number of datasets available, and plenty more features could be added – and the navigation and interaction improved significantly. Please bear this in mind when viewing the live site.

There are a few “toy” features already though – you can invert the rank clock (normally the top-ranked items are in the middle of the circle and so are hard to see), change the metric the colour is showing, and filter and relayer.

The three rank clocks shown here are showing: TOP – Changes in population of the London Boroughs of Newham and Tower Hamlets, and the City of London, over 150 years. The City of London line spirals outwards, showing its drop in population (and so rank). Tower Hamlets also shows a big drop in rank during WWII, but has started to increase again recently. Westminster’s population rank has steadily increased, until WWII – but again its rank has also more recently increased. MIDDLE – Tall buildings in London, coloured by year they were built. The oldest (red) buildings have been selected and show in Google Earth, showing that such buildings were entirely in the centre and west of London. BOTTOM – US company revenue. The San-Francisco-headquartered companies are selected on the map and correspondingly highlighted on the rank clock, showing that only one was founded before the 1970s – IBM – and a general spiralling inwards as Silicon Valley grows.

Live Rank Clock site here.


Review: OpenLayers – The Book

OpenLayers 2.10 Beginner’s GuideErik Hazard, Packt Publishing

The OpenLayers 2.10 Beginner’s Guide (buy: Amazon) is a guidebook for a technology that is relatively unknown in the broader technology world – OpenLayers being a JavaScript-based online mapping framework, the open-source equivalent of the popular Google Maps API. As mapping and open source software have increasingly become mainstream over the last couple of years, such a guide has appeared at just the right time.

As with many open source projects, documentation and startup guides are freely available online, but their quality and completeness often is very variable. A paper-based guidebook is still the best way to get to grips with the complete capabilities of a complex framework like OpenLayers – but with the danger that it is likely to date quickly as the project evolves. The author is particularly brave in referring to the current version – 2.10 – in the book title, as any subsequent release (2.11 is probably just around the corner) will appear to age the book, while actually it is likely the vast majority of its content will remain relevant with the new version.

The book serves both as an introduction for beginners to JavaScript and/or online mapping, while also acting as a reference that means it can remain in the development bookshelf for even more advanced developers. There is not a standalone reference section – but then the automatically-generated JavaScript documentation online perhaps serves best for this. However the detail of the chapters mean they effectively can act as a near complete reference.

OpenLayers does have a notably steeper learning curve than (for example) the Google Maps API – although it is ultimately more powerful. A physical, complete guide like this does therefore have a definite benefit to a developer aiming to produce online mapping applications based on open source technology.

The book, slightly surprisingly, introduces some fairly weighty programmatic detail right at the beginning – in Chapter 1. For example, I wasn’t expecting a discussion of Object Orientated Programming, and defining objects, instances and classes/subclasses, so early on in the book. It could be argued that these are important concepts to learn early, o gain a good understanding of a powerful API. I do still think that these would be likely to intimidate a genuine beginner, who just wants to quickly create a map.

The second chapter covers Firebug in depth. While again I was not expecting this so early in the book, I can understand why it is introduced at this stage. It is easy to make typos when writing JavaScript, and a working knowledge of Firebug stops painful debugging that might be necessary for someone just starting out with JavaScript development. But it is possible to use OpenLayers and dip into its rich API without knowing about Firebug, and such detail might serve to intimidate a novice, who would get buried in the detail – hence why I was surprised to see this inclusion so early.

It is interesting that OpenStreetMap (OSM) was not introduced until a third of the way into the book. Before, complex concepts such as map projections and coordinate transforms are used. You really don’t need to know these to use OpenStreetMap! OpenLayers is of course used for so much more than just showing OSM maps – at a recent academic conference I was impressed by the number of speakers that showed complex web applications using OpenLayers. But the “simple case” for OpenLayers is pulling in Google Maps or OpenStreetMap map tiles, and putting pins on them – “mashing up” data, without worrying about projections, ESPG numbers, JavaScript debugging and WMS parameters – all of which you’ll meet early on in the book. Only on page 124 is a simple mashup (Google + WMS + vector editing) introduced, with a more complex example application dissected in the very final chapter.

The vector layers – which in my opinion are the most interesting and powerful part of OpenLayers are introduced all the way back in chapter 9. Vector styling – advanced but powerful – is in the chapter after that. There are many complex method calls for vector layers, and so many of these do deserve to be introduced only late on – but introducing a subset of vector capabilities much earlier in the book would have been of benefit.

There are several typos and minor misspellings in the book, including in a couple of code examples, detracted slightly from the clarity of the book.

The OpenLayers 2.10 Beginners Guide is fantastic as a reference – it goes into great detail and is so very useful for advanced users of the OpenLayers API. But it forsakes smoothing the OpenLayers learning curve in favour of a solid ground-working of the detail – great if this is your career, not so great if you just want to download OpenLayers and create a simple map. If you are prepared to spend the time with the detail, then you will emerge an OpenLayers expert!

The book’s accompanying website includes Chapter 9 as a sample. You can also buy the book – OpenLayers 2.10 Beginner’s Guide – from Amazon.

Mashups OpenLayers

Heatmaps are Simple with HTML 5 and Canvas

Cross-posted from my orienteering blog.

As a Saturday-lunchtime project, I have created a heatmap of where the 2700-odd geolocated orienteering races have been held in Great Britain in the last two years.

The heatmap quickly shows clusters around the main urban areas, where the population sizes supply participation for many local events being put on. Another major bright-spot is the Lake District extract on the right – which contains a large amount of high quality terrain for events. Other areas, such as the Cotswolds NW of Oxford, seem to be somewhat underused.

If you have a browser than can handle the HTML5 Canvas tag (i.e. not Internet Explorer!) you can view the heatmap here. Zoom into your local town or city to see if events have been held there – when zooming in, you’ll need to adjust the two sliders most of the way to the right, so that individual events show up. With the individual settings, a single, isolated event will have very little impact on the heatmap.

The heatmap was possible thanks to the excellent Heatmap library produced for OpenLayers by Bjoern Hoehrmann. The map is powered by OpenLayers, with an OpenStreetMap basemap. I’ve used a custom colour ramp, based on one supplied by Colorbrewer. The custom map adornments are supplied by MapBox.

Creating a heatmap like this is very easily, with just a few lines of Javascript needed to add objects in. The Heatmap library does the rest. See Bjoern’s example for the documentation.

Bike Share Data Graphics London Mashups OpenLayers

The First Million London Bike Share Journeys

Thanks to a FOI request from Adrian Short, Transport for London have recently released to their developers area details of 1.4 million bike share journeys. The data is believed to include all the journeys between 30 July 2010 and 3 November 2010, except those starting between midnight and 6am.

I’ve created a map which visualises these journeys – select a docking station and a time, and it will show the journeys that start/end at that dock, depending on the options chosen.

You can see the map here. On launching the site, an initial docking station – one outside Waterloo station – is selected, and an “interesting” timeframe is chosen – the morning of 4 October, which was a day impacted by a tube strike.

Heavy usage along the Broad Walk through Kensington Gardens, particularly at weekends:

The predominant flows from a docking station near King’s Cross station, in weekday mornings, are outwards (red lines), particularly south towards the river. Only a few inbound journeys happen (blue lines):

The reverse is true in weekday evenings, as commuters head back to the stations:

The map bears a resemblance to my live Barclays Cycle Hire scheme status map, as I’m reusing a lot of the same code and graphics.

Mashups OpenLayers OpenStreetMap

More Circles on a Map – Orienteering Fixtures

Five years ago, I created a mashup of forthcoming orienteering fixtures in Great Britain, as listed by the sport’s national governing body, British Orienteering, on its website. It was based on the Google Maps v2 API, and a regular scraping of the HTML on their website, and was a set of pins on a map, coloured by the number of weeks to the event. On clicking a pin, you got a popup balloon with details of the event, and a link to the organising club’s website. A postcode locator, based on data from the NPEMap project, was added, so you could focus on events in your local area. You could also filter out far away events.

A couple of years later, British Orienteering’s web developers added their own map to their website – Google Maps v2 API based, with pins coloured by the number of weeks to the event, and a popup balloon, a postcode search and distance filter etc etc… The Unique Selling Point of my fixtures map was lost.

So, when a rewrite of British Orienteering’s website just before Christmas broke my map, I took the opportunity to rewrite it, as a vacation project, using the technologies I’ve been using a lot in 2010 – namely OpenLayers, OpenStreetMap, OS OpenData and coloured vector circles. The map is bigger, brighter, and hopefully more useable than the official map and my previous version.

You can see the new map here – with a mass of dots representing forthcoming fixtures, and circles surrounding the “home” postcode, backed by OpenStreetMap, with the postcode locator based on CodePoint Open from Ordnance Survey OpenData. Only the locator uses a database, the rest of the webpage is constructed on-the-fly from a webpage regularly copied from the British Orienteering website.

Not Scarborough…

The map remains subject to the quality of the data entered on the corresponding list – there is some limited tidying up of the data, but it’s difficult to correct grid references that result in events being in the sea – there’s currently one in the Irish Sea, as the event registrant entered “GR” as the grid reference letters, and this just so happens to be the location of the GR myriad. There is still work to be done on my new map, such as spotting obvious errors like this, guessing locations where a grid reference isn’t supplied, and perhaps including Northern Ireland’s events.

Incidentally, my original orienteering web map, which inspired my fixtures map, was one showing orienteering maps, it was written way back in August 2004, using a Flash mapping package by Map Bureau, with dots superimposed on top of a map pinched from Wikipedia. We’ve come a long way.

Data Graphics Mashups OpenLayers

The Political Colour of Great Britain

Following on my UK General Elections 2010 Swings map, where circles represent each constituency, with the sizes and colour describing the metrics, I have used a technique that James has been studying, to combine the vote proportions together to produce a single coloured dot for each constituency. The more blue the dot, the higher the proportion of the vote was Conservative. Similarly, red for Labour and Green for the Lib Dems and the other parties and independents.

A purple constituency represents a Labour/Conservative marginal, as blue+red = purple. There are many of these in the Midlands. Similarly, orange areas indicate likely Labour/Lib Dem (or SNP/PC etc) marginals, such as in South Wales, and turquoise areas indicate Conservative/Lib Dem (& other) margins, there are many of these in SW England. Grey dots show three-way marginals, e.g. Hampstead in London.

Because I am using just three colours, to represent three political groupings, the visualisation does not show the variation in results between the Liberal Democrats and the nationalist parties – the SNP and PC in Scotland and Wales respectively.

Some interesting patterns are revealed – the ring of blue/purple around the red/orange centres of London and Birmingham – with no such corresponding ring around Manchester or Newcastle. Scotland’s lack of blue. The straightforward Labour/Conservative split in NW England. East London isn’t quite as safe-Labour as you might think – with the exception of East Ham standing out in bright red.

The benefit of this visualisation is that every vote is included in it – on a regular election map, if one party just fails to win, then an election map won’t show them at all on it. Here, every vote influences the colour of the map. Each circle represents roughly the same number of people – the populations of constituencies are fairly even, with some notable exceptions such as the Isle of Wight (very populated) and the Scottish Islands (very few people.)

You can see the colour map by going to the election visualisation and choosing “Constituency Colour” from the “Other graphs” drop-down. James has produced a regular choropleth map version, which shows the green (SNP/LD) of northern Scotland and blue (Conservative) of southern England strikingly well.