Simultaneous viewsheds for thousands of point locations

[chrislowrey]

Hi all, I have many thousands of bighorn sheep location data and need to calculate the 500 meter radius viewshed for each point individually. However, many points are closer to each other than 500 meters and those points are interfering with each other in terms of overlapping viewsheds. I need to calculate each one without interference from the others. Any ideas are most appreciated! Chris.

[ThomMackey]

Hi Chris,

Can you provide a bit more detail about your problem?

• Are your sheep locations stored as a point feature class or in a raster grid?


• What are you using as a visibility surface input to your viewshed?


• How are you currently performing the task? Have you written a script?


• What kind of "interference" do you mean?


• Exactly what final outcome are you trying to achieve?

Sounds like a lot of questions but I think everyone will be able to provide better help with a little bit more detail 🙂

Generally speaking, if you're using a DEM as the visibility surface and have the sheep locations as a points feature class, I can't see why a simple script to loop over each point wouldn't do what you're asking.

Cheers!

[chrislowrey]

�?�Thanks for the reply!!

Are your sheep locations stored as a point feature class or in a raster grid?

Feature class

�?�What are you using as a visibility surface input to your viewshed?

A digital elevation model (DEM)

�?�How are you currently performing the task? Have you written a script?

We are in dire need of a script

�?�What kind of "interference" do you mean?

We need to run the points 1 at a time so they don't overlap during calculation. We need to know what the animal sees from 1 point, then the next point, without the script calculating both (or all) points simultaneously.

�?�Exactly what final outcome are you trying to achieve?

Area that an animal sees out to a certain point (example: how many square meters are visible out to 1 km)

Any script help is most appreciated!! Chris-USGS.

[JeffreyEvans]

A conceptual framework for this analysis is to create an empty point feature class and then start a loop:

for ( i in 1:number of points ) {
  Subset point i
    Create a buffer of n distance
      Clip elevation raster to buffer
        Perform viewshed analysis on subset dem
      Assign [(number of cells == 1) * cell size] to subset point
    Append subset point to empty feature class
  Next i
}

I have coded this up in R using GRASS to perform the viewshed analysis. If you would like this code please contact me off list (jeffrey_evans@tnc.org).

[ThomMackey]

Hi Chris,

I made a model which seems to do what you want. A bit simpler than a script, although I can't speak to the speed or efficiency, especially over thousands of points (though it shouldn't be too bad, I'd be surprised if the R/GRASS combo wasn't faster).

I made it in 10.1, so if you have 10.0 you might not be able to open it... I'm not sure how to save toolboxes as older versions, or if it's even possible. Here's a picture of the layout if you need to reproduce it.

[ATTACH=CONFIG]18028[/ATTACH]

The process is exactly the same as Jeffrey outlined above. The expression in the calculate value tool is %visible_cells% * %cell size%. The rest should be self-explanatory if you're familiar with modelbuilder.

Hope that helps 🙂

[JeffreyEvans]

Depending on the goals of your analysis you may want to consider some alternatives to viewshed analysis. Based on the description of your data it sounds like you may want to build some sort of occupancy model and use visible area as a covariate. I would like to point out that if you want to eventually make a spatial estimate of niche occupancy probability that you will not be able to do it with this parameter because of the lack or complete spatial coverage. There are may topographic metrics that may explain the same variation. One alternative that comes to mind is terrain openness (Yokoyama et. al., 2002). Although, compared to other methods, the tractability of this computation has been called into question and there is not an ArcGIS implementation. There is however, a web service available (Luo et. al., 2009). Some other alternatives may be some of the texture measures. I would imagine that rugosity at a large window size would possibly correlate with openness. I have an ArcToolbox that has several scalable metrics that may prove relevant. Also, Jeff Jenness has an ArcGIS addin that calculates some relevant topographic metrics.     

Yokoyama R, Shirasawa M and Pike RJ, 2002, Visualizing topography by Openness: A new applicationof image processing to digital elevation models. Photogrammetric Engineering and Remote
Sensing, 68(3): 257-265. 

Luo et. al., 2009 - Terrain Openness Web Service paper
http://www.lpi.usra.edu/science/stepinskiWebPage/pdfFiles/geoinformaticsConf2009.pdf

Geomorphometry and Gradient Metrics Toolbox
http://conserveonline.org/workspaces/emt/documents/all.html

Jeff Jenness DEM Surface Tools
http://www.jennessent.com/arcgis/surface_area.htm

[chrislowrey]

Thanks to everyone for your efforts! Most appreciated!! C.Lowrey  USGS

[EricRice]

Greeetings,

It's extremely inneffective to buffer the points, and subset the DEM based on each buffer for input into Viewshed. All you have to do is give each point an attribute for Radius1 and Radius2. R1 should be 0, and R2 should be the distance you would have otherwised buffered with. See, How Viewshed works, especially the section called 'Controlling the Visibility Analysis'. You probably should make use of OFFSETA as well.

Since the goal is to determine the area that an animal sees, rather than what he sees you probably don't even need to keep the actual viewsheds. You should set the output to an in_memory workspace. You could also probably shorten the model by avoiding all the field calculations to determine area. Instead, insert the in memory viewshed result into the Zonal Geometry As Table tool (also use in_memory here). It will tell you the area of both visible and not visible for each iteration.

To save a toolbox to a previous release, right click on it and go to Save As, then pick the previous version.

Best,
Eric

[ThomMackey]

Thanks Eric. Very useful. I forgot about the Zonal Geometry tool �?? that's a much better solution. I'd also remembered how to do the export to an older version.

I had problems using the in_memory workspace for rasters in ModelBuilder, although it works for Python scripts.

Is there any chance you can explain why it's more effective to use the Radius2 parameter than clipping out the raster? Does the R2 parameter apply a dynamic mask to the layer or something? I presumed that an issue with using the R2 parameter is that you're limited to using the units of the SR of the input raster, which doesn't make for a very versatile tool, and much elevation data isn't projected so it'd be tricky to accurately calculate a distance in DD for each feature. Is that not true? I can see that the raster clip operation is probably expensive and best avoided, but I don't see a reliable way of getting a consistent distance otherwise. Or can you work around that by using the output coordinate system environment setting?