{"id":5014,"date":"2025-10-28T00:04:39","date_gmt":"2025-10-28T00:04:39","guid":{"rendered":"https:\/\/blogs.lincoln.ac.nz\/gis\/?p=5014"},"modified":"2025-10-28T00:06:39","modified_gmt":"2025-10-28T00:06:39","slug":"zoning-in-on-landcover","status":"publish","type":"post","link":"https:\/\/blogs.lincoln.ac.nz\/gis\/zoning-in-on-landcover\/","title":{"rendered":"Zoning in on Landcover"},"content":{"rendered":"\n

We look at summarising vector polygon data within larger polygon zones using two different workflows.<\/em><\/p>\n\n\n\n

Polygons give us a handy way of creating zones<\/a>, within which we might be interested in knowing what’s going on. Think of country boundaries, regions, school zones or even your own property boundary. Within those zones we often need to summarise some other phenomenon or physical characteristic. Suppose, for example, we’re interested in getting a breakdown of landcover within a river catchment. Sounds like it should be a pretty easy thing in GIS, yeah? Well, not necessarily. At least I haven’t found a straightforward way to do it yet so here I’ll outline two ways to do this. To give us some context, we’ll work with the catchment for Lake Forsyth\/Wairewa on Banks Peninsula (which is composed of several different rivers and the lake): <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

I extracted this from the level 10 HydroBASINs layer on J:, just to give us something to work with. And here’s the Landcover Database layer:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Clearly, there are a number of different landcovers within the catchment – my aim here is to quantify their areas and percentages within the boundaries of the catchment. Here’s a quick look at the LCDB attribute table:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

What I’m mostly interested in are the Name_ attributes. They tell me the name (or category) of each landcover with values for 2018, 2012, 2008, 2001 and 1996 (seems like we’re overdue of an update). Note too that there is a Class_ attribute. This has a numerical code for each landcover. <\/p>\n\n\n\n

It’s a subtle but very important point that, even though this code is a number, it’s really just a category (the data mavens amongst us would call them nominal data<\/a>). While we could add 22 and 21 (the codes for Estuarine Open Water and River respectively), the result doesn’t mean anything: what landcover is 43? It’s actually Tall Tussock Grassland, but adding the two doesn’t magically change the landcover – and Pro won’t stop you from doing this. Key takeaway here is that the Class_ attribute is a name masquerading as a number. <\/p>\n\n\n\n

As a first cut it might be tempting to try the Summarize Within<\/a> tool, which is designed to do just what I might want here: “Overlays a polygon layer with another layer to summarize the number of points, length of the lines, or area of the polygons within each polygon, and calculate attribute field statistics about the features within the polygons.” The only problem here is that this tool only works with numerical rather than categorical attributes, i.e. numbers rather than names. Let’s set the tool up so you can see what I mean:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Under the Summary Fields, the tool only recognises the number fields. In the case of these data, I can make this work by setting the field to Class_2018 and the Statistic to Sum:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The output is a new polygon layer and the table looks something like this – I can only show a small part to make it readable:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

See how each of the class names is now a field? It’d be easy to assume that the values for each field are in square kilometers (especially as I’ve set the Shape Unit to these units) but they are actually percentages <\/strong><\/em>of the total catchment area. I only picked this up on a very careful reading of the help files. Note that since my input polygon layer has only one record, there’s only one output record – but there’s no problem with having multiple input polygons. For New Zealand, HydroBASINs at level 10 has 1,849 catchments which you could do all at once.<\/p>\n\n\n\n

Summarize Within only works here because I’ve got my Class_ codes. But what if I didn’t have that? Let’s assume I’ve only got my Name_ attributes and still want to do the summarising? Here’s where a two-step approach comes in, namely by using Tabulate Intersection followed by Pivot Table. Let me explain. <\/p>\n\n\n\n

Tabulate Intersection<\/a> does just what it sounds like – it “Computes the intersection between two feature classes and cross tabulates the area, length, or count of the intersecting features.”:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The Zone features are the polygons we want to summarise within while the Class features are what we want to summarise. In the output (which is a table) each Zone can have multiple rows – one for each class within it. Plus, we get Area and Percentage in one fell swoop. Let’s try it on our Little River Catchment:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

I’ve set the Zone Field to HYBAS_ID. This is a unique identifier for each catchment in this layer. This will become more important when we use Pivot Table (I could have used OBJECTID as well). Here’s the output:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

As we may have expected, we’ve got a record for each Name_2018 value with AREA and PERCENTAGE fields and all the HYBAS_IDs are the same. This has tallied things up for us nicely but as a next step, we’ll attach these back to our catchment polygon using Pivot Table<\/a>.<\/p>\n\n\n\n

This tool works just like it does in Excel – we can reorganise the table and “flatten” this many-to-one relationship. This image from the help file may help:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

I’ll be honest, whenever I use this tool I have to think hard about which field is which and often have to run it a few times to get it right. What I’m wanting to do is to convert this table of 20 rows to just one, with a column for each landcover’s AREA and PERCENTAGE. The only drawback here is that I can only do AREA or PERCENTAGE, not both. Here I’ve set it to do the PERCENTAGE: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The output is, once again, a table:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

If I need this as part of my polygon layer, I can next use a table join to link this back using HYBAS_ID, giving me a breakdown of the percentage area for each landcover. Again, if I had multiple polygons in my input layer, I’d also have a breakdown for each one. <\/p>\n\n\n\n

We’ve looked at two ways of summarising one layer’s polygons within a different set of polygons: Summarize Within and Tabulate Intersection\/Pivot Table. Each can be made to work and which one you choose will depend on what attributes you’ve got to work with. As another example, I was recently wanting to do something similar with zoning data within a town boundary. The input data had categories of planning areas but no numerical code to go with it. My only option was Tabulate Area\/Pivot Table so, once again, Analyst, know thy data. <\/p>\n\n\n\n

We’ve got a few other things to cover while we’re talking about summarising data within polygons, especially when it comes to raster data (spoiler alert: zonal statistics<\/a>). But that’s a job for another day. <\/p>\n\n\n\n

C<\/p>\n","protected":false},"excerpt":{"rendered":"

We look at summarising vector polygon data within larger polygon zones using two different workflows. Polygons give us a handy way of creating zones, within which we might be interested in knowing what’s going on. Think of country boundaries, regions, school zones or even your own property boundary. Within those zones we often need to […]<\/p>\n","protected":false},"author":3,"featured_media":5030,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-5014","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/5014","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/comments?post=5014"}],"version-history":[{"count":2,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/5014\/revisions"}],"predecessor-version":[{"id":5029,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/posts\/5014\/revisions\/5029"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/media\/5030"}],"wp:attachment":[{"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/media?parent=5014"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/categories?post=5014"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.lincoln.ac.nz\/gis\/wp-json\/wp\/v2\/tags?post=5014"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}