Handling of the North and South Pole

41 © 2016 Open Geospatial Consortium

2.1.2.3 Tile-LOD Replacement Rules

In general, finer tiles replace coarser tiles. The requirements are: Requirement 16 http:opengis.netspecCDB1.0core tile-lod-replacement For negative levels of details, a tile at LOD n SHALL replace exactly one tile at LOD n−1 since both tiles cover the same area. For positive levels of details, a tile at LOD n SHALL be replaced by 4 tiles at LOD n+1 since tiles from LOD n+1 cover only a quarter of the area covered by the tile at LOD n. In the case of positive LODs, note that it is not necessary that all 4 tiles from LOD n+1 exist; as long as one of the four tiles is present, the replacement of the tile at LOD n can take place. For instance, one tile at LOD −1 is replaced by one tile at LOD 0 which is in turn replaced by four tiles at LOD 1. The replacement of coarser tiles with finer tiles stops when no finer tiles exist.

2.1.3 Handling of the North and South Pole

Zones 0 and 10 South and North Pole are processed differently than the other zones. As per Table 2-2: Size of CDB Geocell per Zone, this corresponds to an earth slice of 1 × 30 CDB Geocells. As shown in Figure 2-2: Variation of Longitudinal Dimensions versus Latitude, a single CDB Geocell at the poles covers 12 degrees in longitude and 1 degree in latitude within a single slice. As a geographic position gets closer and closer to the poles in terms of latitude, fewer points are required in the data-grid. However the CDB Geocell still has a regular rectangular shape. Therefore, this implies that grid points will be progressively sampled in longitude in order to respect the grid format of the CDB. In CDB Zone 0, the bottom edges of the 30 geocells of the zone all converge and collapse to a single point, the South Pole. However, the data that belong exactly to the South Pole is found in a single Geocell, the one whose lower left corner is at −90° of latitude and 0° of longitude. The redundant data representing the South Pole found in the other 29 geocells of zone 0 is ignored. Similarly, in CDB Zone 10, the top edges of the 30 geocells of the zone also converge and collapse to a single point, the North Pole. Again, the data that belong exactly to the North Pole is found in a single Geocell whose lower left corner is at +89° of latitude and 0° of longitude. The redundant data representing the North Pole found in the other 29 geocells of zone 10 is ignored. The case of raster datasets that make use of the corner grid conventions is an exception since the CDB does not provide the means of representing data at precisely the North Pole +90° of 42 © 2016 Open Geospatial Consortium latitude and 0° of longitude. In this case, it is recommended that client-devices use the average of the nearest grid elements in the immediate vicinity of the North Pole.

2.2 File System Requirements

See section 1.7.1.1

2.3 Light Naming

The CDB standard defines rules that unambiguously tag any modeled light point 13 with a descriptive name. This provides client-devices with the information necessary to control all light points that have been tagged with a name that conforms to this standard. The CDB standard provides a comprehensive set of light types, particularly well suited to the needs of Visual simulation. Light types include those found on: ● cultural features including point, lines, polygons 14 , and specialized airport systems ● air, land, and surface platforms ● life forms ● munitions Each light type defined in this standard corresponds to a real-world light type. The standard provides a definition of each light type, which is representative of the light type’s function rather that its characteristics. The client-devices use the light type name as an index to derive the properties and characteristics of the light. The approach is client-device independent because the device-specific client rendering parameters are not stored in the data store and are therefore invisible to the modeler and the data store tools. The modelertools need not be concerned with dozens of parameters that describe the light’s properties and characteristics. The client-devices internally build and initialize a table of light properties and characteristics for their respective use. The table is nominally built at CDB data store load time and is built to match the device’s inherent capabilities and level-of-fidelity. The light point types are structured in a hierarchy that is designed to simplify the modeler’s workload. Increasing levels of specialization are possible if a modeler specifies light names located in deeper levels of the light naming hierarchy, i.e., the more specialized the light, the deeper the level. An extract from the light naming hierarchy is illustrated in Figure 2-5: Extract from Light Naming Hierarchy as an example. This portion of the light naming hierarchy concerns itself with lights used for “Line-based Cultural” light points e.g., streets, highways. Immediately 13 The CDB standard does not distinguish between a light-point and a light-source. In the simulation industry, the term light-point refers to a point source of light that does not illuminate its immediate surroundings. Likewise, the term light-source refers to a point source of light capable of illuminating its immediate surroundings. 14 The original CDB specification as submitted to the OGC used the term “areal” instead of “polygon”. In order to be consistent with OGCISO best practice, areal has been replaced with “polygon” throughout the document.