Line-of-sight maskingThe Line-Of-Sight constraint determines whether or not the ground obstructs the line of sight between two objects, using a simple ground model. Higher-fidelity models are available using the Azimuth Elevation (AzEl) Mask or Terrain Mask constraints. The Line-Of-Sight constraint ground model differs by object class. This ground model refers to the ellipsoid underneath the object. The ellipsoid models the ground as locally flat (i.e., no hills nor mountains nor valleys) and represents the simplest ground model possible. For example, if STK computes a facility access with a satellite above the horizon, the line of sight is considered unobstructed even if there is a mountain between the two objects. However, as soon as that satellite disappears over the horizon, obstructed by the ellipsoid that is between the objects, there is no access. The way the Line-Of-Sight constraint determines access is affected primarily by the object class and an obstruction surface. The latter can be affected by the altitude and height above ground.
Line-Of-Sight constraint as applied to satellites
Altitude versus height above ground (for line-of-sight calculations)
Assuming you have an STK object placed on or near the ground, you will have the option to change the object's altitude and/or height above ground. In STK, altitude shifts the underlying globe (ellipsoid) to the distance specified for line-of-sight calculations. The reference ellipsoid refers to a mathematical geometric model of the earth. STK usually uses one of two models: Mean Sea Level (MSL) and the World Geodetic System 1984 (WGS84). These models define the size of the ellipsoid. Specifying the altitude of an object conveys to STK the elevation of the ground underneath an object. The height above ground, on the other hand, expresses to STK the distance above the ground that the object occupies. Both options may display a floating object, but STK will compute accesses differently depending on which parameter you use; altitude would calculate accesses as if the ground were attached to the bottom of the object.
Altitude enables you to better model the ground for a facility. For example, at Denver Station, located in Denver, Colorado, the ground is nominally a mile above the ellipsoid. Using altitude prevents STK from validating access when an access object is realistically below the facility's line of sight.
Denver Station accessing a satellite as it rises above the horizon
On the other hand, if there were a ship in the ocean looking for other ships, the altitude would be zero. However, this altitude is only reflected on the center of the ship, whereas the sensors on the ship are at a height that would allow them to see much farther. This relationship would be modeled using height above ground, raising the sensor above sea level (or the ellipsoid) to increase visibility.
Sensor using height above ground to see farther
Terrain masking
A Terrain Mask constraint determines instantaneous visibility based on detecting intersections of the line of sight with the terrain surface. In an access computation scenario, using a Terrain Mask, a mountain would violate the access constraint. For example, if a satellite and facility in Denver have a mountain between them, no matter if the satellite is above the ellipsoid horizon, access will be unsuccessful. The Terrain Mask is not computationally heavy initially, but it does recompute throughout the entire scenario analysis period. The longer the analysis period, the more computationally heavy this method will become. The Terrain Mask constraint is in an object's Constraints - Basic properties. If you use this constraint, you should turn off the Line-Of-Sight constraint, as it is redundant. To operate a Terrain Mask using the Terrain Server, select the "Line-Of-Sight Terrain Mask" check box in the scenario's Basic - Terrain properties.
The main advantages of the Terrain Mask constraint are:
• There are no wasted computations; STK only computes obscuration in directions of interest.
• The constraint is extremely efficient for cases where the two objects are statically located in the central body-fixed reference frame.
• STK does not need to use interpolation, so results are of the highest possible fidelity.
• STK only needs to apply the constraint to one end object for cases where the two objects are statically located in the central body reference frame.
The main disadvantages of the Terrain Mask are:
• STK must evaluate each line of sight against the terrain during visibility computations to moving objects.
• You must include terrain information when sharing a scenario.
• There is no related visualization capability.
Access blocked by a hill using Terrain Mask
An AzEl Mask constraint leverages a provided or computed AzEl Mask to determine visibility. You can define the mask in two ways. You can provide a mask file, or the mask may be computed from terrain information to be representative of terrain-based visibility restrictions. To use an AzEl Mask with a Terrain Server, you must select the “Azimuth/Elevation Mask” check box in the scenario’s Basic - Terrain properties. The AzEl Mask computes the angles that are obscured within a certain range and stores that data. You can use an AzEl Mask in an object’s Basic - AzElMask properties. You can visualize an AzEl Mask in the 2D Graphics window by entering 2D - AzElMask properties. You can also view an AzEl Mask in 3D Graphics window by setting 3D Graphics - AzElMask properties; this view has more options.
The main advantages of the AzEl Mask constraint are:
• STK computes the mask once and can store and apply it to all subsequent access computations.
• You can share the mask with the scenario as an AEM file without needing to share the source terrain information.
• You can visualize the mask.
• The mask accounts for all geometries, making it easily applicable to moving objects.
• It is a good option for ground stations.
The main disadvantages of the AzEl Mask constraint are:
• The up-front computation of the mask is computationally expensive, especially in coverage applications where STK applies the constraint to the coverage grid points.
• Since STK uses interpolation to determine instantaneous visibility, the results are not exact.
AzEl Mask visualized
Body maskA body mask provides data that STK uses to restrict visibility of a sensor specifically. The body mask defines areas of exclusion or inclusion that are defined using an offset from local axes. The boundary of a body mask is assembled using pairs of azimuth and elevation angles that restrict the visibility of a sensor. You can create a body mask inside of STK using the sensor’s AzElMask Tool. To do this, right-click a sensor, expand the Sensor option, and select AzElMask. In the dialog box, choose the obscuring objects and compute to generate a BMSK file. You can use this file in the sensor Basic – Sensor AzElMask properties.
Sensor body mask on a ship
This article has hopefully helped you understand the main principles behind line-of-sight masking. The different uses of altitude (underlying globe) and height above ground (terrain) should be clear. Altitude is used for the height of the ground, and height above ground is the distance between the ground and the object. You also saw the variance between the three mask types: AzEl Mask (precomputed rays), Terrain Mask (instant terrain blockage), and Body Mask (sensor-body obstruction). An AzEl Mask is best used for terrain calculations with a substantial amount of accesses, while a Terrain Mask is better suited for small amounts of terrain calculations.
Basic ConstraintsDefine an Azimuth-Elevation MaskAz-El Mask vs Terrain Mask for Terrain ObstructionUsing the AzEl Mask ToolCreating an AzEl Mask from ImagesBody Mask File Format (*.bmsk) 