We look at using the Tabulate Intersections tool to do an off-beat spatial join.
Postgrad Lucia had a problem, a spatial problem, to be more exact. As part of her MLA she’s doing some research on whether shade is equitably provided in Christchurch’s parks, i.e., do wealthy neighbourhoods have more access to shade than poorer neighbourhoods. Her plan is to do a “shade audit” of a number of parks and relate that to socio-economic levels. Sounds like a pretty worthwhile study. As part of this, Lucia had to select a set of parks that fit two main criteria:
- In either the highest or lowest areas of socio-economic status, and
- the areas surrounding each park (known as access areas) need to be at the same socio-economic level as the park.
These are mainly spatial criteria so GIS has something to offer (Ed. it sure seems like everything is a spatial nail to your GIS hammer…). Let’s start with the parks – Lucia was able to get a shapefile from the CCC with all the parks (822 in total) broken down into three categories: garden and heritage parks, local/community parks and sports parks:
Great start – we can think about socio-economics next. Doing this well is a challenge. Thankfully, a lot of effort has been put into this and we’ve got two options to choose from: the NZ Deprivation Index and the Indices of Multiple Deprivation (here’s a comparison between the two). For this project we’ve been working with the IMD. These data build on information contained in the 2018 census and distils this down to an index value of socio-economic deprivation. Values range from 1 (low deprivation) to 10 (high deprivation). They’re not the same as Ministry of Education deciles but are somewhat inversely related. The values give us an indication of the socio-economic status within a given area based on seven different factors as shown below.
To be useful for spatial analysis, the IMD values need to be mapped to some spatial data. In this case, it’s one of the spatial areas used in the 2018 census, specifically, the statistical area 2 (SA2) zones. In urban areas, these are closely related to suburbs, though not exactly. (Side note: there are no definitive boundaries to suburbs as far as I can tell – something that many real estate agents take advantage of.) These data can be downloaded and added to a map:
So far so good. As a next step we might be interested in knowing each park’s IMD value. A nice little spatial join should do that trick. But before we get to that, Lucia needed to be sure that the areas surrounding each park (the access areas) were consistently of the same socio-economic status, meaning that we need to think about not just the park but also the access area – which meant creating some buffer zones around each park. Lucia used three buffer distances depending on the size of each park:
|Park size (m2)||Buffer Distance (m)|
|0 – 1,000||150|
|1,000 – 10,000||250|
This led to new parks layer for this analysis:
Right – things are starting to get complicated but we’re poised to do some analysis now. Next step is to find those parks and their buffers that share the same IMD values (i.e the IMD value of the surrounding area is the same as the park’s IMD value).
My first thought here was, wouldn’t this be a great use of a spatial join? Bring together the two layers so that we have all the information for each park plus whatever IMD values are in the overlapping polygons? No brainer. Or so I thought.
We’ve got several choices for doing spatial joins:
These tools all do similar things but if different ways and with different outputs. In all cases, we’re joining at least two layers together, both on the map and in the attribute table. It’s a simple but very powerful form of spatial analysis. In this case, we should end up knowing the IMD value for each park and buffer. Intersect seemed like a good option here. While it seemed like the right idea at the time, the output was clearly going to be difficult to work with. Hopefully the image shows why:
Very busy indeed. The problem here is that there are so many overlaps that it’s going to be very difficult to easily consider any given park on its own – there’s almost too much information in the table to work with. This is one of the only times I can think of that a spatial join has let me down. (Ed. How sad for you.)
But all is not lost! No! Not by a long shot. From the depths of my addled brain, I recalled a seldom used tool that could help. It may be seldom used but when it does what’s needed, it becomes the most important tool on the face of the earth. (Ed. Please seek some help before it’s too late for you.) The tool I have in mind is Tabulate Intersection. The help file tells us that this tool “Computes the intersection between two feature classes and cross tabulates the area, length, or count of the intersecting features.” and the picture helps to illustrate:
If we run this tool on Lucia’s data, she should end up with a table showing each park (by its name) and then a row for each different IMD value. The advantage here is that things are summarised by park name, making it easy to see the range of different IMD values. Here’s a quick pick at her output to illustrate:
It’s sort of an off-beat spatial join with a table instead of a layer as an output. From this we can see that, for example, Abberley Park sits across two IMD zones with values of 2 and 5. Acorn Reserve has just one value (6). And so on. While it’s not a spatial layer, it does make it easier to pick out the parks she wants to focus on – parks listed just once were the ones she was after. And here’s her final set of parks, awaiting a shade audit:
So what have we seen here? Hopefully, a number of useful things:
- Mapping socio-economic status with the IMD;
- Familiarity with census mapping areas;
- A reminder about spatial joins;
- A new tool for many: Tabulate Intersection.
The hard work for Lucia begins now as she starts to do the main work of her research. Here, GIS has helped to narrow down all the possible study sites to a more manageable (and defensible) set. Looking forward to some results now (no pressure)!