Lecturer: In lecture two of module two,
we're going to dig into one of the more technical aspects
of geoprocessing to help develop a better understanding
of what's really going on behind the scenes in ArcGIS
when we click run in a geoprocessing dialogue box.
As I was perusing geoprocessing tool reference pages,
you know, like you do in your free time,
I stumbled across something interesting.
This is for the help for the Intersect tool.
For inputs with different geometry types,
for example, line on poly, we're talking about a tool
that takes two or more vector datasets
as their input features.
The output feature class geometry will default
to the same as the input features geometry type
with the lowest dimension geometry.
Again, this comes from a help file, to which I say, huh?
Look at the graphic on the right hand side
to see if we can't introduce some clarity here.
As you move from left to right on the graph,
from points to lines to polygons,
the number of dimensions increases.
So if you're in a situation where you're intersecting
a point feature class and a line feature class,
the output features will be points.
Lines and polygons, the output features will be lines.
This is what's meant by defaulting
to the lowest dimension geometry.
Now that we've got that cleared up, let's move on
to explore environment settings and how they do
or don't affect various geoprocessing operations.
First, let's establish some common ground
regarding what environment settings are, what they do,
and where to find and define them.
Then we'll look at specific geoprocessing tools
and evaluate whether various Environment settings
affect the values or spatial extent of the output data.
Environment settings are additional parameters
that affect a tool performance and results.
They don't appear in a tool's primary dialogue box.
Rather, you access them from the environment's dialogue box.
These are parameters that you set once,
although you can change them as often as you'd like.
Unlike tool parameters you set each time you geoprocess,
environment settings cascade through the project
to influence subsequent geoprocessing operations,
assuming the geoprocessing tool honors
the environment setting.
The software evaluates environment settings for inclusion
in a particular geoprocessing rule at run-time.
That is when you click run from a tool dialogue box.
Now it's important to note that not all geoprocessing tools
respect every environment setting.
If you derive an unexpected result,
the environment setting dialogue is one place to check
among many to help troubleshoot your situation.
We'll look at some examples of this in a few slides.
I'll also mention that some environment settings
are vector or raster specific.
So a raster environment setting is not going to affect
a vector geoprocessing operation and vice versa.
Geoprocessing tools will observe
default environmental settings.
Even if you haven't set any,
that doesn't mean some don't exist by default.
One example of this is the current workspace setting.
Although you've never set this, at least not in this class,
you've already benefited from having one in lab one.
This environment setting is established
automatically by ArcGIS when a new project is created.
It points to the project geo database
also created at the same time as the new project.
When you click run on a tool dialogue box,
ArcGIS looks for environment settings,
applies them if any are found,
or more specifically found to be relevant,
and then runs the geoprocessing operation.
As noted in the previous lecture,
there's an environment section in every tool reference page.
Here, you can learn which environments are honored
by a particular geoprocessing tool.
You can also easily link to
the environment settings reference page
from this part of the tool reference.
Some geoprocessing tools assume default parameter values
based on the existing environmental settings.
Remember, you can always change these
either in the environment settings dialogue box
or on the tool specific environments tab.
One other thing to mention about environment settings
is their hierarchical structure.
There are four levels to this hierarchy.
The application level, this is the default.
In the absence of other information,
ArcGIS will look for application level environment settings
and apply that to a geoprocessing tool
at the time of execution.
Tool level environment settings only apply
to that single tool run.
It overrides the application level setting of the same name.
You might have an application level setting
established to limit the spatial extent
of your output to the area of interest.
However, maybe you want to run a tool to produce output
that extends beyond your area of interest,
alter the extent setting at the tool level,
produce your result, and carry on as you did
prior to altering the tool level setting.
We'll talk about model level
and model process level settings later in the course.
For now, it's enough to know they exist
and that they behave differently
than the two levels we've discussed.
Last thing here, each of the four levels
have the same list of environment settings
and the settings function the same way.
If you set the extent parameter
to the same feature class in the application level
and then the tool level, you'll produce the same output.
The difference is both in how you access
and how you set the parameters.
I present several environment settings categories here.
Note this is not an exhaustive list.
Rather, I list those that I make use of most frequently.
Workspace settings direct file storage traffic
where the files are written on disk.
The processing extent limits the spatial extent
of the analysis and output.
Raster analysis, as its name implies,
influences raster geoprocessing operations.
How do you access the environment settings dialogue box?
From the Analysis ribbon, of course.
The Environment button is on the left side
of the Analysis ribbon.
Click it to open the environment settings dialogue box.
The top half is in the image on the left
and the bottom half of the dialogue box is on the right.
I've also minimized several of the categories
to hide some details.
You can expand or contract the section
by clicking the arrow to the left of the category name.
I thought it would be useful to look at
a few environment settings in the context of
specific geoprocessing tools to learn how they do
and do not affect those operations.
On the left is the environment settings dialogue box.
These are all default values,
including those for the current and scratch workspaces.
By default, ArcGIS assigns current workspace
and the scratch workspace to the project geo database,
which is created with the new project.
You can change either or both of those settings
and that would redirect the traffic.
Your output from a geoprocessing operation
to a different database or directory.
On the right side of the slide,
we see the Copy Features geoprocessing tool.
Let's experiment with copying a feature class,
a pretty basic operation all things considered.
This is the tool dialogue box before any parameters are set.
If I click the Environments tab,
we can see a lot of the same categories that appear
in the environment settings dialogue box in the left image.
The image on the right displays
the tool level environment settings
for the Copy Features geoprocessing tool.
Note that not all of the available settings on the left
are included on the tool level settings.
This implies that these settings
are not honored by the tool.
I'm going to set my extent
to a feature class named Waitsfield.
Note that you do not have to use
a polygon feature class for this setting.
A bounding box can and is drawn around
every type of vector geometry.
Once I select my extent parameter,
the boxes below are populated with numeric values.
When I open the Copy Features geoprocessing tool
and examine the Environments tab,
the tool level environment settings,
I note that the same set of numbers
from the environment settings dialogue box
on the left appear.
We see the application level settings on the left
and the tool level settings on the right.
Now where do you suppose those numbers come from?
If we open the layer properties
for the Waitsfield feature class,
and access the extent section of the Source tab,
I see that same collection of numbers.
Top, bottom, left, and right.
Four unique numbers from which
we can generate four coordinate pairs
to define the minimum bounding box of the feature class.
The minimum bounding box is the smallest rectangle
I can draw around a feature class
that includes all of its features.
I've set the required parameters of the Copy Features tool.
I want to make a copy of a point feature class.
I ran this operation twice,
once with the default environmental settings
and once with the extent set to
the Waitsfield feature class.
Let's look at the results.
If I look at the input data over on the left,
there's a black polygon, the Waitsfield feature class,
and a collection of points.
These are actually points of interest
in and around the matter of valley.
On the right we see the output
with the default settings in place.
Doesn't look any different than the input data.
But if we look at the output with
the extent set to the Waitsfield feature class,
we see something altogether different.
There are a lot fewer points,
but for some reason there are still points
outside the Waitsfield boundary.
Remember, the extent was set to
the Waitsfield feature class,
which really means the bounding box
of the Waitsfield feature class.
The yellow box represents that bounding box
drawn from those coordinates we saw in an earlier slide.
Let's take a look at another copy feature example.
In this case, let's copy a line feature class
representing winter recreation trails.
Based on what we saw in the last example,
I'd say the output looks a little bit different
than what was expected.
What do you suppose is going on here?
Here's the bounding box of the Waitsfield feature class,
the extent environment.
And here's the extent of the output data.
We already observed with the copy point features
that the tool does not function like the Clip tool.
Rather, ArcGIS makes a copy of the features
that pass through the bounding box.
Remember with select by location
that you select a feature regardless of how much
is in or outside the polygon boundary.
This is the same sort of deal.
Any of those line features you see outside
of the extent have some portion of their feature
inside the bounding box.
Any line features completely outside the bounding box
are excluded from the output dataset.
One more digression.
If you think it's frustrating to read unhelpful help,
imagine the difficulties this presents with teaching.
From the tool reference, the tool you are using
will determine the processing extent.
All tools have a default extent
they calculate from their inputs.
This default is rarely documented
on the tool reference page, but it's usually obvious.
Okay, but what if it's not obvious?
And as a further aside, obvious to who?
The person that created the tool in question?
My advice here is to look for external sources of help,
external to the Esri tool reference.
One good resource is the GIS Stack Exchange site.
I can't promise you'll find answers here,
but there are lots of good resources
that may get you back on track.
Speaking of which, let's get back to the topic at hand.
In this case, we're using the same processing extent setting
as before, the Waitsfield feature class.
This time, I'm going to copy a raster dataset
instead of a vector dataset.
We worked with the crop scape data in the introductory class
and we'll use that as our raster dataset here.
We see the tool fully parameterized here,
and if we switch to the Environments tab,
we see that the processing extent setting
has been adopted by the Copy Raster tool.
On the left is the input raster
and on the right is the output raster.
Maybe not exactly what we are expecting here.
The spatial extent has been reduced from the input raster,
but it still seems to extend beyond what I was expecting.
Let's dig in a little further to see what we can determine.
I'm comparing the output of the copy raster operation
to another raster dataset I'm using in my project.
The blue data you see is from a DEM
that uses the Vermont State plan coordinate system,
same as my Waitsfield feature class.
The crop scape data uses the same symbology as before.
I'm using the Swipe tool to compare the two datasets.
Based on what I see, the two datasets are using
different coordinate systems.
You could confirm this information
from the layer properties for the different rasters.
I also see that the cells are not aligned.
The crop scape data seems to be rotated
in relation to the DEM.
This could and probably would affect
any analysis that you need to do.
Remember that one of the benefits
of raster analysis over vector analysis
is the one-to-one correspondence between the cells
of two different raster datasets.
With rotated cells that only partially overlap,
you're bound to introduce confusion into your results.
ArcGIS will of course project the data on the fly,
but that means you're seeding control of some decisions
that are potentially better made by you.
Hence the need to harmonize the data.
Standardize it to eliminate some of the automated guesswork.
We might also consider looking into
raster specific environments to see
if there's anything to learn there.
Let's do that now.
We're also going to switch tools here
to see if we can't get closer to the result that we want.
The crop scape data limited to the Waitsfield feature class
that directly overlaps my DEM.
Let's look at the cell alignment setting.
This sounds promising.
We'll align ourselves with the processing extent.
On the right, you can see that I've already parameterized
the Project Raster tool.
And if we look in the environment setting,
so the Project Raster tool,
we actually don't see a cell alignment category.
This means the Project Raster tool does not honor
that particular environment setting.
Let's run the tool anyways and check the output.
We know we want the data in the same coordinate system
of the rest of the project data,
so we need to do this regardless.
The crop scape data is shown on the right side of the image
and the DEM on the left.
Looks like we're making some progress.
We see that the cells are oriented
in the same direction at least,
but they still do not directly overlap.
One other detail to mention here is that
both datasets use a 30-meter cell size.
Time to dig deeper still.
What other environment settings
might influence our raster analysis?
How about the snap raster?
ArcGIS uses the snap raster to snap or fix cell position.
The bottom left cell of the snap raster
is used to generate this positional alignment.
Your input data can extend beyond
the spatial limit of the snap raster.
In that case, ArcGIS still uses the snap raster
in the same way, only it aligns
to another cell in your input raster,
not the lower left corner of the input dataset.
Looking at my project raster environments on the right side,
I see that the snap raster is one of
the environment settings honored by the tool.
Difficult to display the cells in alignment, so instead,
I've used the swipe tool in the vertical
and horizontal directions to give you
a sense of the overlap.
Looks like I'm cutting cells from both datasets in half
and I'm satisfied that my alignment is correct.
If we compare the output crop scape data
to the input crop scape data,
we see the difference in rotation there too.
Things are looking pretty good
in terms of data harmonization.
What have we accomplished so far?
We've projected our data and used the extent setting
to limit the data to
the Waitsfield feature class bounding box.
We set the snap raster so the cells are completely aligned.
Almost there, but we've still got the issue of
the crop scape data extending beyond
the Waitsfield town boundary.
Maybe the mask setting will do the trick.
Even though the mask setting
is in the raster analysis category,
you can still use a vector feature class
as the parameter setting.
Choose the Waitsfield feature class
to constrain the dataset to the Waitsfield bounding box.
Do you think this is going to work based on
what you learn in the vector copy feature examples?
I'm a bit skeptical myself.
Once again, we'll use the project raster tool.
Here's a quick look at the environments
and here are the tool parameters.
Let's run it.
Looks better, but why can't I get this right?
The combination of the snap raster,
an extent environment settings that both played their part,
both of those are honored by the project raster tool.
We're getting so close.
Bear with me here.
I've had one of those crazy geoprocessing visions again.
Maybe I can just use a raster calculator query
to do the job.
I'll just query the crop scape data to look for cells
with a value greater than zero.
Good news, bad news.
My result is constrained to the Waitsfield boundary,
but all the cells have the same value, one.
Why?
Well, I queried the data and all the cells
that evaluated as true were assigned a value of one
and all the cells evaluated as false
were assigned a value of zero.
If I look at the environment section of the tool reference,
I see that the mask setting is honored.
If I read a little deeper, I learned that any cells
outside the mask, the Waitsfield boundary,
are assigned a value of no data.
That's why the output looked like it did.
So where do we go from here?
We're most of the way to our goal
and have a bunch of partial fixes and erroneous pieces.
Time to consult some GIS tea leaves,
or if that's not your thing, some tool reference pages.
Guaranteed good times.
After a cursory review and a couple of naps,
I've come up with three possible options.
Another raster calculator operation, extract by mask,
and extract by attributes.
Sounds promising except for maybe that first one.
Fool me once and so forth.
I reviewed the help and observed
that raster calculator honors the mass setting.
I'm going to multiply a projected version
of the crop scape data by the output
of the raster calculator query to see what happens.
Again, I'm trying to produce a crop scape dataset
of just the town of Waitsfield.
We'll look at that result in a couple slides.
Seems logical that the Extract by Mask tool
would honor the mask environment setting.
Also seems like it might not need the mass setting at all
since you actually specify the mask in the tool parameters.
This is essentially the raster equivalent
to the vector clip operation.
Set the input raster to our projected dataset
and the mask to the Waitsfield feature class.
Let's also look at the extract by attributes option.
This is essentially the same as a vector query
and data export workflow.
Remember with vector data, if you have features selected
and you perform a geoprocessing operation on that dataset,
only the selected features are considered for the operation.
I set my input raster as the projected version
of the crop scape data and then I create a query
for values greater than zero.
Let's take a look at the outputs.
Generally speaking, they're all the same.
That's a bit more obvious for the two on the right.
Remember from a few slides back
the image of the cropland data layer.
It appears the right two outputs maintain
the input raster symbology.
Not so with the raster calculator output.
Although the extent is the same as the other outputs
and the cell values are too,
the symbology was not carried over into the output.
You could of course use a layer file
to restore the symbology and be on your way.
That's it for now.
Hopefully I've demonstrated some useful insights
into the multiple pathways to solving geospatial problems
and the influence of environment settings
on geoprocessing operations.
Plenty more to talk about, but at this point
I think it's time to do a little digging on your own.
Grab some practice data,
try different approaches and settings,
take notes, and evaluate the outputs.
I'll see you in lecture three.