- [Instructor] In this last lecture for module seven,
we'll take another look at visibility analysis.
We've already explored the Viewshed tool
or at least minimally explored the Viewshed tool.
We'll take another look at that as well as other options
for assessing visual quality of a landscape.
Now Viewsheds as you recall identify cells in a raster
that can be seen from one or more observation points.
And we'll focus in this lecture on three primary options
for performing this type of analysis,
Viewshed, Observer Points, and Viewshed Two.
Now we've worked with the Viewshed tool already
dealing with individual appoints
to assess their visibility on the landscape.
In this lecture, we'll quickly review that,
but also look at analyzing line features.
Observer Points produce output rasters
that store information about which observers
can see a particular cell.
And finally, the Viewshed Two tool can do both of these,
the frequency or the observers,
but uses a geodesic method for calculation.
I won't go into all the math here, but this takes us back
to conversations about coordinate systems.
The surface raster and the observers are transformed
from the input coordinate system
to a three-dimensional geocentric coordinate system.
This produces a more accurate result from the analysis
but can be much more computationally intensive.
The other thing to note about the Viewshed Two tool
is that it uses the graphics processing unit, a GPU,
instead of a central processing unit, a CPU.
And you'll probably see a warning
indicating that's the case
when you work on your own examples
for Viewshed Two analysis.
Now recall that the Viewshed tool requires an input raster
and either a point or polyline observer features
in order to produce an output raster.
In the previous examples that we use the Viewshed tool for,
we analyze a single point at a time.
In this current example,
I've got 10 different picnic site locations
scattered throughout the Mad River Valley
that will serve as my input points.
If I look at the output raster,
I see that it ranges in value from zero to 10
where zero indicates that none of the observation points,
those picnic spots, can see a location on the landscape
or 10 meaning all of those picnic spots
can see a particular location on the landscape.
We can also open the attribute table and get information
about the number of cells that are visible from
the number of different locations.
What we can't do with this information
is determine which picnic spot can see which location.
We might be able to infer some of those low-end values,
but it gets more complicated
the more observation sites that can see
a particular location.
Instead if we want that kind of information,
we can use the Observer Points tool.
Note that the setup for the Observer Points tool
looks very similar to the Viewshed tool.
We need an input raster, some point observation features,
and specify an output raster name.
Note that the big difference here
between Viewshed and Observer Points
is that Observer Points can only deal with point inputs.
So we've got our same 10 picnic spots
and I run that analysis.
The output looks mostly the same,
but the way that the values are coded is quite different.
First of all, we see that the values range
from zero to 1,023.
If I look at the output table, the attribute table itself,
I see what I was expecting to see
in terms of my object ID, my value and my count.
But I also see these OBS followed by some number.
In this case, ranging from OBS one to OBS ten,
one column for each of our different observation sites,
those picnic locations.
The interpretation of this table
might seem a bit tricky at first,
but on closer inspection, it's relatively straightforward.
Let's look at the row with object ID value two.
It's got a value of one, 4,559 pixels
in our output dataset take on that value
and we note by reading across that OBS one
has a value of one while the other observation sites
have a value of zero.
That means that any pixel in my output dataset
coated with a value of one
can only be seen from observation point one.
If we move down to the row where the object ID equals four
and the value is equal to three,
we note that values of three indicate that those locations
are visible from both observation point one
and observation point two.
So lots of information included in this table
as long as you know how to unpack it.
One other thing to note here
given my 10 observation points, my 10 picnic areas,
there are 300 different combinations
of visibility that appear in the output table
and we can see that
on the bottom of the attribute table itself
where I have zero of 300 records selected.
Let's take another look at Observer Points.
And in this case, I want to compute the above ground raster.
This indicates the amount of fill
or the elevation that would need to be raised
at this location in order to be able to see spots
that are not currently visible.
So first things first we run the Observer Points
and then we look at the output.
Over on the right-hand side, depicted in red,
we can see the Viewshed from that particular observer point.
I have that draped over the top of the above ground raster.
Those values are shown in blue, and we can see that
in order to make locations that are not currently visible
from this particular observer point visible,
we'd need to raise the elevation of that observation point
by almost 2,000 meters.
We note that maximum value from the legend
for my above ground raster.
Let's take another look at an Observer Points example.
In this case, I've just got three points
that I want to evaluate,
a trailhead and two shelters up off the long trail.
I've run my Observer Points calculation
and I return seven different possible combinations.
So our values range from zero to seven.
We can see those combinations
in the table over on the right hand side.
A value of zero means
none of the observation points are visible
whereas a value of seven means all three points are visible
in that location.
I can update the legend to indicate the visibility
at each location ranging from can't see any
to can see all three.
Now suppose I want to assign an economic value
to each of those pixels based on
what can be seen from that location.
I can use a tool known as reclass by table.
This is similar to the reclassified tool
that we've used before, but in this case,
I'm specifying the values via a table that I've created
and we can see that table on the right.
A value of zero gets a reclass value of zero.
A value of seven
meaning all three of my locations are visible
gets a value of $175.
The tool set up over on the left indicates
the required parameterization to make this work.
I've input my raster data set that I want to reclassify,
I've specified my remap table,
and then identified the appropriate fields for those values.
Once I run that operation,
visually we don't see any difference,
but the values themselves are now coded differently.
And I could, for example, run zonal statistics
on this new output to summarize the economic value
of visibility at the town level.
So I've done that here.
I joined that output from my zonal statistics
to the town boundaries data, and I can display the sum
of the visual values for each town.
Let's move on to Viewshed Two.
Now, in this case, the dialog box for Viewshed Two
is quite a bit more complicated than that
of the Viewshed tool itself.
Once again, we still need to specify an input raster,
provide input point or polyline observer features
and specify an output raster,
but that's the bare minimum that you can do
to make the Viewshed tool run.
Note that when I've specified my input raster
that I receive a warning message.
Input elevation raster
should have a vertical coordinate system
that has heights reference to a spheroid.
All this is telling me is that my digital elevation model
does not have a vertical coordinate system specified.
That's okay since my vertical units are the same
as my X, Y units, in this case meters.
However, if your vertical units were something different
than your X, Y units, you would definitely want to make sure
that you correct this issue
in order to derive the most accurate results.
I can look at more detail
about that warning here in the ArcGIS Pro help.
Now, the other thing that you can specify
in Viewshed tool is the analysis type.
And for this first example, we'll look at the frequency
and this mimics what we saw from the very first example
of this lecture where we ran a Viewshed analysis
with multiple points and the output showed the number
of Observer Points that could see a particular location.
And if I look at my outputs here, it looks very similar
to what we saw from that first Viewshed example.
Now let's change it up a bit.
All the same settings except for our analysis type this time
will be set to observers.
And because I've changed that analysis type to observers,
I will also be producing an output table,
the output observer region relationship table
that we see right below the analysis type parameter.
So it appears that my process has completed with warnings.
And in this particular case,
it's a warning about a GPU being used,
remember a graphical processing unit being used
to run this particular procedure.
I've received this message every time
I've run Viewshed Two even when it successfully concludes.
Here's the difference
between the two outputs that we just generated.
Over on the left hand side, we've got that frequency,
the number of observers that can see a particular location.
And over on the right hand side,
we've got the observers output,
these different combinations of observation points
that can see a specific location.
Note here that those values range from one to 1,023.
If I look at the attribute tables for the different outputs,
I can notice that I have my 10 observers
so those two tables on the top,
I've sorted the observer column in ascending order
on the left and descending order on the right.
I do the same thing for the region column
and notice that the lowest region value is one
and that highest region value is 1,023.
Again, this is information we could also see
on that last slide.
These tables are a bit more dense to unpack
so it's important to note that multiple different observers
can see the same region.
And in fact, that region value is assigned
based on the observers that can see it.
So in that table
in the lower right-hand corner of the slide,
we see that all 10 observers can see that region 1,023.
So note that there could be repeats of the observers
and repeats of the region within the table.
You might consider creating a pivot table
depending on how you want to use this information
for subsequent analysis.
Let's take another look at a Viewshed example here,
this time using the Viewshed Two tool once again.
In this case, I've got my same setup,
I'm using a single point at a trailhead location
on the long trail using that same DEM
and specifying my output raster.
One thing that I'm gonna do differently this time though
is applying observer offset.
So imagine that you have a tower of some height
at your particular observation location,
so no longer are you standing just on the ground,
you're climbing to the top of that tower
or the top of that offset
and evaluating the Viewshed from there.
Over on the left,
we see what's returned from that Viewshed Two tool
when no offset is specified.
Over on the right,
we see the Viewshed that's generated
when the offset is used shown in blue
with the result from the no offset draped on top
and red there for comparison.
If we really wanted to get more detailed
about the difference between the two outputs,
we could use either the minus geo processing tool
or set up a formula in raster calculator
to compute difference between those two surfaces,
the one with the offset and the one without the offset.
So I show both examples here
in this slide and they generate the same result
that we see here on this slide.
Now if I open the individual attribute tables
for the no offset Viewshed, the offset Viewshed,
and the difference between the two,
I can subtract those counts for the value of one
in my two inputs
and derive that same result for the output.
Now let's come back to the original Viewshed tool
and look at what happens with linear features.
In this case, I've got a small trail segment
from the long trail identified in blue
over in the image in the right.
From my Viewshed output,
I see that there are between zero and 633 observers
for each of the locations within the study area.
Now, how did I get at that number?
Well, when you use a line input for your Viewshed tool,
ArcGIS uses all of the nodes and vertices
as those observation points.
We don't have any control over where those nodes
and vertices are located, unless we were the ones
to digitize that line feature to begin with.
Instead, let's consider another option here.
I can use a tool known as generate points along line
to generate points at a fixed interval along a line segment.
So in this case,
I'm inputting that same long trail segment that I used
for my Viewshed a minute ago and I'm specifying
that I want points to be located every 100 meters
along that line feature.
I've also indicated that I want to include the end points
of my line feature.
Here's the result of that tool shown here on the left.
On the right hand side, on the top,
I've opened the long trail segment attribute table
to see that the shape length is about 2,250 meters.
Remember that we specified a 100 meter interval
as well as the inclusion of the start and end points
in the creation of those points along that line.
If I look at the attribute table for the output
of this operation, I see that I've got 24 points
that were generated.
At 100 meter spacing
and including the starting and ending points,
that seems about right given the input shape length
of that line feature.
From here, I can compute the Viewshed using those points
that I just generated as my observer locations.
Notice the output, in this case,
it ranges from zero to 20 observers
but the same general pattern of visibility
is revealed from this analysis.
And here I compare the two with the line result
on the left and the point result over on the right.
Now that's a visual comparison.
Suppose I want to go into a bit more detail
and compare the two outputs.
Well, I could look at the percent
of each of the observation points
that can see a particular location.
That way, I'm comparing a standardized value
between the two outputs.
So in this case, I'll use the divide tool
and because I know I had 24 points in that data set
that I generated, the point dataset,
I'll divide my Viewshed points, that output raster, by 24.
Now we see the result of that over on the right hand side,
a raster dataset with values of all zero.
Well, what do you suppose is going on here?
Note that my input raster is of type integer
and the value that I specified as the divisor
is also of type integer.
This means that ArcGIS will by default
write an output raster dataset that is of type integer.
And since the only options then are zero or one,
ArcGIS will round down to the nearest available number,
in this case, all zeros.
So how do we fix that?
Well in this case it's actually a pretty simple fix,
although not maybe the easiest thing to identify clearly.
Instead of entering 24 as my constant value,
I entered 24.0 and make that division.
Now that was the easy one, because remember,
I could see how many observation points
were generated along that line, 24.
What about for the other case where the nodes
and vertices are used for observation points?
In that case, if you want it to get at the number of
vertices included in your data set,
you need to go into the editing environment
and I can see that there are 746 nodes and vertices
associated with that segment of the long trail.
So I set up the divide tool the same way here.
Now I can compare the percent visibility of the two.
A couple of things to note.
Again, the visual pattern is mostly the same.
And interestingly, the range of values
is almost identical where the line percent visible
ranges from zero to 85%
and the point percent visible ranges from zero to 83%.
I could use raster calculator or the minus tool
to subtract one from the other.
In this case, I'm subtracting the percent of the points
that are visible from the percent of the line
that is visible to produce this output
over on the right hand side.
Once again, it's pretty interesting
to note the range of values there are almost identical
from the negative end to the positive extent,
but what we can see is that generally speaking,
there are more places where the line percent visible
is less than the point percent visible.
We see that because the output graphic is dominated
by those colors on the negative end of the spectrum.
So we've dealt with point observations
and line observations.
What happens when you have a polygon
and you want to compute the view from a polygon?
Well, you have a couple of different options here,
but this is one I really like to use,
the create random points.
So in this case, instead of trying to assess every point
within a polygon,
an impossible task I might note by the way,
we'll just create some random subset of points
scattered about the polygon itself
then we use the create random points geo processing tool
to do that.
Now you specify a constraining feature class,
in this case my trail buffer,
a buffered region around that trail segment
and you tell ArcGIS the number of points that you want,
I've specified 100 in this case,
and said that points are not allowed
to be closer than 10 meters together.
And here's the output from that tool operation.
I've got my 100 points scattered around that polygon
and now ready for use in the Viewshed tool.
I produce my Viewshed result
just like we've seen in past examples here.
I note that the polygon containing those points
is that dark red blob that you see
in the middle of the image on the left
and the Viewshed is represented in that blue color ramp.
Now, suppose I wanted to do another calculation here
that indicates the extent of my Viewshed.
In this case, I don't care how many people can see
or how many observation points a location is visible from,
just whether or not the location is visible.
I could use the reclassify approach where I say
that any cell value of zero stays zero
and any cell value from one to 100,
remembering of course that our maximum value
in this case was 98 should be converted to one.
I could also do the same exact operation
using raster calculator and a con function
where I specify that my random points Viewshed
if the value is greater than zero assign a value of one,
otherwise assign a value of zero.
Once again, either way will produce the same result.
So now I've defined the visible extent
from that polygon in question.
I could couple that once again
with the percent of observation points
that can see a particular location.
In this case, I'm dividing by 100
or I could use raster calculator to perform
that same computation.
And here's the output that I see
for my percent visible calculation
ranging from zero all the way up to 98%.
When I put the two next to each other, I get an indication
of the visible extent from the polygon of interest
as well as the percent visibility from that polygon,
potentially suggesting locations
that might receive further protections
if we're worried about the visual quality
from this important location within the center of town.
I think that's enough examples for me.
You're probably all ready to get your hands dirty.
Feel free to turn your attention to the lab assignment
and as always ask questions on YellowDig
and let me know if I can be of further assistance.