5.2 raster
From the URL: http: //openev.sourceforge.net/lib_design_doc/opnev.html, the design document for theinkenenv library.
The GvRaster class provides access to image data in tiles. Because image data size is potentially very large, GvRaster does not store the entire image in memory. Instead, it connects to a data input abstraction object provided by the GDAL Data I / O Library. This abstraction object may be connected to a memory buffer (in the case of an image in virtual memory) or to an image file, socket, etc. Since reading data from this object is potentially slow, GvRaster maintains a local cache of the image tiles . The maximum cache size is a parameter of GvRaster. When the cache size limit is reached, tiles in the cache are discarded on a least recently used (LRU) basis. The exact strategy for determining which tiles to discard will be tuned during the testing Phase of the project.
GvRaster is also responsible for level of detail (LOD) reduction of image tiles, also known as pyramiding. The LOD reduction process is performed `` on-the-fly '' as each tile is loaded. LOD0 is the full resolution data, with Nominal Tile Dimensions (Adjustable) of
pixels (maximum 512KB / tile). LOD1 through LODN are generated by recursively applying a box filter (4 pixel average) and decimating by 2 in rows and columns. For example, nominal tile dimensions for LOD1 through LOD3 are
(128kb),
(32KB), AND
(8kB), respectively. The process is stopped if the LOD being generated already exists in the cache. Figure 5.1 illustrates the LOD reduction process. The number of levels generated will be tuned during the testing phase of the project.
Since the data contained in a GvRaster can take on a number of different types (integer or floating point, real or complex, different bit depth), and since either averaging, or decimation may be desired, there are a number of reduction kernels required. GvRaster switches to the right kernel at run time. Currently, an averaging algorithm is employed in computing LOD1 through LODNIn order to accelerate initial overview display, GDAL provides for access to pre-built levels of detail in source data files when available. A pyramid level can be attached to one or more LOD stages (see LOD3 in the figure). If the LOD3 file existed when the pipeline was constructed, it would be used to fill in the LOD3 and LOD4 caches without needing to read the full resolution image. Such persistent caches are only attached to lower LODs, where the total data size is relatively small (a few megabytes). Addition of a LOD file to the raster cache is the responsibility of the application, and can be either automa Tic, or triggered by user request.
Figure 5.1: Lod Reduction and Cache
The total available cache size is split evenly across each LOD, except the lowest LOD cache which should handle every tile in the image. Each LOD cache has a separate LRU list. Requests for a tile / LOD combination can be made in either blocking or non . -blocking mode in blocking mode, the tile / LOD will be loaded if it is not in the cache before the request completes in non-blocking mode, the request always returns immediately to the calling function with one of the following status codes.:
Hit
The Tile / Lod Was Found in The Cache. The Tile is returned.
Suboptimal
The Tile / Lod Was Not Found, But a Lod Is Available. The Lower Lod Tile Is Returned.
Miss
No Tile Was Found to match The Request.The Gvrasterlayer Class Usees The Non-Blocking Mode To Implement Asynchronous Tile Loading.
