VerticalProfileOperator.LandCoverInput Property
Gets or sets the input operator that gives land-cover rasters.
Syntax
public Operator LandCoverInput { get; set; }Property Value
Default: null
An operator that gives a thematic raster that represent land cover: forest, shrubs, city, etc.
Remarks
A LandCoverInput should give a thematic raster with land-cover types coded as integers, and it should normally be used together with a LandCoverHeightInput that gives raster data with the land-cover heights above ground. If you have a data source for the LandCoverInput, an easy way to generate data for the LandCoverHeightInput is to reclassify the land-cover codes into estimated heights, for example using a RasterReclassificationOperator or a ImageQuery.ReclassificationByAttributeTable. So, you could reclassify the integer representing Water to 0 meters and the integer representing Forest to 25 meters, etc. But in general, the raster data from these two inputs do not need to be correlated in that way: instead you might have detailed raster data with accurate measurements of land-cover height above ground, in which case terrain cells containing Forest could have different heights above ground.
The operator will use these two inputs to generate features representing the land cover. Each homogeneous piece of land cover along the profile route will be represented by two output features: a polygon, and a line that follows the top of the polygon. The features will get an integer attribute vpopLandCoverCode that contains the code for the land-cover type in the raster.
 |
Of course, the integer attributes would usually not be displayed as numbers, but just used to control colors and line widths, etc. In the configuration sample vertical_profile.px, the integers are also used to generate text labels when zoomed in.
In most cases, it would have been enough if the operator had just generated the polygon features, which could be given both line visualizers and polygon visualizers. But the generation of the top lines as separate features can allow more varied visualizations.
Land-cover inputs should not be used together with TileLayer.AutoThin = True, since the thinning can cause gaps and overlaps between the land-cover features and the ground feature.
Since the land-cover heights are assumed to be heights above ground, the land-cover inputs can be used only if ground elevations are available as well. So, if the land-cover inputs are not null, then the operator will assume that the first ordinary numeric raster feature from ElevationInput contains ground elevations above sea level. And if no raster feature with ground elevations comes from ElevationInput, the land-cover inputs will be ignored. In this context, if the ElevationInput produces the special volume-encoding rasters from a AirspaceCoverageOperator, they will of course not be regarded as representing ground elevations.
Missing land-cover data
Once the operator has received a ground elevation raster from ElevationInput, it will generate land-cover features if at least one of LandCoverInput and LandCoverHeightInput differs from Null. The land-cover features will be generated along the entire ground profile line, even if there are some places along the route line that are not covered by the input land-cover rasters, or places where the land-cover rasters contain their undefined value. In order to do this, missing land-cover types will create land-cover features with the attribute vpopLandCoverCode = -99, and missing land-cover heights are assumed to be zero.
However, although the land-cover features will be generated, the automatic visualization from the operator (see more below) will assign a completely transparent color to land-cover features with vpopLandCoverCode = -99. If you regard unknown land-cover types as a risk for aircraft and you want to highlight them, you have to provide your own visualizer for such features.
In the general case, there could be areas with well-defined land-cover types but undefined land-cover heights. This situation will generate features with automatic colors but zero height above ground, so it would not be obvious that their land-cover heights are really undefined. To highlight such land-cover features, you can increase LandCoverHeightDefault to 100, say, so that they become very high and noticeable.
Flight safety issues with land-cover data
Since the generated terrain profile might be used for aircraft mission planning, the operator should never underestimate the terrain elevations. So the operator takes care to sample every ground elevation cell within MaxDistance from the route, taking the maximum whenever several ground elevations shall be combined to one profile node. If the elevation dataset has overviews in lower resolution, they must computed with RasterCacheFilter = Max to avoid underestimates.
Note, however, that the operator is less rigorous with land-cover rasters. It is the resolution of the ground elevation raster that will determine where ground elevations and land cover data will be sampled, so if the land-cover rasters have higher resolution than the ground elevation raster, it is possible that a small area of redwood forest is overlooked by the operator. Also, if the raster dataset for land-cover types shall use overviews, the only RasterCacheFilter that makes sense is Vote, since the land-cover codes are not numeric quantities. So in the worst case, there could be an overview raster cell for land-cover, based on four cells in higher resolution, where three high-resolution cells containing Grass wins the vote against a single high-resolution cell containing Redwood, although a mission planner would have preferred to see the Redwood win.
On the other hand, even the original land-cover rasters would normally be statistical in nature, created by a kind of vote mechanism. That is, an original 30-meter raster cell can be classified as grassland as long as the grasses dominates the area, even if the cell contains a couple of trees as well. So in practice, you cannot be certain that the land-cover profile does not underestimate the treetop elevations now and then.
Generated visualizers for land-cover data
When the LandCoverInput is not null, the VerticalProfileOperator will automatically create visualizers for the land-cover features. Each polygon and line will get a color based on its vpopLandCoverCode attribute, in agreement with the raster visualizer associated with the raster from LandCoverInput, and if no visualizer was associated with the raster, a grayscale will be used for vpopLandCoverCode values from 0 (black) to 255 (white). Also, the ground profile line will get a dark gray color (R = G = B = 85), while the ground profile polygon, generated if Close is True, will get a light gray color (R = G = B = 170). This allows quick prototyping of a profile visualization with the same colors as a plain 2D map would use.
The generated polygons will get a polygon visualizer but no line visualizer for their contour. The generated lines will get a line visualizer with width = 2.0, to make them more visible when their corresponding polygons have zero height. (Strictly speaking, this width also makes polygons with a positive height appear one pixel higher than they really are.)
Refining the generated visualizers for land-cover data
Although the automatic colors from the land-cover raster allow quick prototyping, a color scheme designed for a 2D map can be unsuitable for a terrain profile.
One remedy can be to give the land-cover raster an explicit RasterVisualizer, which you put in a VisualizationOperator between your VerticalProfileOperator and your ReadOperator for the land-cover raster. You can then refer to this raster visualizer also from your 2D map configuration.
Another remedy can be to modify just a few of the generated profile visualizers. For example, in the Carmenta Engine Samples Geodata, the built-in color for Grasslands is a light beige in the LandUseTIFF for Lake Tahoe. Since grasslands should have height zero, the automatic visualization is just a light beige line, which can be hard to see between the light gray ground polygon and the sky background.
 |
In the sample configuration vertical_profile.px, we have therefore used a VisualizationOperator named AdjustGrasslandsVisOp, which merges the generated grass line visualizer with an explicit line visualizer named AdjustedGrasslandsLineVis.
 |
The operator has VisualizationOperator.Mode = Merge, so when a grasslands line feature arrives, it satisfies the condition of the explicit line visualizer, and the generated grasslands visualizer is merged with the explicit one. The effect is that the beige color is replaced with an olive color, and the line width is also overridden to be 3.0 instead of 2.0.
 |
For good measure, we have also added a symbol visualizer for grass straws, which is activated when you zoom in.
 |
The other generated visualizers are left unchanged by the AdjustGrasslandsVisOp: they are not merged since they do not satisfy the conditions of the explicit visualizers. In this example, using VisualizationOperator.Mode = Append would also have worked, but would have drawn the explicit grasslands visualizers on top of the generated one. Note that the default mode = Replace would have discarded all incoming visualizers.
The sample configuration also generates land-cover labels when zoomed in; they are generated by the separate layer LandCoverLabels.
At very detailed scales, it may be useful to add fill patterns to some of the land-cover polygons. The screenshot below was created by modifying the example further, using mode = Append and an explicit PolygonVisualizer, with a black color and a pattern getting its value from table lookup with the vpopLandCoverCode attribute, such that 41 gets the predefined Patterns.deciduousTree (circles), 42 gets Patterns.evergreenTree (triangles), 43 gets Patterns.mixedTree (circles and triangles), 51 gets Patterns.scrubThicket (spots), and other numbers get Patterns.empty, which is also the default pattern.
 |
Platforms
Windows, Linux, Android