Viewshed 2 geoprocessing package in Runtime SDK

992
6
02-21-2018 03:08 PM
jkDfGrt3K8Dw
New Contributor II

Hi, I'm having trouble getting good results from Viewshed 2 as a GeoprocessingTask.

System info:

-- Runtime SDK version 100.2.0 for Qt, C++ API, Windows.

-- Runtime Local Server for Qt 100.1.0 (not 100.2.0, if that matters)

-- NVIDIA Quadro K4200 GPU (CUDA compute capability 3.0) with latest drivers

Inputs:

-- Observers are Point features

-- Elevation source is a SRTM .hgt file

First, I used the Viewshed analysis class with good results. I was able to see a reasonable looking viewshed using a LocationViewshed object. I added the SRTM DEM as an elevation source to my Scene and it worked great.

Now I'm trying to do the viewshed as a GeoprocessingTask using the same observers and same elevation source. The GeoprocessingJob object accepts my input observer features and other parameters, and successfully returns an output raster, but the result is not what I expected.

The observer is located a few meters above the DEM (observer offset ~5 meters) with a horizontal FOV of approximately 15 degrees and a vertical FOV of approximately 60 degrees. The inner and outer radii are set to 5 meters and 16 km respectively.

The screenshot shows the observer point (the yellow square), with the Viewshed 2 output raster overlaid onto the Scene. The viewshed is the black region.

On the left, using the ALL_SIGHTLINES mode, the viewshed shape doesn't seem to be influenced by the terrain; it only appears to be limited by the azimuth and radius ranges that I set. Considering that the observer is at sea level viewing a mountain range of around 1000 meters elevation, the viewshed should not extend behind the mountains.

On the right, using the PERIMETER_SIGHTLINES mode, the viewshed appears to be limited by terrain features. The bottom picture shows that more clearly.

Why might I be having trouble with the ALL_SIGHTLINES mode?

0 Kudos
6 Replies
EricBader
Occasional Contributor III

Hi Martin,

Is there any chance you could show us your code?

Is there a reason why you still need to use LocalServer 100.1 and not 100.2?

Thanks

0 Kudos
jkDfGrt3K8Dw
New Contributor II

Yes, I'm putting together a minimal example and will get it to you shortly--thanks for offering to take a look.

There wasn't any reason why I had previously used Local Server 100.1, but I tried 100.2 just yesterday and had the same result.

0 Kudos
jkDfGrt3K8Dw
New Contributor II

Here is a "minimal" reproducible example. I was hoping to create the observer feature table in memory using a FeatureCollectionTable but couldn't get that to work, so it instead pulls from a .geodatabase with a single table containing one feature.

If you switch the "analysis_method" GeoprocessingString from ALL_SIGHTLINES to PERIMETER_SIGHTLINES, you should be able to get the results I described earlier.

Thanks for looking into this.

0 Kudos
jkDfGrt3K8Dw
New Contributor II

I was able to get results by forcing Viewshed 2 to compute the viewshed using the CPU. A temporary rough fix is to set environment variable CUDA_VISIBLE_DEVICES to a value that excludes CUDA devices, e.g., CUDA_VISIBLE_DEVICES="". However, this disables CUDA processing for the duration of the program execution, which has obvious performance implications both for the viewshed and for other operations that use CUDA. If there is a way to disable support on a per-service/task/job basis, that would be better.

EricBader
Occasional Contributor III

Good find. We need to fix this. Thanks Martin.

0 Kudos
JamesBallard1
Esri Regular Contributor

Martin Jaszewski‌, can you try setting CUDA_VISIBLE_DEVICES to either 0 or 1 and see if that helps the issue?

There's a bit more information here related to configuring the GPU GPU processing with Spatial Analyst—Help | ArcGIS Desktop  (see GPU configuration).

Please let us know if that helps.

0 Kudos