Available with 3D Analyst license.
The Viewshed 2 tool determines surface locations visible to a set of point or polyline observers, using geodesic methods. It transforms the elevation surface into a geocentric 3D coordinate system and runs 3D sightlines to each transformed cell center. It will take advantage of a graphics processing unit (GPU), if available on your system. It optionally accommodates vertical uncertainty or error in the input elevation surface. It also optionally produces an observer-region relationship table for up to 32 observers (points, multipoints, or polylines) that can be related back to the input observer feature class.
Since the computation is performed in a true 3D coordinate system, Viewshed 2 does not need the earth curvature correction parameter. It also uses the z units of the input spatial reference, if available, rather than a z-factor parameter. Finally, since each 3D sightline is evaluated independently of other sightlines, it avoids some of the errors that can creep into a wavefront-based viewshed algorithm (such as the existing viewshed family of geoprocessing tools). Thus, the Viewshed 2 tool produces more accurate visibility and AGL surfaces than the Viewshed tool.
The determination of visibility
This tool uses geocentric 3D points for observers, targets, and elevation surface cell centers. A target is a surface cell center that has an optional, additional offset added to it. A geocentric 3D coordinate system is a right-handed Cartesian coordinate system with the center of the earth as the origin C, the x axis pointing to the intersection of the prime meridian and the equator, the Z axis pointing to the North Pole, and the y axis rotated 90° clockwise from the x axis while looking down from the North Pole. See the following figure for an example of a target location T expressed with geocentric coordinates.
To determine the visibility of each target, 3D sightlines from each observer to each target are constructed. See the figure below for an illustration of how the sightlines are constructed. The ground path of each sightline on the spheroid is determined and divided into cell size steps. In this figure, the steps are shown as the green dots, and the distance between them is equivalent to the cell size. At each step, the distance d along the normal to the spheroid, between the sightline and the surface, is calculated. The elevation of ground is estimated using a linear Inverse Distance Weighted (IDW) approach using the nearest cell centers. If d is positive for all ground steps along the sightline, then the target is considered visible; otherwise, it is considered not visible.
The ground path of each sightline on the spheroid is determined and divided into cell size steps. At each step, the distance d along the normal to the spheroid, between the sightline and the surface, is calculated. The elevation of ground is estimated using a linear IDW approach using the nearest cell centers. If d is positive for all ground steps along the sightline, then the target is considered visible; otherwise, it is considered not visible.
Vertical error
The Vertical error parameter is only enabled when the analysis type is FREQUENCY. It is used to account for the vertical uncertainty in the input elevation surface. When this parameter is 0 or not specified, a single sightline is cast between the observer and each target. The result is that the target is either visible or not visible. In this case, the output visibility raster records the number of times that each cell location in the input surface raster can be seen by any of the input observation points.
When the Vertical error parameter is greater than 0 (for example, 0.6 meters), some number of sightlines are cast between the observer and each target. For each sightline and each step, a uniformly distributed random number in the range of [-0.6, 0.6] is added to d. If d becomes less than zero, that particular sightline is terminated. In this case, each observer contributes a number between zero and one (the number of successful sightlines divided by the total number of sightlines, from that observer) to the output visibility raster, which is now of type single-precision float.
The determination of AGL
An Above Ground Level (AGL) raster is an optional output that represents the above ground height that the nonvisible target cells would need to be raised by in order to become visible. The following figure illustrates how the AGL value is determined. T is a target with a certain height (which is the target offset in the illustration). The sightline between the observer O and the target T is blocked by the terrain, so target T is not visible. If the target is raised to the new position T’, then it becomes visible because there is now a clear sightline. The distance between T’ and the ground is the AGL value in the output raster.
The computation of distance TT' does not assume that triangle OTT' is a right triangle.
Interpreting the output observer-region relationship table
When the analysis type is Observers, the tool outputs an observer-region relationship table, as shown in the following figure. In this table, the Observer field lists feature IDs from the input feature class. The Region field lists cell values in the output visibility raster. Thus, the table lists the regions that are visible to each observer. You can use this table to look up the region IDs given an observer ID, and vice versa.
The same information is encoded in the output cell values of the visibility raster, but in a less accessible way. The input observers are sorted in ascending order by their FID values, and the output visibility map reports the bitwise OR of their sorted positions. You can use Map Algebra to extract information about which observers can see which regions, and that information can be related back to observer features using this sorting rule. An example is shown in the figure below. Assume that Observer 1 has FID 1 and Observer 2 has FID 2. Then Region 1 in the output visibility map will have a cell value of 1 (the rightmost bit is set). Region 2 will have a cell value of 2 (the second bit is set, counting from the right). And Region 3 will have a cell value of 3, the numeric value of the bitwise OR of the first and second set bits.
In the illustration above, the output cell values are the bitwise OR of the internal indexes of the input features. The observer-region relationship table reports this same information using feature class IDs instead of internal indexes.
Controlling the visibility analysis
It is possible to limit the field of view for each observer by specifying various numerical values or fields in the observer parameters. These observer parameters are functionally the same as the view cone fields—such as OFFSETA or OFFSETB—used for controlling the visibility analysis by the Viewshed tool. The difference is that the Viewshed 2 observer parameters can take any numerical fields and are not limited to any specific field names.
Use of a GPU
A Graphics Processing Unit (GPU) is a hardware component that accelerates the rendering of graphics in the screen display. It can also be used for general computing tasks. The Viewshed 2 tool is GPU accelerated, which means that a GPU may be used in the visibility calculation if present. Currently, only NVIDIA GPUs with CUDA compute capability of version 2.0 or greater are supported. If only one GPU is present (which is connected to the display), this GPU will be used and a warning message will be reported at tool execution time. If multiple GPUs are present, one not connected to the display will be preferred. If no GPU is present, the tool will use as many cores of the CPU as are allowed by the Parallel Processing Factor geoprocessing environment value.
When a GPU is used in the Viewshed 2 tool computation, the computation is divided into many small portions and sent to the GPU for processing. It’s possible for the window display device driver to reboot the GPU if any individual portion of the computation takes longer than 2 seconds. This is known as Windows Timeout Detection and Recovery (TDR). If this happens, the tool execution may fail. To prevent this issue, a registry key (TdrDelay) will need to be either created or updated to use a larger value (for example, 60 seconds). The Microsoft Developers Network has more details on setting TDR Delay
. Note that when you create or change this registry value, you should make a backup of the registry first. You must reboot your machine for the change to take effect.
For spatial analysis using a GPU, Esri recommends a machine with two GPUs: one being used for display and one being used strictly for compute. For NVIDIA GPUs, the compute GPU should be set to use the Tesla Compute Cluster (TCC) GPU driver, rather than the default Windows (WDDM) display driver. The release notes provide details on how this is done. TCC mode allows the compute GPU to operate more efficiently. It will also then be accessible from a remote desktop session. Esri also recommends that the ECC mode for the GPU (GPU RAM error detection and correction capability) not be enabled, since it reduces the memory available on the GPU and increases the expense of GPU memory accesses.