Hexmaps – the old fashioned (stupid) way

Some time ago, a colleague had been impressed by the Guardian’s hexmaps of the 2015 general election. He issued a challenge to try and recreate the basic premise using whatever software and techniques we had available and some uncontraversial data (population and deprivation data).

The basic idea of this is that:

  • constituencies are given a block of hexagons, the amount of which is proportionate to their population;
  • those hexablocks are supposed to look like the constituencies themselves
  • the hexablocks are then stuck together and ‘tessalate’ with eachother
  • the shared borders of the constiuency should be reflected by it’s hexablock
  • the overall aggregation of these hexablocks should look recognisably like the shape of it’s parent (in the Guardian’s case, the UK; in my case, Wakefield district)

Weighting the number of hexagons per LSOA is easy enough.  Designing hexagonal approximations would be time-consuming and I didn’t have the free time at work to do this.

So what if we abandoned the population weighting idea and see if we can ‘fit’ LSOAs to a single hexagon and still get a recognisable overall shape at the end of it?

As I’d been working on LSOA mapping, I opted to work at that level of granularity.  Native support for low levels of UK geographical units is not great in Tableau.  I’d gotten into the habit of creating my own shape files (using a Geocode, PointID and PolyID method) and joining the shapefile to a geocoded dataset.  Plenty of bloat to bog things down!

In comparison, a hexagon only has six points (seven if you include a return to origin)… this should be easy!  At the time, hexbins hadn’t been introduced to Tableau (and I still haven’t made fantastic use of them), so I went with the method described above.

What’s less easy is to programmatically assign a hexagon and its relative position.  It’s even more difficult to do this while reflecting shared borders (hexagon has six, LSOAs have many more… wish I’d thought about that more before I started), and somehow make all this fit together in a way that vaguely resembles the overall picture and sub-district blocks.

Attempts at automating this weren’t successful (why would they be???) and it came down to Eyeball Mk1 and copious geometric reading.

Anyway… the result:

In certain areas, the representation is successful.  I like how the majority of the “hexablocked” sub-district areas look similar to their polygonal originals (Rural is an exception due to the size of some of the LSOAs in the original).  In other ways, the representation fails due to its poor adherence to shared borders.

Short answer is, don’t bother doing it this way.  It’s rubbish.

Bet you’re glad you read this article now, aren’t you?

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Leave a reply by filling in your details below, or connect automatically with social media:




Your email address will not be published. Required fields are marked *