nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Changes to Viewshed tool between ArcGIS 9.3 and ArcGIS 10.3

AlexanderKeyel

I am updating a toolbox from ArcGIS 9.3 to ArcGIS 10.x. When I run the viewshed tool (in either Spatial Analyst or in 3D analyst), I get a different result than I obtained in ArcGIS 9.3. Any idea what is causing the discrepancy? Is there any documentation regarding the tool change?

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

DarrenWiens2

Can you provide an image showing the discrepancy? I'm just curious if it's totally different, or some subtle change in the algorithm.

AlexanderKeyel

The differences are a bit subtle, so I subtracted the one layer from the other to highlight the changed output.

ArcGIS 9.3 version (above)

ArcGIS 10.3 version (above)

Difference between ArcGIS 9.3 and 10.3 (blue = no difference, white = in view in 9.3)

AlexanderKeyel

Following Dan Patterson's advice on another thread,

Re: PathDistance Calculation discrepancy

I made a test landscape to try to identify the discrepancy in the Viewshed tool (PathDistance is next on my to-do list). It didn't help me solve the existing problem as Arc9.3 and Arc10.3 gave the same answer in the test landscape, but it added a NEW problem: in a flat landscape, I got very strange results where the point of origin was not in view! Also note that flat points to the north (or a very high point to the N) are not in view, but points to the east of the same elevation are.

Cell size is 30 m x 30 m.

I'm not sure if the pictures loaded (it just says Viewshed.tif instead of the image on my screen), but this is even more concerning than the first problem.

Viewshed.tif

Viewshed_legend.tif

Landscape.tif Landscape_legend.tif

Any ideas why I'm getting this behavior out of the tool? I can't see any way for the origin cell to be out of view, nor for a nearby high point (curvature of the earth isn't THAT great)

DanPatterson_Retired

have you set the observer point be a small amount (1 or 2 meters) from the terrain? I have had weird results reported to me from time to time when there is no offset

AjitKumarBabar1

I think the result from 10.3 is more accurate.

Why don't you try with new added viewshed2 tool in ArcGIS for Desktop 10.3

Viewshed 2—Help | ArcGIS for Desktop

DanPatterson_Retired

Since there is no information in the change logs regarding the viewshed tool between the versions, nor any indication as to any changes in the algorithm .... which would be a huge error of omission ... what makes you think that the results are more "accurate" in the newer version. Have you tested the functions on devised surfaces to confirm that there has been a change?

Alexander indicated that there were no differences on devised surface. He did find that for a flat surface that there is a behaviourial issue. Hence, my suggestion to elevate the observer point by some small amount to see if it was a floating point or other numerical problem in the returned results. In reality, no one observes a landscape buried neck deep in a hole with the surface mid-point in the eyeball in any event.

In the help topic Viewshed—Help | ArcGIS for Desktop

there are several places that need addressing

curvature_correction

(Optional)

and

(Optional)

The output above ground level (AGL) raster.

The AGL result is a raster where each cell value is the minimum height that must be added to an otherwise nonvisible cell to make it visible by at least one observer.

Cells that were already visible will have a value of 0 in this output raster.

should be derived to ensure that the former is considered (unlikely given the overall distance) and the latter (to assess the degree of offset needed0

Viewshed 2 uses geodesic methods Viewshed 2—Help | ArcGIS for Desktop and the reader is directed there for details. The use of a version number, does not mean that Viewshed 2 is better than Viewshed, but that it is a second alternative to situations that are not well modelled otherwise.

DanPatterson_Retired

sharing to the spatial analyst

AlexanderKeyel

Dan Patterson for the offset in the viewshed tool, do you typically just add the offset to the input raster? I did not see an option for an offset in the tool itself.

CORRECTION: with the offset correctly applied, ArcGIS 10.3 now gives a plausibly correct answer. I still have no idea what's going on in the ArcGIS 9.3 version.

With the viewshed tool, using a 6ft offset (sorry, my data are in ft for historical reasons), here is what I get for ArcGIS 10.3 for the white-labeled point 1:

Green is in view, gray is out of view

I'm using the "FLAT_EARTH" and 0.13 (default settings) for the viewshed calculations.

The results are now coming out differently in Arc9.3 (assuming I coded everything correctly), also with "FLAT_EARTH" and 0.13:

Note the weird invisible line extending out northward from the source point. Otherwise everything looks good in 9.3. No above ground level raster as that was not an option in the viewshed tool back in 9.3.

And here is the test landscape for reference:

I also tried the viewshed2 tool with a 1 m offset, and the results were improved, but the above ground raster showed one cell requiring a 12 m offset when it was the same height as the surrounding cells!

Above_Ground_raster.tif

I'm also getting NoData for some of the border cells, even though I'm setting both snapraster and the extent.

The viewshed2 tool is also not ideal, as I'm hoping for backward-compatibility with earlier versions of ArcGIS 10.

With respect to the line-of-sight calculations - thanks for the amusing mental image of a person buried eyeball-deep in the ground, but we're actually interested in this for noise propagation purposes, so it's not that implausible that a noise source would be located on or near the ground.

AlexanderKeyel

I didn't know about the viewshed2 tool. Unfortunately, I'm not getting good results with it either! (see longer response to Dan P. above).

DanPatterson_Retired

I always use observer points as a separate file, so I can't comment on whether your approach produces similar results. I put them into the table, since they can be varied and you can control more options... see below.

The feet meter thing.... arrrrg. make sure that everything is in one coordinate system and units are all the same (aka meters )

I will look in more detail soon, but have a look at the below so I am sure that everything is as it should be

Configuration of inputs for viewshed and visibility analysis

Using Viewshed and Observer Points for visibility analysis—Help | ArcGIS for Desktop

the inputs are generally located in the observer point table as in... from the help topic

Controlling the visibility analysis

It is possible to limit the region of the raster inspected by specifying various items in the feature attribute dataset, such as observation point elevation values, vertical offsets, horizontal and vertical scanning angles, and scanning distances. There are nine items in total: SPOT, OFFSETA, OFFSETB, AZIMUTH1, AZIMUTH2, VERT1, VERT2, RADIUS1, and RADIUS2.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.