- [Teacher] This is the last of the Module Three Lectures.
In this lecture, we explore techniques
through summarizing raster data within bounded regions.
Think of this as the raster equivalent
of the vector operation reviewed in the last lecture.
Once again, we're faced with the same problem
of determining how much of one thing
is contained by another, or how much of each type
of that one thing is contained by the other.
First, a short step back to refresh
what we know about zonal operations.
Zonal operations summarize raster values
within a bounding unit or zone.
Those zone boundaries can be represented
with other vector or raster data.
But in this case, to remain consistent with the examples
of the previous lecture, we'll use polygons
to define our zone boundaries.
It's critically important here that each zone
feature a unique ID.
In other words, there are no two discreet bounding polygons
that have the same zone ID value.
Note that you can use a raster dataset
to represent the zones.
But in this case, the zone is defined
by the value of the pixel.
All pixels in the dataset with the same value
make up the zone, regardless of whether those cells
are adjacent to one another or not.
Zonal operations typically produce either a new table,
certainly when you run zonal statistics as table
or tabulate area.
Note that the zonal statistics tool
generates an output raster dataset,
and it's also only able to compute a single statistic
for each run of the tool.
This slide breaks down the key details or parameters
of the two primary approaches I'd like to focus on,
zonal statistics as table and tabulate area.
In the left column, we see the characteristics
of the zonal statistics as table geo processing tool.
As I mentioned earlier, input zones can be either vector
or raster and must use a unique ID for the zone field.
Hopefully you already know why,
but in case not we'll reconsider that on the next slide.
The input data should be a continuous raster dataset.
I say should here, because there is a specific case
where the thematic dataset could be used
and the output will still make sense.
If you want to summarize data from a continuous raster,
zonal statistics as table is the correct tool for the job.
The output table represents the summary statistics
of the input raster for each of the input zones.
What about tabulate area?
The primary difference here is that the input data
should be thematic.
I say should here because the tool will work
with continuous data, but the output table is likely
to be a mess.
If you're not sure why consider this again
after you've reviewed the output
of a tabulate area operation.
You still need to specify a unique value for each zone ID
and the output will once again be a table.
So why do we need unique value for each zone ID?
Look at the typical workflow for a zonal operation.
You compute that summary operation
and produce a tabular output.
How do you plan to map your results?
You're going to join that tabular output
to the input zone dataset.
That zone ID comes from the first step of what is commonly
a three or more step geo processing workflow.
Once the joint is implemented, you can query the result,
apply custom symbology or calculate values
of other attributes from the summary statistics.
This is certainly not an exhaustive list
of what might happen after step two.
Computing the summary statistics is just the first step.
Understanding the what and how of the operation
are critical for further interrogation of the data
in order to extract the information you're looking for.
Let's return to our trail buffers example
from the Vector Lecture.
This time however, we'll use zonal statistics as table
to make our calculations.
We're once again using trail buffers shown in blue
and town boundaries, gray with black outlines.
I converted the polygon trail buffer data to raster data.
If we zoom in a bit closer, we get confirmation
that this is indeed a raster dataset.
I can see that stair-step outer edge
of what used to be the polygon boundaries.
In this case, our input data,
that raster that defines whether something
is a trail buffer or not, takes on a value of zero,
not a buffer or one as a buffer.
Look to the right to evaluate the parameters
of the zonal statistics as table operation.
Not surprisingly, I'm going to use that FIPS six code
as my zone ID.
We run the tool to produce a table of summary statistics,
one record for each of the FIPS six codes
in my input zone data.
At this point, you might be scratching your head saying,
wait a minute, you just introduced
zonal statistics as table as the appropriate tool
for summarizing continuous raster data
and then the first example you show us
is not a continuous raster dataset.
And you're absolutely right.
This is the special case I alluded to earlier.
In this instance, it's important to remember that a pixel
in my input dataset is either a trail buffer
of value of one, or it's not, a value of zero.
The output here has a particularly useful interpretation.
Not surprisingly, we see a minimum value of zero
and a maximum value of one.
The count represents the number of pixels in that zone
and the sum is the sum of all values in that zone.
If you divide the sum by the count, you get the mean.
The mean value in this case represents
the percent of the zone that is covered by that phenomenon.
In this case, we interpret the first record in the table
to mean that 58% of the town with FIPS six code 23040
is covered by the 500 meter trail buffer.
It's important to understand that this interpretation
only works when you specify a raster dataset
with values of zero and one for your input values.
Let's take a look at a slightly different example
with a more traditional continuous raster.
In this case, a digital elevation model.
We see the input data in the image on the left,
which includes the town boundaries and a DEM with values
that range between 548 and 4,064 feet.
I set up the zonal statistics as table tool
exactly like I did before, but the key difference being
the input raster and the output table name.
When we look at the output table,
we notice that it's got all the same statistics
we saw last time, the min, max, mean and so on
but the way to interpret this is different.
Let's review the top record in the table.
The mean value of that top record
is approximately 1,720 feet.
That means the mean elevation in that particular town
is 1,720 feet.
We can't tell how much of the town is at
or above that elevation.
Obviously the output is still valid and useful,
but it's important to understand that the interpretation
of the outputs for these two different instances does vary.
One other things to mention here is this warning
you might receive when running a zonal operation.
The warning states that some zones
may not have been rasterized.
That's okay, it simply means that one or more
of the zone boundaries are so small or oddly shaped
that they did not contain the center point
of any of the pixels in your input raster dataset.
As a result, that particular zone will be ignored
in the calculations.
Okay, now back to our regularly scheduled programming.
Let's look at another case here.
We use zonal statistics as table again,
but this time we've got multiple buffers around the trails,
one at 500 meters with a pixel value of 500
and the other at 1000 meters with a pixel value of 1000.
What do you think?
Is this the right tool for the job
if we're trying to compute the amount of each town
that is comprised of each buffer type?
Let's look at the output table.
Once again, as expected, we see the same listing
of statistical summary information,
but what can we tell from the output?
Remember the 500 meter buffer has a pixel value of 500
and the 1000 meter buffer has a pixel value of 1000.
What does a mean value of 574 actually mean here?
Not much really.
It's certainly not the mean buffer with in each town.
If you've got some well-developed math skills,
you could probably back your way into something meaningful.
But for the rest of us, what's the point?
My point here is simply to illustrate that this is not
the right tool for the job.
However, if you use raster calculator
to query your raster inputs, to, for example,
identify all pixels of the 1000 meter buffer
or elevations above 1700 feet in the DEM,
you produce datasets that meet the criteria
of the special case raster that only contains values
of either zero or one, where zero means the pixel
did not meet the criteria 1000 meter buffer
or 1700 foot elevation and one means that it did.
We've already reviewed an approach to summarize
this type of data so I won't go into that again here.
Let's move on to the tabulate area geo processing tool
to address the same questions.
We've got our 500 meter trail buffers
and town boundaries once again.
I set up the tabulate areas geo processing tool
as you see on the right.
And, not surprisingly, I need to specify a zone field
as well as the input raster.
The tool produces a table as its output.
The review of the output table reveals the FIPS six code
as expected and the columns for values of zero and one.
Of course, the zero and one represent the classes
of the input raster where zero means the pixel
is not a trail buffer and vice versa.
Now it's important to note here that these numbers
represent the area of each pixel class or value
within that particular zone boundary.
If we look at that top row, we see that the value one number
for the FIPS six code 23040
is about 54.5 million square meters.
You can always review the layer properties
to determine the linear and arrow units of the data
you're working with.
Okay, that was a simple example.
Let's muddy the waters a bit.
This time, we'll evaluate two trail buffers,
one at 500 meters and the other 1000 meters.
Of course, we also have the non buffer pixels
with value zero.
If I set up the tabulate area tool in the exact same way,
what do you suppose will happen here?
After I run the geo processing operation
and open the resulting table,
I see a format that looks very similar to the previous one
with the addition of the 1000 meter buffer.
That's great. One more quick aside here,
in this example, I illustrate the use
of the tabulate area tool
on the National Land Cover Dataset.
That's automatic raster
with more than 25 pixel classes or values.
I set the tool parameters just like we've seen before
and run the operation.
The output is as expected.
I only show this example to point out that it doesn't matter
how many different values are represented
in your input raster.
In the end, each value will have a corresponding column
in the output table where the cell value represents
the area of that pixel class within a given boundary.
If we compare the outputs from the zonal statistics as table
and tabulate area operations, we know similarities
and differences in the two approaches.
Of course, it doesn't make sense
to calculate summary statistics on thematic values.
They're not really numbers.
The primary similarity here is the zone field definition.
And we can see the FIPS six code throughout all four
of the tables that are present here.
Let's look at just two of the outputs,
the two that dealt with a special class of input raster
with values of zero and one.
Can you see any similarities between the two tables?
Look at the top row in each,
they both refer to the same town,
which you can tell by the FIPS six codes.
If we multiply the area by the mean,
I derive a value of 54.5 million square meters.
If we look instead at the tabulate area result,
we see almost exact same value.
We wondered to the same result,
along two very different paths,
zonal statistics as table and tabulate area.
So where do we go from here?
Remember that a joint operation joining the resulting table
from a zonal operation to the input zone data
is a common following step after zonal calculation.
After that, query the data, apply custom symbology,
calculate attribute values, recreate new attributes
based on your findings.
That's it for Module Three Lectures.
We covered a lot of ground this week.
Hopefully some of it was review and some of it was new.
If any of this remains a mystery to you,
one, don't panic
and two, post questions and comments to Yellowdig
and let's keep the conversation going.