More adventures in overlay: splitting polygons with cartographic spaghetti

In my previous blog post about overlay, I showed how to create simple tabulation tables using a variety of geoprocessing tools.  In this post, I continue with the theme of overlay by introducing an overlay methodology that can be useful in some cases.  This methodology revolves around the creation and subsequent detangling of something us old-timers call ‘cartographic spaghetti’.

The scenario

The map below shows two polygons that delineate forest areas.  The labels on the polygons show the two attributes of the polygon: District, and NTrees (Number of Trees).  The map also shows a river system that dissects the forest polygons.  The problem is to split up the forest polygons by the dissecting rivers, creating new polygons whose boundaries are defined by the rivers.

As with most of my posts, this is a really simple dataset I concocted to illustrate the problem and solution.  Your data may be far more complex, but, in essence, it boils down to a polygon feature class with a bunch of attributes and one or more line feature classes that you want to use to split your polygons.

Figure 1: The task is to split the forest polygons by rivers.


You can download the data and models shown in this blog here (this is a geoprocessing package and requires version 10.1).

Create some spaghetti

Figure 2: Spaghetti on my refrigerator

The first step is to create polygons from the combination of forest polygons and rivers. This is where the metaphor of ‘cartographic spaghetti’ comes in. Suppose you take a handful of cooked spaghetti noodles and throw them against your refrigerator door. If you throw them carefully, they’ll stick there long enough for you to realize that, in cartographic terms, you just created a map on your refrigerator door (by the way– congratulations). If you’ve used enough spaghetti and a good throwing technique, you’ll have noodles that cross each other and have formed polygons. In GIS terms, the equivalent is to throw a bunch of line features together and create polygons from the mix. That’s what the Feature To Polygon  tool does.

Figure 3: Feature To Polygon tool dialog

Figure 3 shows the Feature To Polygon tool dialog with the forest and rivers as input. Note that you can input any number of polygon or line features to the Feature To Polygon tool (see the end of this post for an example).

Figure 4 shows the result of running Feature To Polygon. There are 9 polygons that fall into 2 classes:

  1. Polygons formed by the rivers that dissect the original forest polygons.
  2. ‘Artifact polygons’ — Polygons formed by rivers outside the original forest.

Figure 4: Output of Feature To Polygon

The attribute table of this output is shown below. Note that the three fields, FID_ForestDistrict, and NTrees, all contain their default (null) values. These are attributes of the original forest polygons and, while present on the table, only contain their default (null) values—fairly useless information. (Although the Feature To Polygon has a Preserve attributes parameter that allows you to control how attributes are written, it doesn’t have any effect on the output as noted in the tool’s documentation.)

Figure 5: Attributes of the output of Feature To Polygon

Removing the attributes

Unless you’re planning on updating the attributes manually, you should delete all the attributes of the output of Feature To Polygon. Personally, I always delete the attributes. In this scenario, this means we want to delete FID_ForestDistrict, and NTrees. You can use the Delete Field tool for this.

Here’s a tip that is especially useful when building models and scripts: The Feature To Polygon tool has a Label Features parameter used to define the attributes of the output. This parameter takes a point feature class. If you provide a point feature class with no points and no attributes, the output of Feature To Polygon will only contain the four required fields: OBJECTID, Shape, Shape_Length, and Shape_Area and none of the attributes of the input features. To create an empty point feature class with no attributes, use the Create Feature Class tool, as shown in Figure 6 below. In the Create Feature Class dialog, I use the in_memory workspace to create a point feature class in my computer’s memory (rather than a location on disk). This in-memory feature class will automatically be deleted upon exit from ArcMap. Since I don’t want any attributes, I leave the Template Feature Class parameter blank. In Feature To Polygon, I use the output of Create Feature Class for the Label Features parameter. The end result is just what I want; a simple polygon feature class with no attributes.

Figure 6: Creating and using an empty point feature class to create spaghetti without attributes

Overlay the original polygons with the spaghetti polygons

Now all we need is to make the polygons meaningful by adding back the attributes of the forest polygons, as well as removing the artifact polygons described above.

Figure 7: Identity tool dialog

Here’s where overlay comes in. The Identity tool (found in the Analysis toolbox/Overlay toolset) does the job perfectly;  forest polygons are overlain on top of the spaghetti polygons.  You can think of Identity as ‘stamping’ the Input Features and their attributes onto the Identity Features.

Figure 8 shows the output of Identity, where the artifact polygons are removed and the polygons that comprised the original two forest polygons are preserved.

Figure 8: The result of the overlay

But there’s a problem with the attributes. The FID_Forest (the original forest OBJECTID), and District are all correct, but NTrees is not. NTrees (the number of trees per polygon) is an area proportion attribute. That is, its value is in proportion to the area of the polygon. In this case, the original value is simply copied to the output and is not proportioned by area.

Figure 9: The values of NTrees are not apportioned by area

Apportioning the NTrees attribute

You can instruct overlay tools to apportion attribute values on area by using the Make Feature Layer tool to create a layer that contains a bit of additional field information, then input this layer to the Identity tool (or any other overlay tool).  In Make Feature Layer’s Field Info parameter, there is a Use Ratio Policy column containing a checkbox.  By checking the box, you are telling any tool that uses the layer that the attribute is to be apportioned by area.  As shown in the model in Figure 10, the NTrees field has its Use Ratio Policy column checked.  The output layer is then input to Identity.

Figure 10: Full model that uses Make Feature Layer to apportion the NTrees attribute

After running the above model, the NTrees field values are now apportioned by area as shown in Figure 11.

Figure 11: Correct apportioning of the NTrees attribute

Note that it’s more likely that you don’t have any area proportion attributes, so there’s no need to insert Make Feature Layer into the workflow. In this case, the model looks like this:

Figure 12: Model that doesn’t apportion attributes


In this post, I showed how you can split polygon features by line features as follows:

  1. Create cartographic spaghetti using the Feature To Polygon tool,
  2. then use the Identity tool to overlay the original polygons onto the spaghetti.

When using the Feature To Polygon tool, you almost always want the output to have no attributes (other than the required attributes of OBJECTID, Shape, Shape_length, and Shape_area). You can do this by supplying an empty point feature class for the Label Features parameter of Feature To Polygon.

The forest polygons contained an attribute, NTrees, that contained the number of trees.  In order to have the values of NTrees apportioned by area, the Make Feature Layer tool was used to designate that the NTrees values were to be apportioned when the Identity  tool was run.

To illustrate that this technique works with multiple line feature classes, Figure 13 shows the same study area, but using two line feature classes, roads and rivers, to split the polygons.

Figure 13: Splitting forest polygons by rivers and roads

Read the next blog in this series:  Counting overlapping polygons with spaghetti and meatballs


This entry was posted in Analysis & Geoprocessing and tagged , . Bookmark the permalink.

Leave a Reply