The purpose of map generalisation is to represent spatial data in a way that makes it possible to effectively view the data at scales smaller than that for which it was originally intended. In the case of the Ordnance Survey’s MasterMap product you have data at an incredibly fine level of spatial resolution, which is ideally viewed at a scale of approximately 1:1000 give or take 500. When you are reliant on MasterMap, but need to create map of a wider area you are faced with the challenge of generalising data so that it can be ably understood, this means reducing the complexity of components of the spatial data, for instance smoothing wiggly lines, or transforming complicated polygons into simpler ones, as well as aggregating an abundance of small features into larger ones. Such interventions are necessary because it is increasingly difficult to resolve fine detail as map scale decreases, leading to complex shapes appearing messy and disordered when visualised at smaller scales that that which they were intended for. The actual scale of a map gives us an insight into the types of objects that it is possible to resolve at different scales; at a scale of 1:1000 a physical distance of 100cm represents 1km, at 1:10000 and 1:100000 the distance of 1km is covered by 10cm and 1cm respectively. If we conservatively suggest that we can resolve features that are 5mm across, then at 1:1000; 1:10000; and 1:100000, the smallest real world objects that can be represented are 5m,  50m, and 500m respectively. These distances equate to real world objects such as large cars and trucks (c. 5m in length), Olympic-sized swimming pools and office buildings (50m), whilst a distance of 500m is twice the span of Tower Bridge. Evidently, there are significant difference in what constitutes appropriate detail at each of these scales.

I’ve been dealing with one such problem recently, involving the representation of MasterMap building outlines at a scale of 1:10000, somewhat smaller that the 1:1000ish that it was intended for. In order to create an effective map I did needed to generalise the building outlines, however, unfortunately I don’t have access to ESRI’s ArcGIS “simplify building” tool due to licensing restrictions, so I had to come up with another solution. Initially I attempted the classic line generalisation procedure – the Douglas-Peucker algorithm, which simplifies by reducing the number of points in a curve subject to some pre-specified threshold value. However, buildings are strong geometric shapes, often rectangular and orthogonal, so an algorithm such as the Douglas-Peucker can have the effect of disrupting the geometric regularity of building outlines, removing corners etc. What is required is a polygon simplification algorithm that preserves orthogonality, however I couldn’t find anything that did this whilst being accessible, instead I had to come up with a procedure to approximate a generalisation of the building polygons by another methods. The image below reveals the result, which I think is successful enough to use.

In the image above, A is the raw data, and B is the generalised data. I experimented with a few approaches, but the one I assessed as being the best was to position an enclosing rectangle around each building polygon, so that the area of the enclosing rectangle was minimised, and subsequently buffer the result to close any small gaps, choosing to dissolve as well in order to further reduce the complexity. Subsequently I removed the particularly small buildings. The generalisation is more in evidence in the image below, in which A and B are the same as before.

I am reasonably pleased with the result, which was achieved after a little trial and error. Whilst technical approaches to orthogonal simplification exist I can’t imagine them being much more effective at this scale, although perhaps at smaller scales they would be more appropriate as they can create meaningful aggregations of building based upon characteristics such as nearest-neighbour distance.

I work a lot with flows and spatial interactions, one thing that I’ve wanted to do for a while is compute a mean flow direction surface. Unfortunately, arithmetic means don’t work for angular data, this is because it cannot account for the circular nature of the distribution of angular measurements. For instance the angles 5 degrees and 355 degrees are seperated only by 10 degrees, but their arithmetic mean is 180 degrees -w ay off, it should be 0 degrees!

Luckily, Brunsdon and Charlton have published on this very subject, so I took it upon myself to implement a weighted circular mean function in Python. The key obstacle was learning about complex numbers, about which, up until this point, I had no idea about at all!

The first thing to do is calculate the angle between a set of candidate points (such as people) and a set of services (such as Medical Centres). This is simple enough to do using, and would look something like:

import math

math.atan2((y2-y1),(x2-x1))

In which the pair (x1,y1) is the location of the candidate point, and (x2,y2) the location of the allocated service for that candidate point. The line linking these two points defines a flow from a candidate point, to a servcie and vice versa.

Having calculated all of the angles, I used ArcGIS to create an output grid, at the extent of the candidate points, using the “fishnet” function which creates a vector grid of prespecified dimensions.

The beauty of Brunsdon and Charlton’s method is that it uses a local method of approximation, this means that for each cell in the output grid, a mean direction can be calculated based upon the values of nearby points, applying a weighting allows for more distance points to have less of an effect on the mean direction.

Firstly, I read all the candidate points into a KDTree structure, this allows me to search for local points, at the same time I also create an array of the angles for those candidate points.

from scipy.spatial import cKDTree
import numpy as np

tree = cKDTree(treepoints)
res, idx = tree.query(testpoint,300000,0,2,100)
res = res[0][np.where(res[0] < np.Inf)[0]]
idx = idx[0][:len(res)]

The tree takes a numpy array of coordinate pairs, and the query method returns an array of distances to points (res) and their index value in the original array of coordinates (idx). The testpoint is a cell in the vector grid; 300000 is the k-number of nearest neighbours to find, here I have simply set it arbitrarily high in the context of my dataset; 0 is for approximate nearest neighbours, here I’ve specified exact; 2 indicates the use of euclidian distance; and 100 is the threshold, neighbours won’t be returned if they are further than 100 metres away. The penultimate line simply returns an array that is shortened to just those values which are less than 100m away (i.e. less than infinity) – points over 100m away are returned as value Inf.

The next step is to actually compute the mean direction, this requires a special approach using complex numbers however. Brunsdon and Charlton show that a direction can be stated as a complex number z in which z = exp(iθ) this is effectively: z = cos(θ) + i sin(θ)  in which i is an imaginary number. We can restate our directions in Python using:

import cmath

thetas = angles[idx]
cThetas = []
for i in xrange(0,len(thetas)):
    cThetas.append(complex(np.cos(thetas[i]),np.sin(thetas[i])))
cThetas = np.array(cThetas)

Here, the complex function allows the complex number representing an angle to be stored in a list, which I convert (lazily) to a numpy array. The first term, thetas, is using the idx array from the cKDTree to cleverly index the relevant angle records from the angles array which stores all the angle values in the order of entries for the cKDTree.

Next a temporary variable is created which calculates the mean direction:

temp = np.sum(cThetas)/np.absolute(np.sum(cThetas))
MeanDir = np.angle(temp, deg = True)

The mean direction is given by the argument (Arg) of the resultant complex number, Python implements this with the np.angle function, where deg = True returns the angle in degrees, and False in radians.

So far this is the unweighted mean, aggregating directional observations within a 100m disk (see also: uniform disk smoothing). To introduce weighting we must first define a weighting scheme, I’ve used the one suggested by Brunsdon and Charlton, which is Gaussian, and might look at bit like this:

def gaussW(dists,band):
    out = np.zeros(dists.shape)
    for i in xrange(0,len(out)):
        temp = np.power(dists[i],2)/(2.0*np.power(float(band),2))
        out[i] = np.exp(-1.0 * temp)
    return out

weight = gaussW(res,100)

Quite simply, I pass the distance array res to the gaussW function and it gives me back an array of weights for that ordering of distances. Using this I can redo the mean direction thus:

temp = np.sum(weight*cThetas)/np.absolute(np.sum(weight*cThetas))
MeanDir = np.angle(temp, deg = True)

There you have it! Attached is the script I used. Obviously, Brunsdon and Charlton implement a variance and a couple of visualisation devices, but these should be simple enough to implement now!

I created an output for flows of patients to GPs in Southwark, visualised using one of ESRI’s circular/direction colour ramps from colour ramp pack 2. Not sure how best to visualise the legend at this point though. NB. 90 is north, -90 is South, 0/-0 is East and 180/-180 is West. The map is visualised to show the 4 cardinal directions, but the output is in fact continuous.

My example script is here. Note that I am using dbfpy to read and write to shapefile DBF tables directly.

The intent of this post is not simply to uncover where the highest density of people belonging to a particular ethnic group are, but rather to use the ‘location quotient’ (LQ) technique to compare the ethnic density in any one area to the overall ethnic density in Southwark, thus providing a relative insight into where the density of particular groups is more, less or as dense as expected.

Location Quotients tend to work with areal units, characterising different areas subject to a larger region and providing a basic insight into where functions are clustered. Because the Southwark patient register data is address geocoded, we would be losing some spatial information if we choose to aggregate the data, not to mention the question of which areal aggregation is best. More info on how to create location quotients here.

A Location Quotient has 3 possible interpretations; if it is around 1 then the ethnic population in that area is at the level we would expect given what we observe nationally. If the LQ is less than 1 then that area has a lesser population of a particular ethnic group that what we would expect based upon national figures. Finally, in the LQ value is over 1 this suggests a concentration of the ethnic group in the area which is greater than we would expect given nationally observed levels. A LQ is quite simply a rate-ratio.

Instead of the standrad areal approach, the maps here use a density estimation approach in which disaggregate point data is transformed into a representation of the continuous density function of the point distribution. The LQ can then be computed for each cell based on the density of that cell with respect to the total density of the surface. This creates a smoothed LQ surface which is readily interpretable in the same manner as above. The Kernel Density Estimation used to create the ethnic and total population density surfaces should be parameterised in the same way; these examples use a 250m bandwidth and a 25m cells size, which is largely empirically redundant, based on the input dataset’s spatial resolution, but creates a more aesthetically appealing mapped representation. Naturally, the procedure works well for clustered data, in Southwarks case for the African and Muslim groups.

Using the excellent SANET extension for ArcGIS 9.3 I was able to take some of my data for Southwark that I had geocoded to address level, and estimate the population density using the OS Mastermap ITN product. The procedure is essentially a Kernel Density Estimation that takes place on a given network rather than across 2D space, this effectively controls for the effect of spatial structure, such as urban form, of which the data relates to residential locations. The estimation is made for c.300,000 people in Southwark on a network with around 30,000 road segments so it is to be expected that the calculation takes several hours to run. The KDE process is parameterised in much the same way as the straightforward density estimation procedures in the ARCGIS Spatial Analyst toolboxes, bandwidth and cell size are specified. In this case though cell size relates to the length of segments into which the network has to be cut in order to represent the output. Additionally, SANET allows you to control how you handle road intersections, either by using a continuous or discontinuous approach to the bifurcation, i arbitrarily chose the continuous approach, essentially meaning that the density estimation can turn corners. A straightforward representation can be made in 2D as below.

The interesting aspect to this image that is obscured in 2D smoothed representations is the relative usage of different streets, clearly visible are the residential streets as distinct from the more commercial area on Southwark’s Bankside, and along major roads, and the effect of open space and water features in reducing network density (i.e. if only one side of a road has residences on it). I’ve attempted to explore this further by using ArcScene’s 3D visualisation capabilities, but the complexity of the data make this an incredibly arduous process. The result i was able to obtain outside of ArcScene simply crashing are below.

In this example, Southwark is presented in a kind of 2.5D perspective in which the streets have been extruded so that their height represents the population density at that point. I’ve included some contextual elements, the Thames, and parks, wooded areas, and other water features. Whether or not this image is in anyway an improvement over a simple 2D representation is open to debate, but the selections below do present an interesting cross section of the data.

I liked Ben Hennig’s population cartogram of the UK under snow, but I thought it could perhaps show something a little more serious than simply where the people are. To do this I went to the UK Census 2001 (I know, an old data source, but the only thing I was aware of that could help me) and downloaded a dataset of counts by area (LSOA) of households without central heating. Using these counts as a base population, I created the cartogram below.

Whilst very similar to Ben’s cartogram, there are some differences, notably Scotland is not as prominant as in Ben’s. Perhaps the higher frequency of harsh winters in Scotland has made central heating a necessity. This also seems to be true in the far north of England. Likewise, Wales shrinks away in all areas aside from Cardiff which is a notable bulge of people without central heating. It is clear, however, that the people most effected by a lack of central heating are those that live in the south and middle of England in large population centres such as London – perhaps complacency to cold weather, plus a stock of substandard housing, or high levels of deprivation have caused this. Needless to say, it is likely to be these people that disproportionately feel the cold this winter.

A subtitle to this post might also be: Are we all being mislead by the New York Times? In stating this I am referring to the recent maps released by the New York Times looking at ethnic distributions from the US Census Bureau’s American Community Survey.

The most immediate thing we can learn about this project is that it is a spatial ecology, that is, an examination of the spatial patterning of a phenomena, here it’s ethnicity, at a given level of spatial aggregation, in this case “every city, every block”.This much is apparent both when you drag the mouse across the geography of America and the Census areas are highlighted, as well as when you zoom in, and you navigate from the Census tract level to the Census block level, a finer scale areal aggregation.

On the one hand, what has been achieved in this map is tremendous, and the use of dot density mapping allows for a singular look at multivariate data. The sheer level of residential segregation in the US also makes the dot density approach a very persuasive cartographic representation. However, first let us consider what the dot density approach is.

First and foremost, it is important to note that the dot density approach does not represent the real-world locations of individuals, far from it, dot density maps are simply another way of drawing a choropleth map. Choropleth maps show data aggregated into predefined areas (e.g. Census Blocks) and thematically colour these areas based upon some classification of the share of the mapped phenomenon that each area has. In a dot density map, each dot represents an observation, or number of observations, that occur within an area, each dot is then randomly positioned within that area. This means that phenomena do not strictly occur where they were sampled, which can (in increasingly large areas) lead to increasingly large uncertainties and misrepresentations. A higher number of dots within an area indicates a greater number of observations, with density described by the relative spacing of the dots in each area: smaller spacings indicate higher density.

Herein lies the difficulty – most ways of dividing up territory, and census delineations in particular, use a space covering approach. This continuous, spatially extensive way of dividing up land means that all land areas, even areas that have no people living in them, are potentially subject to the random placement of a dot, in the image below this is shown by the placement of dots in water bodies. Dot density can be logically unsound, particularly when two adjoining census blocks have significantly different population densities, shown by the representation of apparently hard ‘edges’ at areal boundaries as in the image below.

One solution that could work to mitigate the issue of representing areal data using dot density maps would be to apply dasymetric mapping. The dasymetric mapping technique is a method of reallocating a population recorded on a continuous areal basis to one which is a better representation of where people actually are. To do this, more information than simply population counts are usually required, such as landuse classifications, or delineations of developed area. In reallocating population counts from an areal unit created on a continuous basis, to one which aims at a more realistic placing of people in space, the volume of people per area is preserved, this means that you will never end up with more or less people than you started with. David Martin has, in the UK, been responsible for some notable dasysemtric outputs with regard to the UK Census, and provides a software tool, SurfaceBuilder, here.

The overarching goal of dasymetric mapping is to circumnavigate the ecological fallacy, which manifests itself in issues I have suggested exist in the dot density mapping of the US. Whilst dasymetric mapping would resolve some issues, dot density would still be subject to some mislocation of data, which largely stems from the conflicting ontology of representing an areal-based data, such as a population count by census area, as a series of points within that area; it is too easy for the viewer to interpret the points as having some level of significance above and beyond the areal container within which they sit. Therefore it is useful that the New York Times mapping also provides an option to look solely at the thematic choropleths classified by colouring the areas for each individual ethnicity. In this representation the viewer cannot confer the same kind of absolute interpretation upon the meaning or location of points, as they may do for dot density representations.

Recently, all and sundry had the chance to rummage through LSE Geography’s map library and liberate any maps of their choosing. Naturally some got over excited (cf. James Cheshire) and took numerous maps of all sorts. I was slightly more selective, and whilst being mostly on the look out for maps that represented social areas (cf. Booth Maps) I did find one particularly interesting map.

The map is by Carl Steinitz, from a time when he was at MIT Department of City and Regional Planning, it appears to be made using Symap. The map is entitled “The Principle Local Activity of a Place”. I think this title is both fascinating, and in terms of the development of spatial analysis quite telling. First however, some background.

Carl Steinitz is a Professor at Harvard Graduate School of Design, and has been a regular visitor at CASA for as long as I’ve been at UCL. He trained as an architect and planner, but became known as an early evangelist of Geographic Information Systems (GIS), his ongoing work concerns the design of environments, often urban, and the use of GIS to describe possible development trajectories. I respect him most for his impassioned stance against needless 3d visualisations, particularly if those visualisation have a musical backing.

Symap, aka synergraphic mapping system, is one of the first software packages that could create outputs that actively resemble current desktop GIS outputs. It was developed in the mid-1960s and carried with it a distinctive style of using ascii characters in order to draw map elements. Andrew Crooks has a couple of interesting examples and some background on his blog.

Now the map in question here doesn’t seem to have a date, which is a shame, and it does not give a specific location to the mapped area, although given that the map was made in MIT it becomes apparent that the area in question is Boston, Massachusetts with the Charles River Basin in the north of the map, and Boston Harbour to the east. The legend denotes different kinds of ‘principle local activity’, using different ascii characters to create a colour graduation. Unfortunately some of the particular legend categories are lost due to the low quality of reproduction on this particular map, nevertheless we see that Boston exhibits a distinct spatial patterning with respect to principle activity. This kind of map is not unusual, land use mapping is still an actively researched area that continues to generate copious debate – what interests me actually seems rather minor, it is the description of the map as presenting “The principle local activity of a place” (emphasis added). Initially I wondered whether this phrasing was simply standard boilerplate, but a google search couldn’t find the exact phrase, or variations on it, anywhere else on the web (which is not to say that it isn’t standard, simply that it doesn’t exist on google, I imagine it would have appeared had it been related to statistical reporting at some time or another). What it may mean then is that it marks the way in which the author Carl Steinitz saw the representation at the time: as a representation of the local activity of a place.

This is interesting, first it is easy to assume that by place he meant ‘Boston’, Boston is after all a place. However, scale has a very interesting role to play in how we think about place: we can conceive of many places within Boston centred around communities of all kinds, these places will be at least partially defined by the ‘local activities’ that occur there. As such the gridded representation of this map hints at the possibility of lots of places within Boston each with particular autobiographies, and each engaging people in different ways and offering different opportunities. Subsequent advances in GIS formalised the discourse of ‘space’ and spatial analysis, after all GIS does fundamentally hinge on the euclidian system of representation, and as such the vast, expansive idea of space sits much better than a nuanced, specific, local concept such as place. It would be easy to disregard Steinitz’s map and say that of course it simply assesses land use in Boston by a grid of systematically defined areas, but that designation of ‘place’ – purposeful or not- adds another layer of interpretation. Fundamentally it gives a different sense to what it is being represented here.

Here is a quick confirmation that you can use Python to draw very detailed maps; using the previously specified method I was unable to get python to draw all UK OAs due to their great number (c.220,000) and high complexity (c.50,000,000) vertices. Additionally I was unable to use the generalised OA boundaries for the UK from UKBorders as they contain topological errors that the shapefile reader cannot deal with. ArcGIS is obviously a bit clever in how it handles bad topologies. So I extracted all the vertices and fed them into shapely polygons, and visualised them in the same way, but without reading shapefiles directly into python and was able to output this:

This method has had an impact on the speed of computation as it can take roughly 25 minutes to output this map. The map looks pretty good, aside from a slightly odd polygon in the Bristol channel. Nevertheless, coupled with the operations that shapely, and other geo-libraries, can do this si increasing indication of the maturity of GIS in a variety of platforms. Oh, and it’s all free!

Thanks to Sean Gillies for commenting on my last post, he put me onto a couple of Python packages that he’s been involved in creating that allow you to do some really excellent geospatial things. The shapely package is a great implementation of a lot of spatial analyses that you can do on projected (i.e. flattened) datasets, including topological operations and a full set of object types. The descartes package allows better integration of matplotlib with spatial data, particularly in terms of not having to use the “fill” plotting function repeatedly, but creating a more efficient set of “patches” which can then be added to the figure plot. The overal impression I got from descartes is that it wasn’t spectacularly different from the method detailed in my previous post, but it gives you more control and stability over the map plotting process; whereas using raw matplotlib you are inclined to hope that the map outputs correctly (it all seems a bit up to chance), using descartes you have a more robust and easily manipulable output.

In order to test this I rewrote my previous thematic map script to: firstly convert the shapefile geometries into shapely polygons, and secondly to pass those shapely polygons to descartes and draw a map plot using descartes-matplotlib. The only slightly odd piece of functionality that I found was that you can’t pass the shapely polygon object a list of shapely points in order to create the polygon, rather you have to pass a list of x,y tuples – much less satisfying!

Nonetheless, the changes were easy to implement, and with the previous script as given basically include:

from shapely.geometry import Polygon

points = []
for i in range(0,number of points in shapefile):
 tempx = float(x coord of point in shapefile polygon)
 tempy = float(y coord of point in shapefile polygon)

 points.append((tempx,tempy))
polygon = Polygon(points)

The above method creates a simple polygon without holes, shapely can accomodate this is need be though. Having created the shapely polygons, all that remains is to create a patch.

from descartes import PolygonPatch

patch = PolygonPatch(polygon, plus colour and line considerations)

Then you simply add the patch to the matplotlib figure you have already created so:

from matplotlib import pyplot

fig = pyplot.figure(1, figsize = [10,10], dpi = 300)   #create 10x10 figure
ax = fig.addsubplot(111)    #Add the map frame (single plot)

# here you create all the polygons and patches

ax.addpatch(patch)   # simply add the patch to the subplot
# set plot vars
ax.set_xlim(get xmin and xmax values from data)
ax.set_ylim(get ymin and ymax values from data)
ax.set_aspect(1)

pyplot.show()

Using these basics I was able to create a basic OAC map using Welsh OAs as an example:

I though I would explore the possibility of creating thematic maps using Python, this post documents my initial attempt. The output is hence rather basic, but encouraging. The primary reason that I wanted to test the mapping potential of python is to allow for some basic automated map production in order to quickly visually assess the geographical patterns contained within large data sets. This is something that I am at a loss to do in ESRI’s ArcGIS, although that might change in ArcGIS 10. For fans of R I know it can be done there, however R is too tricky for me! My colleague James Cheshire explains the method in R here.

The first hurdle in map making is getting the data in, for this I used the shapefile reader that Zachary Forest Johnson put together for his excellent blog ‘IndieMaps.com‘. This allowed me read in any of my masses of pre-existing Shapefile format datafiles, and indeed use the python scripting functionality in ArcGIS to perform spatial operations and then output a map quickly and without the hassle of dealing with ArcGIS layouts.

Once you have download the shapefile reader, it is easily implemented using:

import shpUtils   #imports the shapefile reader
#Load a shapefile into an object called shpRecords
shpRecords = shpUtils.loadShapefile('\filename.shp')

This is undoubtedly simple, what you then have is a (slightly) complex object which contians all of the shapefile data nested as lists and dictionaries. In order to get my head round this I spent some time investigating it, a standard shapefile that contains areal geographies (i.e. UK Output Areas) will have a similar set up to this:

• The first list (shpRecords[i]) records the number of complete geometries, this corresponds to the number of rows in the attribute table. Thus a single polygon has 1 row in the attribute table and 1 list (list index 0) in Python.
• The second dictionary (shpRecords[i]['key']) records two branches, reporting either the ‘dbf_data’ from the attribute table, or the ‘shp_data’ from the .shp file describing the underlying geometry.
• Choosing the ‘dbf_data’ key (shpRecords[i]['dbf_data']) allows you to see the attributes recorded column-by-column for each row (and hence each geometry) in the attribute table. Thus shpRecords[i]['dbf_data']['name'] will return the attribute value for the field ‘name’ for the ith geometry in the shapefile.
• Choosing the ‘shp_data’ key (shpRecords[i]['shp_data']) allows you to access the various components of the shapefile’s geometry. In the case of a polyline/polygon you get dictionary items ‘ymax’, ‘ymin’, ‘xmax’, ‘xmin’, ‘numpoints’, ‘numparts’ and ‘parts’. Clearly the first 6 items are properties of the ith geometry you are querying, so it allows you to form a bounding box, get the number of vertices in the line/polygon, and draw separate lines/polygons if the shapefile is setup to have spatially discontinuous shapes for each row.
• The thing we are most interested in is the ‘parts’ dictionary key, as this contains all the coordinates for the particular geometry being considered, this is accessed as: shpRecords[i]['shp_data']['parts']. The next list (shpRecords[i]['shp_data']['parts'][j]) thus allows you to distinguish between parts in a multipart file. i.e. the jth part of the ith geometry.
• Having come this far, one final dictionary allows us to see the coordinates themselves, this dictionary simply offers us ‘x’ or ‘y’. Thus finding the x-coordinate of the ith geometry and jth part is accessed by: shpRecords[i]['shp_data']['parts'][j]['x'] – simple!

I have been using matplotlib – a python library for scientific visualisation a lot recent, and have found it a very simple and powerful resource, so I thought I’d see if it could be made to draw a map.

Firstly import the pyplot element which does all the figure drawing:

import matplotlib.pyplot as plt

Now lets use the “fill” component of matplotlib to draw all the geometries in a shapefile – my shapefile is Output Areas in Southwark. Firstly we need to loop through each geometry, and then draw a polygon using all the points contained within each geometry. I omitted a loop for multipart geometries as my shapefile has none, however this would be very easy if the data did have multiple parts- simply add a loop in the middle!

for i in range(0,len(shpRecords)):
 # x and y are empty lists to be populated with the coords of each geometry.
 x = []
 y = []
 for j in range(0,len(shpRecords[i]['shp_data']['parts'][0]['points'])):
  # This is the number of vertices in the ith geometry.
  # The parts list is [0] as it is singlepart.

  # get x and y coordinates.
  tempx = float(shpRecords[i]['shp_data']['parts'][0]['points'][j]['x'])
  tempy = float(shpRecords[i]['shp_data']['parts'][0]['points'][j]['y'])
  x.append(tempx)
  y.append(tempy) # Populate the lists  

 # Creates a polygon in matplotlib for each geometry in the shapefile
 plt.fill(x,y)

plt.axis('equal')
# This sets the x and y axes as equal intervals.
# NB this script will only work for projected data, for geographical
# coordinate systems get ready to do some maths  

plt.show() # Draws the map!

This is the simplest form of the script, it will simply draw the shapefile with each area filled a random colour. This is not that useful, but it is easy to create a thematic maps of categorical data, so let investigate a way of doing that. I’ve got data for the Output Area Classification, which is a clustering of areas by social characteristics, I know that there are 7 supergroups in the classification, named numerically, so before all the processing of the shapefile I can create a dictionary of colour choices for each group. I’m using hexadecimal colours that I got from Cynthia Brewer’s website for a ‘qualitative’ 7 class classification. The dictionary looks like this:

oacSGroups = {'1':'#A6761D','2':'#E6AB02','3':'#66A61E','4':'#E7298A',\
'5':'#7570B3','6':'#D95F02','7': '#1B9E77'}

Thus the key ’1′ returns the associated hex colour, this can be linked to the ‘dbf_data’ key in the shapefile. In the plt.fill() component I simply have to specify the colour choice, thus we alter the line in the above script to read:

plt.fill(x,y,fc = oacSGroups[str(int(shpRecords[i]['dbf_data']['supergroup']))]\
,ec = '0.7',lw=0.1)

‘fc’ is the ‘foreground colour’ we are asking python to make the colour equal to the value in the oacSGroups dictionary where the key is the value contained in the attribute table for the ith row in the ‘supergroup’ field. Thus if the ith row had a ‘supergroup’ value of ’7′ that foreground colour would be set to ‘#1B9E77′. ‘ec’ is ‘edge colour’ and ‘lw’ is linewidth, here I have set the values to display fine, light grey lines.

Finally, as basic a map as this will turn out to be, we wouldn’t be anywhere without a legend. The following a a very basic, wholy manual way to add a legend to the map:

p1 = plt.Rectangle((0, 0), 1, 1, fc="#A6761D")
p2 = plt.Rectangle((0, 0), 1, 1, fc="#E6AB02")
p3 = plt.Rectangle((0, 0), 1, 1, fc="#66A61E")
p4 = plt.Rectangle((0, 0), 1, 1, fc="#E7298A")
p5 = plt.Rectangle((0, 0), 1, 1, fc="#7570B3")
p6 = plt.Rectangle((0, 0), 1, 1, fc="#D95F02")
p7 = plt.Rectangle((0, 0), 1, 1, fc="#1B9E77")

plt.legend([p1,p2,p3,p4,p5,p6,p7], ["Super Group 1","Super Group 2",\
"Super Group 3","Super Group 4","Super Group 5","Super Group 6","Super Group 7"], loc = 4)

This simply creates 7 rectangular plots which don’t appear on the plotted output, but instead are passed to the legend creator, each rectangle has the appropriate colour to match the mapped representation, and a label, shown int he legend as two ordered lists. The ‘loc’ tag allows the setting of where the legend will appear, 4 denotes the bottom right corner. the tag ‘title’ allows you to add a title to the legend as a string.

An example output looks something like this:

This took a couple of seconds to produce, and accounts for 846 individual geometries, which actually have quite a number of vertices.

I’ll update the blog should I find new methods to visualise spatial data in python.