Overlapping Viewsheds
When you have many observers with overlapping viewsheds, displaying them all may become messy. The most powerful way to handle this issue would be to replace the LineOfSightOperator with an AirspaceCoverageOperator, since it can both compute and merge viewsheds (see also the chapter AirspaceCoverageOperator: What can we see together?).
The rest of this chapter was written before the airspace coverage operator was introduced, and describes a more basic way to handle overlapping viewshed surfaces (but not overlapping viewshed volumes). The chapter may still be useful if you do not want to define a specific minimum number of required observers and instead want to visualize the number of observers that cover each area. The chapter could also be useful if you produce overlapping results with a LineOfSightOperator.CustomPropagation whose PropagationOutputType is Other, since that output type cannot be produced by an AirspaceCoverageOperator at all.
Merging Viewsheds from LineOfSightOperator
If you only care whether a region is visible by any observer, you may want to merge the viewsheds from all observers into a single raster. The correct way is to send the output from the LineOfSightOperator to a RasterMergeOperator with operation = Min. See LineOfSightOperator for details. Or, if you need to handle heterogeneous elevation rasters, see Multiple Resolution.
If you want to see how many observers that can see a region, then a semi-transparent visualization may work, if the observers are sparse. Below, we show the viewsheds of radio beacons (of type DME) for flight navigation, each one displayed separately by a RasterVisualizer with the following color table:
 |
meaning that visibility heights in the range 0 - 2000 meters are shown in red. The RasterVisualizer.Alpha is 31, so that an isolated viewshed becomes nearly transparent. The background is generated by a ShadeOperator.
 |
In the west half, you can see the difference between zero, one, two, and perhaps three overlapping viewsheds. But in the east half, there are many radio beacons around Arlanda, so their overlapping viewsheds obscure the background shading, and their boundaries are hard to see.
A better idea is to reclassify the viewshed rasters, so that a visibility height in the range 0 - 2000 m is replaced by some positive value, say 10, while other visibility heights are replaced by zero. The results are then summed to one raster by a RasterMergeOperator with operation = Add. The summed raster will contain the value 10n in each cell that can be seen from n observers. So we can use a better RasterVisualizer, based on a traffic-light analogy: one beacon is not enough (red), two beacons are so-so (yellow), and three beacons suffice (light green). More beacons are even better (darker green colors). But zero beacons would be useless (invisible).
 |
By using a RasterVisualizer with the color table above and With alpha = 90, we get a much better the result:
 |
One can clearly distinguish between regions seen by 0, 1, 2, 3, 4, 5, and more than 5 observers, and the height shading is not obscured.
However, it is difficult to see what regions can be seen by one particular observer. So, let us select the BORLÄNGE beacon:
 |
That is better, but how was it done? Well, the inverted colors of the BORLÄNGE symbol are simply displayed by a Visualizer in a VisualizationOperator.SelectionVisualizers (used only for beacons that are selected). But the blue outline of the viewshed was harder to achieve. It is displayed by a separate layer, where the original output from a LineOfSightOperator is passed to an IsolineOperator that generates an isoline at 2000 meters. The difficulty was to ensure that the isoline was generated only for selected beacons, since the built-in support for selection visualization cannot be used here. We solved it by some application code:
A custom operator, MarkSelectedOp, that can remember a list of feature identities, and later, during an update, assign a new attribute SELECTED = True to each incoming feature whose identity appears in the list.
An application method that reacts to the View.SelectionChanged event, by asking the MarkSelectedOp to remember all feature identities from View.GetSelectedIds.
The proxy for MarkSelectedOp is placed between the LineOfSightOperator and the ReadOperator for beacons, where it will add the attribute SELECTED = True to all beacons that are selected. For each beacon, its SELECTED attribute will survive the LineOfSightOperator; that is, the attribute will appear on the viewshed rasters for the beacon. So it easy to insert an FilterOperator that allows only viewshed rasters with SELECTED = True to reach the IsolineOperator. Here is a screenshot of the configuration:
 |
An isoline of a viewshed can become quite fractured and hard to visualize well, if the LineOfSightOperator.MinVisibilityHeightType is AboveGround or AboveTreetops. Fortunately, it was AboveSeaLevel in these examples, and this setting will usually give isolines of a simpler shape.
Turning off Individual Results
As you know, you can turn off the display of all viewsheds - assuming they are in the same layer - by letting Layer.Enabled be False.
When viewsheds (or visibility indexes) overlap, it can be useful to turn off an individual observer temporarily. You can allow the application user to edit a Bool attribute SHOW on each observer, and let an FilterOperator remove the observers whose SHOW is False, before the observers arrive to the visibility operator.
Previous: Properties of the Sensor
Up: Visibility Analysis
Next: Length Units for Visibility Analysis