1 GeoRaster Overview and Concepts

1.1 Vector and Raster Data

Geographic features can be represented in vector or raster format, or both. With vector data, points are represented by their explicit x,y,z coordinates, lines are strings of points, and areas are represented as polygons whose borders are lines. This kind of vector format can be used to record precisely the location and shape of spatial objects. With raster data, you can represent spatial objects by assigning values to the cells that cover the objects, and you can represent the cells as arrays. This kind of raster format has less precision than vector format, but it is ideal for many types of spatial analysis.

In the raster geographic information systems (GIS) world, this kind of raster data is normally called gridded data. In image processing systems, the raster data representations are typically called images instead of grids. Despite any differences between grids and images, both forms of spatial information are usually represented as matrix structures (that is, arrays of cells), and each cell is usually regularly aligned in the space.

1.2 GeoRaster Data Sources

GeoRaster data is collected and used by a variety of geographic information technologies, including remote sensing, airborne photogrammetry, cartography, and global positioning systems. The collected data is then analyzed by digital image processing systems, computer graphics applications, and computer vision technologies. These technologies use several data formats and create a variety of products.

This section briefly describes some of the main data sources and uses for GeoRaster, focusing on concepts and techniques you need to be aware of in developing applications. It does not present detailed explanations of the technologies; you should consult standard textbooks and reference materials for that information.

1.3 GeoRaster Data Model

Raster data can have some or all of the following elements:

• Cells or pixels

• Spatial domain (footprint)

• Spatial, temporal, and band reference information

• Cell attributes

• Metadata

• Processing data and map support data

GeoRaster uses a generic raster data model that is component-based, logically layered, and multidimensional. The core data in a raster is a multidimensional matrix of raster cells. Each cell is one element of the matrix, and its value is called the cell value. If the GeoRaster object represents an image, a cell can also be called a pixel, which has only one value. (In GeoRaster, the terms cell and pixel are interchangeable.) The matrix has a number of dimensions, a cell depth, and a size for each dimension. The cell depth is the data size of the value of each cell. The cell depth defines the range of all cell values, and it applies to each single cell, not to an array of cells. This core raster data set can be blocked for optimal storage and retrieval.

The data model has a logically layered structure. The core data consists of one or more logical layers. For example, for multichannel remote sensing imagery, the layers are used to model the channels of the imagery. (Bands and layers are explained in Section 1.5.) In the current release, each layer is a two-dimensional matrix of cells that consists of the row dimension and the column dimension.

GeoRaster data has metadata and attributes, and each layer of the GeoRaster data can have its own metadata and attributes. In the GeoRaster data model, all data other than the core cell matrix is the GeoRaster metadata. The GeoRaster metadata is further divided into different components (and is thus called component-based), which contain the following kinds of information:

• Object information

• Raster information

• Spatial reference system information

• Date and time (temporal reference system) information

• Band reference system information

• Layer information for each layer

Based on this data model, GeoRaster objects are described by the GeoRaster metadata XML schema (described in Appendix A), which is used to organize the metadata. Some schema components and subcomponents are required and others are optional. You must understand this XML schema if you develop GeoRaster loaders, exporters, or other applications. This XML schema can also be extended to include any kind of raster metadata that is not already included in the schema. Some restrictions on the metadata exist for the current release, and these are described in the Usage Notes for the SDO_GEOR.validateGeoraster function (documented in Chapter 4), which checks the validity of the metadata for a GeoRaster object.

The GeoRaster object data types, described in Chapter 2, are based on the GeoRaster data model.

In this data model, two different types of coordinates need to be considered: the coordinates of each pixel (cell) in the raster matrix and the coordinates on the Earth that they represent. Consequently, two types of coordinate systems or spaces are defined: the cell coordinate system and the model coordinate system.

The cell coordinate system (also called the raster space) is used to describe pixels in the raster matrix, and its dimensions are (in this order) row, column, and band. The model coordinate system (also called the ground coordinate system or the model space) is used to describe points on the Earth or any other coordinate system associated with an Oracle SRID value. The spatial dimensions of the model coordinate system are (in this order) X and Y, corresponding to the column and row dimensions, respectively, in the cell coordinate system. The logical layers correspond to the band dimension in the cell space.

Figure 1-1 shows the relationship between a raster image and its associated geographical (spatial) extent, and between parts of the image and their associated geographical entities.

Figure 1-1 Raster Space and Model Space

Description of "Figure 1-1 Raster Space and Model Space"

In Figure 1-1:

• In the objects on the left, the medium-size rectangle represents a raster image, and within it are a rectangular area showing a national park and a point identifying the location of a specific restaurant. Each pixel in the image can be identified by its coordinates in a cell coordinate system (the coordinate system associated with the raster image). The upper-left corner of the medium-size rectangle has the coordinate values associated with the ULTCoordinate value of the cell space for the GeoRaster object.

• In the objects on the right, the large rectangle represents the geographical area (in the model, or ground, space) that is shown in the raster image, and within it are spatial geometries for the national park and the specific restaurant. Each entire geographical area and geometries within it can be identified using coordinates in its model (or, ground) coordinate system, such as WGS 84 for longitude/latitude data.

In GeoRaster, the upper-left corner of the raster data can have a different coordinate in its cell space from the coordinate of the origin of the cell space. In other words, the (row, column) coordinate of the upper-left corner is not necessarily (0,0). The upper-left corner is called the ULTCoordinate, and its value is registered in the metadata. If there is a band dimension, the ULTCoordinate value is always (row,column,0). The coordinate of each cell is relative to the origin of the cell space, not to the ULTCoordinate value. The origin of the cell coordinate system may not be exactly at the ULTCoordinate value.

For two-dimensional single-layer GeoRaster data, the cell coordinate system has a column dimension pointing to the right and a row dimension pointing downward, as shown in Figure 1-1. The unit is in cells, or pixels, and the cell coordinates are identified by integer column and row numbers. For a multiband image, the axis along bands is called the band dimension. For a time series multilayer image (where each layer has a different date or timestamp), the axis along layers is called the temporal dimension. Three-dimensional GeoRaster data includes the vertical dimension, which is vertical to both the row and column dimensions.

The model coordinate system consists of spatial dimensions, and other dimensions if there are any. The spatial dimensions are called the x, y, and z dimensions, and values in these dimensions can be associated with a geodetic, projected, or local coordinate system. Other dimensions include spectral and temporal dimensions (called the s dimension and t dimension, respectively). GeoRaster currently supports only two spatial dimensions (X,Y) in the model coordinate system. (For information about coordinate systems, including the different types of coordinate systems, see Oracle Spatial User's Guide and Reference.)

The relationships between cell coordinates and model coordinates are modeled by GeoRaster reference systems (mapping schemes). The following GeoRaster reference systems are defined:

• Spatial reference system, also called GeoRaster SRS, which maps cell coordinates (row,column,vertical) to model coordinates (X,Y,Z). Using the spatial reference system with GeoRaster data is referred to as georeferencing the data. (Georeferencing is discussed in Section 1.6.)

• Temporal reference system, also called GeoRaster TRS, which maps cell coordinates (temporal) to model coordinates (T).

• Band reference system, also called GeoRaster BRS, which maps cell coordinates (band) to model coordinates (S, for Spectral).

Each of these reference systems is currently defined, at least partially, in the GeoRaster XML schema. However, for the current release, only the two-dimensional spatial reference system is supported. This means that only the relationship between (row,column) and (X,Y) coordinates can be mapped. If the model coordinate system is geodetic, (X,Y) means (longitude,latitude). The temporal and band reference systems can be used, however, to store useful temporal and spectral information, such as the spectral resolution and when the raster data was collected.

Other metadata is stored in the <layerInfo> element in the GeoRaster XML metadata, as explained in Section 1.5.

1.4 GeoRaster Physical Storage

As mentioned in Section 1.3, GeoRaster data consists of a multidimensional matrix of cells and the GeoRaster metadata. Most metadata is stored as an XML document using the Oracle XMLType data type. The metadata is defined according to the GeoRaster metadata XML schema, which is described in Appendix A. The spatial extent (footprint) of a GeoRaster object is part of the metadata, but it is stored separately as an attribute of the GeoRaster object. This approach allows GeoRaster to take advantage of the spatial geometry type and related capabilities, such as using R-tree indexing on GeoRaster objects.

The multidimensional matrix of cells is blocked into small subsets for large-scale GeoRaster object storage and optimal retrieval and processing. Each block is stored in a table as a binary large object (BLOB), and a geometry object (of type SDO_GEOMETRY) is used to define the precise extent of the block. Each row of the table stores only one block and the blocking information related to that block. (This blocking scheme applies to any pyramids also.)

The dimension sizes (along row, column, and band dimensions) may not be evenly divided by their respective block sizes. GeoRaster adds padding to the boundary blocks that do not have enough original cells to be completely filled. The boundary blocks are the end blocks along the positive direction of each dimension. The padding cells have the same cell depth as other cells and have values equal to zero. Padding makes each block have the same BLOB size. Padding mainly applies to row and column blocks, but for multiband and hyperspectral imagery, padding can be applied to the band dimension also. For example, assume the following specification: band interleaved by line, blocking as (64,64,3), and 8 bands, each with 64 rows and 64 columns. In this case:

1. Bands 0, 1, and 2 are stored interleaved by line in the first block.

2. Bands 3, 4, and 5 are stored interleaved by line in the second block.

3. The third block holds the following in this order: line 1 of band 6, line 1 of band 7, 64 column values that are padding, line 2 of band 6, line 2 of band 7, 64 column values that are padding, and so on, until all 64 rows are stored.

However, the top-level pyramids are not padded if both the row and column dimension sizes of the pyramid level are less than or equal to one-half the row block size and column block size, respectively. See Section 1.7 for information about the physical storage of pyramids.

If the cell depth is greater than 8 bits, GeoRaster cell data is stored in big-endian format in raster blocks (BLOBs). If the cell depth is less than 8 bits, each byte in the raster blocks (BLOBs) contains two or more cells, so that the bits of a byte are fully filled with cell data. The cells are always filled into the byte from left to right. For example, if the cell depth is 4 bits, one byte contains two cells: the first four bits of the byte contain the value of a cell, and the second four bits contain the value of its following cell, which is determined by the interleaving type.

Based on this physical storage model, two object types are provided: SDO_GEORASTER for the raster data set and related metadata, and SDO_RASTER for each block in a raster image.

• The SDO_GEORASTER object contains a spatial extent geometry (footprint or coverage extent) and relevant metadata. A table containing one or more columns of this object type is called a GeoRaster table.

• The SDO_RASTER object contains information about a block (tile) of a GeoRaster object, and it uses a BLOB object to store the raster cell data for the block. An object table of this object type is called a raster data table (RDT).

Each SDO_GEORASTER object has a pair of attributes (rasterDataTable, rasterID) that uniquely identify the RDT and the rows within the RDT that are used to store the raster cell data for the GeoRaster object.

Figure 1-2 shows the storage of GeoRaster objects, using as an example an image of Boston, Massachusetts in a table that contains rows with images of various cities.

Figure 1-2 Physical Storage of GeoRaster Data

Description of "Figure 1-2 Physical Storage of GeoRaster Data"

As shown in Figure 1-2:

• Each row in the table of city images contains information about the image for a specific city (such as Boston), including an SDO_GEORASTER object.

• The SDO_GEORASTER object includes the spatial extent geometry covering the entire area of the image, the metadata, the raster ID, and the name of the raster data table associated with this image.

• Each row in the raster data table contains information about a block (or tile) of the image, including the block's minimum bounding rectangle (MBR) and image data (stored as a BLOB). The raster data table is described in Section 1.4.2.

The SDO_GEORASTER and SDO_RASTER object types are described in detail in Chapter 2.

Figure 1-3 shows the physical storage of GeoRaster data and several related objects in a database.

Figure 1-3 GeoRaster Data in an Oracle Database

Description of "Figure 1-3 GeoRaster Data in an Oracle Database"

In Figure 1-3:

• Each GeoRaster object in the GeoRaster table has an associated raster data table, which has an entry for each block of the raster image.

• The BLOB with image data for each raster image block is stored separately from the raster table data. You can specify storage parameters (described in Section 1.4.1) for the BLOBs.

• Each GeoRaster object has a raster data table associated with it. However, a raster data table can store blocks of multiple GeoRaster objects, and GeoRaster objects in a GeoRaster table can be associated with one or multiple raster data tables.

• GeoRaster system data (described in Section 2.4) maintains the relationship between the GeoRaster tables and the raster data tables.

• Indexes (standard and Spatial) can be built on the GeoRaster table and raster data tables. For information about indexing GeoRaster data, see Section 3.8.

• Additional tables, such as ground control point (GCP) tables and value attribute tables (VATs), can be related to the GeoRaster objects.

You should maintain a one-to-many relationship between a GeoRaster table and its associated raster data tables. That is, you should let a raster data table only contain cell data of GeoRaster objects that belong to the same GeoRaster table.

The following considerations apply to schema, table, and column names that are stored in any Oracle Spatial metadata views. For example, these considerations apply to geometry tables, GeoRaster tables, raster data tables, and geometry and GeoRaster columns.

• The name must contain only letters, numbers, and underscores. For example, the name cannot contain a space ( ), an apostrophe ('), a quotation mark ("), or a comma (,).

• All letters in the names are converted to uppercase before the names are stored in geometry metadata views or GeoRaster system data (xxx_SDO_GEOR_SYSDATA) views or before the tables are accessed. This conversion also applies to any schema name specified with the table name.

For more information about raster data tables, see Section 1.4.2.

For information about cross-schema support with GeoRaster tables and raster data tables, see Section 1.4.4.

DECLARE
   gr1 sdo_georaster;
   gr2 sdo_georaster;
BEGIN
INSERT INTO georaster_table (georid, georaster) VALUES (2, sdo_geor.init('RDT_1'))
       RETURNING georaster INTO gr2;
SELECT georaster INTO gr1 FROM georaster_table WHERE georid=1;
sdo_geor.changeFormatCopy(gr1, 'blocksize=(128,128) pyramid=FALSE', gr2);
UPDATE georaster_table SET georaster=gr2 WHERE georid=2;
COMMIT;
END;
/

CREATE TABLE georaster_table
( georid    NUMBER,
  name      VARCHAR2(32),
  georaster SDO_GEORASTER );

CALL SDO_GEOR_UTL.createCMLTrigger('georaster_table', 'georaster');

CREATE TABLE rdt_1 OF SDO_RASTER
  (PRIMARY KEY (rasterID, pyramidLevel, bandBlockNumber,
    rowBlockNumber, columnBlockNumber))
  TABLESPACE geor_tbs NOLOGGING
  LOB(rasterBlock) STORE AS rdt_1_rbseg
    (TABLESPACE  geor_tbs_2
     CHUNK 8192
     CACHE READS
     NOLOGGING
     PCTVERSION 0
     STORAGE (PCTINCREASE 0)
    );

1.5 Bands, Layers, and Interleaving

In GeoRaster, band and layer are different concepts. Band is a physical dimension of the multidimensional raster data set; that is, it is one ordinate in the cell space. For example, the cell space might have the ordinates row, column, and band. Bands are numbered from 0 to n-1, where n is the highest layer number. Layer is a logical concept in the GeoRaster data model. Layers are mapped to bands. Typically, one layer corresponds to one band, and it consists of a two-dimensional matrix of size rowDimensionSize and columnDimensionSize. Layers are numbered from 1 to n; that is, layerNumber = bandNumber + 1.

A GeoRaster object can contain multiple bands, which can also be called multiple layers. For example, electromagnetic wave data from remote sensing devices is grouped into a certain number of channels, where the number of possible channels depends on the capabilities of the sensing device. Multispectral images contain multiple channels, and hyperspectral images contain a very large number (say, 50 or more) of channels. The channels are all mapped into GeoRaster bands, which are associated with layers.

In raster GIS applications, a data set can contain multiple raster layers, and each layer is called a theme. For example, a raster may have a population density layer, where different cell values are used to depict neighborhoods or counties depending on their average number of inhabitants per square mile or kilometer. Other examples of themes might be average income levels, land use (agricultural, residential, industrial, and so on), and elevation above sea level. The raster GIS themes can be stored in different GeoRaster objects or in one GeoRaster object, and each theme is modeled as one layer. The raster themes and multispectral image channels can also be stored together in one GeoRaster object as different layers, as long as they have the same dimensions.

Figure 1-4 shows an image with multiple layers and a single raster data table. Each layer contains multiple blocks, each of which typically contains many cells. Each block has an entry in the raster data table. Note that GeoRaster starts layer numbering at 1 and band numbering at 0 (zero), as shown in Figure 1-4.

Figure 1-4 Layers, Bands, and the Raster Data Table

Description of "Figure 1-4 Layers, Bands, and the Raster Data Table"

The GeoRaster XML metadata refers to the object layer and to layers. The object layer refers to the whole GeoRaster object, which may or may not contain multiple layers. If the GeoRaster object contains multiple layers, each layer is a sublayer of the object layer, and it refers to a single band.

Each layer can have an optional set of metadata associated with it. The metadata items for a layer include the layer ID, description, scaling function, bin function, statistical data set (including histogram), grayscale lookup table, and colormap (or, pseudocolor lookup table, also called a PCT). Applications can use the available metadata information. For example, to display a 64-bit GeoRaster object, a typical approach is to process the original cell values through scaling or binning so that the cell value range is less than the 64-bit range and thus can be displayed on a normal monitor. The metadata items are defined in the GeoRaster metadata XML schema, which is presented in Appendix A. See also the explanations of the SDO_GEOR_COLORMAP object type in Section 2.3.2 and SDO_GEOR_GRAYSCALE object type in Section 2.3.3.

The metadata associated with the object layer applies to the whole GeoRaster object. The metadata associated with a layer applies only to that layer. For example, the statistical data set for the object layer is calculated based on all cells of the GeoRaster object, regardless of how many layers the object has; but the statistical data for a layer is calculated based only on the cells in that layer.

The metadata for the object layer and other layers is stored using <layerInfo> elements in the GeoRaster XML metadata, which is described in Appendix A, and sometimes in separate tables, such as a colormap table or a histogram table. Metadata stored in the GeoRaster XML metadata is managed by GeoRaster, and you can use the GeoRaster API to retrieve and modify this metadata. For metadata stored in separate tables, the table name can be registered in the GeoRaster XML schema, in which case applications can retrieve the name of the table. However, GeoRaster does not check the existence or validity of that table or provide any operations on that table.

Three types of interleaving are supported: BSQ (band sequential), BIL (band interleaved by line), and BIP (band interleaved by pixel). Interleaving applies between bands or layers only. Interleaving is limited to the interleaving of cells inside each block of a GeoRaster object. This means GeoRaster always applies blocking on a GeoRaster object first, and then it applies interleaving inside each block independently. However, each block of the same GeoRaster object has the same interleaving type. You can change the interleaving type of a copy of a GeoRaster object by calling SDO_GEOR.changeFormatCopy procedure, so that the data can be more efficiently processed and used.

1.6 Georeferencing

The GeoRaster spatial reference system (SRS), a metadata component of the GeoRaster object, includes information related to georeferencing. Georeferencing establishes the relationship between cell coordinates of GeoRaster data and real-world ground coordinates (or some local coordinates). Georeferencing assigns ground coordinates to cell coordinates, and cell coordinates to ground coordinates.

In GeoRaster, georeferencing is different from geocorrection, rectification, or orthorectification. In these three latter processes, cell resampling is often performed on the raster data, and the resulting GeoRaster data might have a different model coordinate system and dimension sizes. Georeferencing establishes the relationship between cell coordinates and real-world coordinates or some local coordinates. Georeferencing can be accomplished by providing an appropriate mathematical formula, enough ground control point (GCP) coordinates, or rigorous model data from the remote sensing system. Georeferencing does not change the GeoRaster cell data or other metadata, except as needed to facilitate the transformation of coordinates between the cell coordinate system and the model coordinate system.

GeoRaster currently supports six-parameter affine transformation that georeferences two-dimensional raster data. The affine transformation is a special type of the Functional Fitting polynomial model. If an affine transformation is provided and is valid in the metadata, the GeoRaster object is considered georeferenced, and the isReferenced value in the SRS metadata will be TRUE; otherwise, it should be FALSE.

Rectification can be done with horizontal coordinates, so that cells of a GeoRaster data set can be mapped to a projection map coordinate system. After rectification, each cell is regularly sized in the map units and is aligned with the model coordinate system, that is, with the East-West dimension and the North-South dimension. If elevation data (DEM) is used in rectification, it is called orthorectification, a special form of rectification that corrects terrain displacement. If a GeoRaster object is rectified, the isRectified value in its metadata will be TRUE; otherwise, it should be FALSE. If a GeoRaster object is orthorectified, the isOrthoRectified value in its metadata will be TRUE; otherwise, it should be FALSE.

To georeference a GeoRaster object, see Section 3.6.

row = a + b * x + c * y
col = d + e * x + f * y

row = a + c * y
col = d - c * x

<xsd:element name="modelCoordinateLocation" minOccurs="0">
        <xsd:simpleType>
                 <xsd:restriction base="xsd:string">
                          <xsd:enumeration value="CENTER"/>
                          <xsd:enumeration value="UPPERLEFT"/>
                 </xsd:restriction>
        </xsd:simpleType>
</xsd:element>

x = A * col + B * row + C
y = D * col + E * row + F

row = row0 + m
col = col0 + n

1.7 Pyramids

Pyramids are subobjects of a GeoRaster object that represent the raster image or raster data at differing sizes and degrees of resolution. The size is usually related to the amount of time that an application needs to retrieve and display an image, particularly over the Web. That is, the smaller the image size, the faster it can be displayed; and as long as detailed resolution is not needed (for example, if the user has "zoomed out" considerably), the display quality for the smaller image is adequate.

Pyramid levels represent reduced or increased resolution images that require less or more storage space, respectively. (GeoRaster currently supports only reduced resolution pyramids.) A pyramid level of 0 indicates the original raster data; that is, there is no reduction in the image resolution and no change in the storage space required. Values greater than 0 (zero) indicate increasingly reduced levels of image resolution and reduced storage space requirements.

Pyramid type indicates the type of pyramid, and can be one of the following values:

• DECREASE means that pyramids decrease in size as the pyramid level increases.

• NONE means that there are no pyramids associated with the GeoRaster object.

Figure 1-5 shows the concept of pyramid levels with a pyramid type of DECREASE. It conveys the idea that as the pyramid level number increases, the file size decreases, but the resolution also decreases because fewer pixels are used to represent the image.

Figure 1-5 Pyramid Levels

Description of "Figure 1-5 Pyramid Levels"

The size of the pyramid image at each level is determined by the original image size and the pyramid level, according to the following formulas:

r(n) = (int)(r(0) / 2^n)
c(n) = (int)(c(0) / 2^n)

In the preceding formulas:

• r(0) and c(0) are the original row and column dimension size.

• r(n) and c(n) are the row and column dimension size of pyramid level n.

• int rounds off a number to the integer value that is less than but closest to that number.

• 2^n means 2 to the power of n.

The smaller of the row and column dimension sizes of the top-level overview (the smallest top-level pyramid) is 1. This determines the maximum reduced-resolution pyramid level, which is calculated as follows: (int)(log2(a))

In the preceding calculation:

• log2 is a logarithmic function with 2 as its base.

• a is the smaller of the original row and column dimension size.

The pyramids are stored in the same raster data table as the GeoRaster object. The pyramidLevel attribute in the raster data table identifies all the blocks related to a specific pyramid level. In general, the blocking scheme for each pyramid level is the same as that for the original level (which is defined in the GeoRaster object metadata), except in the following cases:

• If the original GeoRaster object is not blocked, that is, if the original cell data is stored in one block (BLOB) of the exact size of the object, the cell data of each pyramid level is stored in one block, and its size is the same as that of the actual pyramid level image.

• If the original GeoRaster object is blocked (even if blocked as one block), the cell data of each pyramid level is blocked in the same way as for the original level data, and each block is stored in a different BLOB object as long as the maximum dimension size of the actual pyramid level image is larger than the block sizes. However, if lower-resolution pyramids are generated (that is, if both the row and column dimension sizes of the pyramid level are less than or equal to one-half the row block size and column block size, respectively), the cell data of each such pyramid level is stored in one BLOB object and its size is the same as that of the actual pyramid level image.

When pyramids are generated on a GeoRaster object or when a GeoRaster object is scaled, resampling of cell data is required. GeoRaster provides the following standard resampling methods:

• Nearest neighbor

• Bilinear interpolation using 4 neighboring cells

• Cubic convolution using 16 neighboring cells

• Average4 using 4 neighboring cells

• Average16 using 16 neighboring cells

The following subprograms (described in Chapter 4) are associated with GeoRaster support for pyramids:

• SDO_GEOR.generatePyramid generates pyramid data for a GeoRaster object.

• SDO_GEOR.deletePyramid deletes pyramid data for a GeoRaster object.

• SDO_GEOR.getPyramidMaxLevel returns the maximum pyramid level of a GeoRaster object.

• SDO_GEOR.getPyramidType returns the pyramid type for a GeoRaster object.

1.8 Compression and Decompression

GeoRaster provides two types of native compression to reduce storage space requirements for GeoRaster objects: JPEG (JPEG-B or JPEG-F) and DEFLATE. With both types, each block is compressed individually, as a distinct raster representation; and when a compressed GeoRaster object is decompressed, each block is decompressed individually.

Any GeoRaster operation that can be performed on a decompressed (uncompressed) GeoRaster object can also be performed on a compressed GeoRaster object. When GeoRaster performs an operation, if the source GeoRaster object is compressed, GeoRaster internally decompresses blocks of the source object as needed, performs the specified operation, and then compresses the resulting object in the format specified by the compression keyword or, if the compression keyword is not specified, in the source object's compression format. Therefore, you do not need to decompress compressed GeoRaster objects before performing certain operations, but you might gain some overall performance benefit if you decompress the objects before performing other operations.

Before a database user compresses or decompresses a GeoRaster object, ensure that the database has been created with a default temporary tablespace or that the user has been assigned a temporary tablespace or tablespace group. Otherwise, by default the SYSTEM tablespace is used for the temporary tablespace, and large temporary LOB data generated during GeoRaster operations are put in the SYSTEM tablespace, possibly affecting overall database performance. For information about managing temporary tablespaces, see Oracle Database Administrator's Guide.

To specify compression or decompression of a GeoRaster object, use the compression keyword in the storageParam parameter, which is described in Section 1.4.1. You can use the compression keyword in the storageParam parameter with several GeoRaster procedures, including SDO_GEOR.changeFormatCopy, SDO_GEOR.getRasterData, SDO_GEOR.getRasterSubset, SDO_GEOR.importFrom, SDO_GEOR.mosaic, SDO_GEOR.scaleCopy, and SDO_GEOR.subset. (There are no separate procedures for compressing and decompressing a GeoRaster object.)

If the source GeoRaster object is blank, the compression keyword is ignored, except for the SDO_GEOR.getRasterSubset and SDO_GEOR.getRasterData functions. That is, a blank GeoRaster object is never compressed, and the compression type in the metadata is always NONE. (Blank GeoRaster objects are explained in Section 1.4.3.)

This section covers the following topics:

• JPEG compression of GeoRaster objects (Section 1.8.1)

• DEFLATE compression of GeoRaster objects (Section 1.8.2)

• Decompression of GeoRaster objects (Section 1.8.3)

1.9 GeoRaster PL/SQL Subprogram Categories

GeoRaster provides the SDO_GEOR and SDO_GEOR_UTL PL/SQL packages, which contain subprograms (functions and procedures) to work with GeoRaster data and metadata. This section groups the subprograms into categories based on the types of actions they perform.

Chapter 4 and Chapter 5 contain detailed reference information about the subprograms in the SDO_GEOR and SDO_GEOR_UTL packages, respectively. The subprograms are presented in alphabetical order in those chapters.

1.10 GeoRaster Tools: Viewer, Loader, Exporter

GeoRaster includes several client-side tools. If you installed the demo files from the Companion CD, these tools are in the following directory (assuming the default Spatial installation directory of $ORACLE_HOME/md):

$ORACLE_HOME/md/demos/georaster/java

This directory contains a file named README, which includes helpful usage information, as well as instructions for using the following tools:

• GeoRaster viewer, which displays GeoRaster objects and metadata, as well as raster images, in a Java viewer application. You can connect to multiple databases simultaneously, and see the GeoRaster objects from each database listed in the left pane. You can quickly switch among views at various resolutions, from the original image (pyramid level 0) to the overview (highest pyramid level). You can perform image enhancement, such as linear stretch (automatic, manual, or piecewise), normalization, equalization, and controls for brightness, contrast, and threshold. (For more information about viewing GeoRaster objects, see Section 3.14.)

  In the viewer, you can call the GeoRaster loader and exporter tools, thus enabling you to use a single tool as an interface to the capabilities of all the GeoRaster tools. The loader and exporter tools are described in this section and in the README file.

• GeoRaster loader, which loads raster data into the GeoRaster objects. You can use this as an alternative to the SDO_GEOR.importFrom procedure, which is documented in Chapter 4. However, on non-Windows systems this loader tool does not support the BMP or GIF image formats, so you must use the SDO_GEOR.importFrom procedure with these formats on non-Windows systems. This tool does not support raster data that has a cell depth value of 2BIT, or source multiband raster data with BIL or BSQ interleaving types. The imported GeoRaster object has the BIP interleaving type. The loading operation of this tool cannot be rolled back.

  When an image in JPEG file format is loaded, the amount of memory required for the operation depends on the size of the uncompressed image, and can be specified as a command line parameter using the -Xmx option (for example, java -Xmx256M oracle.spatial.georaster.tools.GeoRasterLoader ...).

• GeoRaster exporter, which exports GeoRaster objects to image files. You can use this as an alternative to the SDO_GEOR.exportTo procedure, which is documented in Chapter 4. The GeoRaster exporter tool does not support GIF as a destination file format; the SDO_GEOR.exportTo procedure does not support GIF or JPEG as a destination file format. The GeoRaster exporter tool does not support GeoRaster objects that have a cellDepth value of 2BIT. GeoRaster objects with a cell depth of 8 bits or greater that have a BSQ or BIL interleaving are exported in BIP interleaved format. For information about limits on the amount of GeoRaster data that can be exported in a single operation, see the Usage Notes for the SDO_GEOR.exportTo procedure.

These tools are developed in Java, so you can run them anywhere through an intranet or the Internet, as long as you establish a network connection with the Oracle database.

GeoRaster can load and export the following image formats: TIF/GeoTIFF, (georeferencing information), JPEG, BMP, GIF, and PNG. Georeferencing information can be loaded from and exported to ESRI world files, but georeferencing information in GeoTIFF imagery is ignored during loading and exporting. Some restrictions regarding image size and types may apply; see the README file for the GeoRaster tools.

After raster or image files are loaded into GeoRaster objects, the data is completely stored in the native GeoRaster object data type and is independent from any specific file formats.

If you want to create your own GeoRaster loader and exporter tools, you can develop them using OCI, Oracle C++ Call Interface (OCCI), or Java, and you can implement them as client-side commands or server-side SQL procedures or functions.

1.11 GeoRaster PL/SQL Demo Files

GeoRaster includes several PL/SQL demo files that show common operations. If you installed the demo files from the Companion CD, these files are in the following directory under the Spatial installation directory (which by default is $ORACLE_HOME/md):

/demo/georaster/plsql

The README file in that directory introduces the PL/SQL files in the directory, which are listed in Table 1-12.

1.12 README File for Spatial and Related Features

A README.txt file supplements the information in the following manuals: Oracle Spatial User's Guide and Reference, Oracle Spatial GeoRaster (this manual), and Oracle Spatial Topology and Network Data Models. This file is located at:

$ORACLE_HOME/md/doc/README.txt