Using GeodesicViewshed

[mody_buchbinder]

Hello all

I would like to use GeodesicViewshed  (https://pro.arcgis.com/en/pro-app/2.8/tool-reference/spatial-analyst/viewshed-2.htm ) to make my visibility quicker.

I have some problems with the spatial reference.

Currently my DTM is UTM 36N.

The doc say "The input raster is transformed into a 3D geocentric coordinate system during the visibility calculation" Can I save (or project) my DTM into any other SR so it will transformed quicker?

Then the docs say  "should have a vertical coordinate system that has heights referenced to a spheroid"

My pixel values are in Meters. What is an example to such a vertical reference?

Should I Project or just define it.

Thanks

[JamesTenbrink]

Hi Mody:

> Can I save (or project) my DTM into any other SR so it will transformed quicker?

There will be some variation in speed based on the complexity of a particular inverse projection operation , but i don't think degrading your DEM by explicitly reprojecting is the way to go. 

To speed up the entire operation, including the initial 'creating a geodesic grid index...' phase, I recommend setting the 'outer radius' parameter (in the 'observer parameters' group) and using the smallest analysis extent possible. Both will be used by the tool to restrict the number of cell centers that need to be processed. The initial grid index generation phase is not gpu accelerated, but it does use multiple cpus, so you should specify as high a value as possible for the 'parallel processing factor' gp environment variable. 

> Then the docs say  "should have a vertical coordinate system that has heights referenced to a spheroid". 

> My pixel values are in Meters. 

You need to know if your pixel values are meters measured relative to a spheroid or to a geoid. Here's some info on that: https://pro.arcgis.com/en/pro-app/latest/help/mapping/properties/geoid.htm. Once you find that out, you can use the DefineProjection gp tool to tag your data with the appropriate vertical coordinate system.

The geodesic viewshed operation runs sightlines positioned relative to a spheroid. If your cell values are relative to a geoid (i.e. gravity related heights), then subtracting sightline elevations from surface elevations will have some error in it. You would need to check what the 'geoid undulation' values are in your analysis area to determine if the error is acceptable or not. A gravity model (such as egm 2008) will report undulations (aka 'anomalies') relative to an underlying spheroid (wgs 84 in the egm2008 case).

You can use the ProjectRaster tool to do a vertical transformation. You may need to download some support files for certain transformations (https://pro.arcgis.com/en/pro-app/latest/help/mapping/properties/arcgis-coordinate-systems-data.htm).

Here is some more info on datums: https://vdatum.noaa.gov/docs/datums.html

Here is info on a recent gravity model, egm 2008, used with wgs 84: https://earth-info.nga.mil/index.php?dir=wgs84&action=wgs84

Let me know how it turns out!

regards,

-Jim TenBrink

spatial analyst team

[mody_buchbinder]

Hi Jim

Thanks for the info, we finally made the GP work today.

On a machine without GPU it took 4 times longer even it uses 80% CPU. The visibility command uses one cpu only (12% in 8 core).

Does this make sense? is GPU going to make a big diffrent?

Thanks

[Anonymous User]

Hi Mody

GPU will help. GeodesicViewshed is very compute intensive. On my older laptop (dell precision 7540 with a quadro t1000 gpu) i'm seeing a 4x - 5x speedup when switching to gpu.

If possible, use the outer radius parameter to restrict how far sightlines are run.

Newer gpus with more compute units should do better. I'm working on getting some performance numbers comparing the ampere a40 to the a100. The latter has more support for double precision floating point operations, which geodesic viewshed uses intensively.

-jr

[Anonymous User]

Hi Mody:

I just tried an nvidia a6000. The job that took over 5 hours on my laptop cpu took 10 minutes on this gpu! (the same job took about 40 minutes on the laptop gpu, a quadro t1000). The a6000 has lots of compute cores (nice) and lots of single precision floating point compute power (not so useful for geodesic viewshed).

I'm trying to do the same test on an a100 but haven't been able to access one in aws yet. I suspect that performance on the a100 will be spectacular because of all the double precision compute power this card has. 

To me, it looks like nvidia is starting to prioritize FP64 compute. The next line of cards coming out, Hopper, will have even more of that.

Regards,

-jt

[mody_buchbinder]

Hi Jim

I have done some testing.

I have a strong machine (i7 11 series) with graphic card Quadro P5000

test on 16bit signed int raster and with 32bit float.

Run Visibility command on projected raster (ITM) and the Geodesic Viewshed on Geo (4326) raster.

Pixel is 15 meter the test was for 75Km outer radius.

visibility tool (not using GPU) took around 35 seconds.

Geodesic Viewshed took 1:53 on the float raster and 2:18 on the int.

When I disable my graphic card the same operation took about 6:30

Maybe other card will do better?

[Anonymous User]

Mody:

It will be tough to get performance as good as visibility tool. Visibility does not run independent sightlines to each raster cell, it uses an approximate expanding rasterized horizon, so there are more interpolation errors. It also assumes that straight lines on the map are straight on the ground. If that's good enough for your purposes, then use visibility (you should compare results between visibility and geodesic viewshed , along with some ground checks if possible).

Here are a couple of things to check and some additional suggestions.

What percentage of the time is being spent building the grid index for the gpu test? Look for this progress bar message while running the tool interactively:

You'll have to eyeball the time, since this isn't a gp message and doesn't have a time stamp associated with it. If you have lots of observers, there may be multiple observer groups, each requiring a different grid index.

Grid index building is not gpu accelerated. The difference between total time and index build time is what's actually being spent on the gpu. Grid index generation does use multiple cpu cores though (all of them by default, or whatever's specified by the PPF gp env var). We're looking at ways to cache that work so it doesn't have to be recreated every time. For now, the best way to reduce that time is to keep the outer radius as small as possible, and also use an angular restriction if possible (anything to reduce the number of DEM cells that need to be processed).

Make sure your TMP/TEMP variables are pointing at a large fast SSD. That is where the grid index will be created.

You might try the 'perimeter sightlines' method instead of the 'all sightlines' method. The former only runs sightlines to raster cells on the boundary of the area being processed (the edge of the circle defined by the outer radius, for example). Its faster but more approximate (its still totally geodesic though). However, the perimeter sightlines method uses the grid index more, so the TMP/TEMP guidance above will be even more important.

An ampere class gpu would be faster for sightline processing, but i suspect most of the ~2 minutes your seeing for the gpu test are being spent building the grid index, so switching gpus won't help much in that case.

-jt