Multiple Resolution
Single Resolution
If you have elevation data in a single resolution only, the visibility operators can become slow if the resolution is high and the VisibilityOperator.MaxDistance is long.
Homogeneous Multiple Resolution
To improve performance, you can generate elevation data in pyramidal resolutions. See for instance DtedDataSet.RasterCachePolicy for more information. See VisibilityOperator.FirstResolutionChange and the Line of Sight Configuration Tutorial.
Heterogeneous Multiple Resolution
Sometimes, we have only heterogeneous data. That is, the best resolution is available in a limited region only, while lower resolution must be used elsewhere. We shall see how such data can be used by a LineOfSightOperator. The example configuration can also be found as .../samples/MapConfigurations/line_of_sight_heterogeneous.px.
With heterogeneous elevation rasters, we would like the LineOfSightOperator to use the highest possible resolution for each observer. Ideally, each little piece of each line of sight should be computed in the highest resolution that is available locally, but this has not been implemented. But a viewshed from an observer is computed in the best resolution that is available near the observer.
To demonstrate this design, we can use the Lake Tahoe sample data.
In a small area around the lake, we have a fine elevation raster with 10 m resolution, expressed in a Crs known as NAD27 / UTM zone 10 North. Around the boundary of the data, there are elevation cells with the undefined value, and the default visualization by a ShadeOperator will show these as if they were flat ground:
 |
In a larger surrounding area, we have coarse GMTED 2010 elevations, expressed in Wgs84LongLat (resolution 30 * 30 arc seconds, or about 730 * 920 meters). We show them here with a NearestNeighbor filter on the ShadeOperator, to emphasize the difference in resolution. (They would look smoother with a Bilinear or Bicubic filter.)
 |
The simplest way to show both resolutions together, is to place them in separate layers, and display the high resolution layer last. However, the undefined elevations in the high resolution must be shaded with the transparent color, so they do not hide the valid low-resolution data behind them. To do this, we set outputUndefinedValues = True in the fine ShadeOperator. The result will look like this (we have also highlighted the boundary by a dotted line).
 |
This design works only when the shade layers use completely opaque colors, otherwise the coarse shades would be semi-visible behind the fine shades. But opaque shades are enough for our purposes here. To handle semi-transparent colors, one could have used a single ShadeOperator that takes input from a FunnelOperator that is connected to both the read operators.
The design with the funnel operator is, in fact, just what we need to use both elevation datasets in a LineOfSightOperator.
 |
The result looks like this:
 |
The line-of-sight operator will probe its elevation input to determine the highest available resolution near each the observer. It will then demand this basic resolution as far away as it needs, and will resample incoming data if necessary. (Farther away from the observer, the line-of-sight operator may demand elevation data in a series of lower resolutions, resampling the input again if necessary; see VisibilityOperator.FirstResolutionChange.) So, since the west observer is located where we only have coarse GMTED 2010 elevations, its entire viewshed is computed in this resolution. The east observer is located where we have 10 m elevation data, and the viewshed is computed in high resolution (well, actually in a series of resolutions of 10 m, 20 m, 40 m, etc., due to the VisibilityOperator.FirstResolutionChange). Note that the east part of the east viewshed is computed in elevations that have been upsampled from the coarser GMTED data. So, this part of the viewshed looks more accurate than it probably is.
You may have some reason to merge many viewsheds to a single raster. If so, you can insert a RasterMergeOperator to the left of the LineOfSightGenerator, with operation = Min. This method to merge viewsheds has been mentioned elsewhere (see Line of Sight Configuration Tutorial and Overlapping Viewsheds), but in the heterogeneous setting, such a RasterMergeOperator should have resolution = ViewRelative instead of the default RasterRelative. This is usually not necessary if you merge viewsheds from homogeneous elevation data (due to an implementation trick: for each observer, the first output raster from a LineOfSightOperator is a dummy raster intended only to specify a good resolution for a subsequent RasterMergeOperator; but if you merge many viewsheds of different resolutions, this trick fails to work.)
Previous: Trees as Obstacles
Up: Visibility Analysis
Next: Accuracy