Raster datasets and raster catalogs in a geodatabase in PostgreSQL
Raster data is spatial data represented in an array of equally sized cells arranged in rows and columns. Raster data can be made up of one or more raster bands. For a complete explanation of raster data and its attributes, see the "Understanding raster data" book in this help. You can start with What is raster data?
Rasters in ArcGIS Desktop
In ArcGIS, raster data can be stored in a single raster dataset, raster catalog, or mosaic dataset. For a description of these types of raster storage, see Raster data organization.
In the Catalog tree, individual raster datasets in PostgreSQL have the following icon:
A raster catalog in the Catalog tree has the following icon:
The names of raster catalogs and raster datasets in PostgreSQL contain the name of the database, the name of the owner of the raster catalog or dataset, and the name of the raster catalog or raster dataset itself.
For example, a raster dataset, qa_ras_seattle2, owned by user rocket, in the m8db database would be listed as m8db.rocket.qa_ras_seattle2 in the Catalog tree.
For information on how mosaic datasets are stored in a geodatabase, see Mosaic datasets in a geodatabase in PostgreSQL.
Raster tables in a PostgreSQL database
ArcSDE geodatabases in a PostgreSQL database can store raster data in either PostgreSQL's native bytea column or in the ST_Raster storage type.
Rasters stored in bytea
A raster column is added to a business table, and each cell of the raster column contains a reference to a raster stored in a separate raster table. Therefore, each row of a business table references an entire raster.
When you import a raster into an ArcSDE geodatabase, a raster column is added to the business table of your choice. Each cell of the raster column contains a reference to a raster stored in a separate raster table. Therefore, each row of a business table references an entire raster. ArcSDE restricts one raster column per business table.
Tip:You can name the raster column whatever you like, as long as it conforms to PostgreSQL's column naming convention.
A raster dataset is made up of five tables: business, auxiliary, block, band, and raster. The following are the tables for the raster dataset qa_ras_seattle2_xf.
The numbers in the sde_ras, sde_bnd, sde_aux, and sde_blk tables correspond to the rastercolumn_id of the sde_raster_columns table.
The business table
The business table is a DBMS table that stores attributes and is spatially enabled by adding a raster column. It stores the footprint (delineates the area) of the raster. In the example above, the business table is the qa_ras_seattle2_xf table.
A business table with a raster column is a raster dataset or a raster catalog. A raster dataset can have only one business table row, while a raster catalog can have more than one. Information about the raster column is maintained in the sde_raster_columns system table. Information about all business tables, regardless of whether they have a spatial column or raster column, is maintained in the sde_table_registry system table.
Raster image tables
The actual raster images are stored in these tables.
Note:The raster tables are only present in your database if you have raster data in the geodatabase.
The raster auxiliary table stores the image color map; image statistics; and the optional bit mask, which is used for image overlays and mosaicking.
ArcSDE automatically stores any existing image metadata, such as image statistics, color maps, or bit masks in the raster auxiliary table. The rasterband_id column of the raster auxiliary table is a foreign key reference to the primary key of the raster bands table. ArcSDE joins the two tables on this primary/foreign key reference when accessing the metadata of a raster band.
|
Field name |
Field type |
Description |
Null? |
|---|---|---|---|
|
rasterband_id |
integer |
A number that represents a raster band; for example, a raster dataset with two raster bands would have two different values in this field—1 and 2. |
NOT NULL |
|
type |
integer |
Values include |
NOT NULL |
|
object |
bytea |
Contains the actual data, either a colormap index, raster statistics, or coordinate transformation |
NOT NULL |
The raster blocks table stores the actual image data for each band of the image.
The raster blocks table stores the pixels of each raster band. ArcSDE tiles the pixels into blocks according to a user-defined dimension. ArcSDE does not have a default dimension; however, applications that store raster data in ArcSDE geodatabases do. Geoprocessing tools and ArcCatalog, for example, use default raster block dimensions of 128 by 128 pixels per block. The dimensions of the raster block, along with the compression method if one is specified, determine the storage size of each raster block. You should select raster block dimensions that, combined with the compression method, allow each row of the raster block table to fit within the DBMS.
The raster blocks table contains the RASTERBAND_ID column, which is a foreign key reference to the raster band table's RASTERBAND_ID primary key. These tables are joined together on the primary/foreign key reference when accessing the blocks of the raster bands.
The raster blocks table is populated according to a declining resolution pyramid. The height of the pyramid is determined by the number of levels, specified by application. The application, such as geoprocessing tools or ArcCatalog, might allow you to define the levels, request that ArcSDE calculate them, or offer both choices. The pyramid begins at the base, or level 0, which contains the original pixels of the image. The pyramid proceeds toward the apex by coalescing four pixels from the previous level into a single pixel at the current level. This process continues until ArcSDE reaches the apex, which may be automatically defined or user defined.
The additional levels of the pyramid increase the number of raster blocks by as much as one-third. However, since you can specify the number of levels, the size of the pyramid can be less. The first level of the pyramid will be 25 percent of the base. It should also be noted that the first level of the pyramid can be skipped, a factor that can greatly reduce the size of the pyramid.
 |
A raster pyramid |
When you build a pyramid, more rasters are created by progressively downsampling the previous level by a factor of two until the apex. As the application zooms out and the raster cells grow smaller than the resolution threshold, ArcSDE selects a higher level of the pyramid. The purpose of the pyramid is to optimize display performance.
|
Field name |
Field type |
Description |
Null? |
|---|---|---|---|
|
rasterband_id |
integer |
A number that represents a raster band; for example, a raster dataset with two raster bands would have two different values in this field—1 and 2. |
NOT NULL |
|
rrd_factor |
integer |
Pyramid level; pyramid levels begin at 0 and can increase from there. |
NOT NULL |
|
row_nbr |
integer |
Tile row number position |
NOT NULL |
|
col_nbr |
integer |
Column row number position |
NOT NULL |
|
block_data |
bytea |
Pixel data stored in the tile |
NOT NULL |
The raster band table stores information about the bands of the images. There is one record for each raster band.
ArcSDE geodatabases store raster bands in the raster bands table. ArcSDE joins the raster bands table to the raster table on the RASTER_ID column. The RASTER_ID of the raster band table column is a foreign key reference to the raster table primary key.
|
Field name |
Field type |
Description |
Null? |
|---|---|---|---|
|
rasterband_id |
integer |
A number that represents a raster band; for example, a raster dataset with two raster bands would have two different values in this field—1 and 2. |
NOT NULL |
|
sequence_nbr |
integer |
Sequence of the raster band within the raster dataset |
NOT NULL |
|
raster_id |
integer |
The unique identifier of the raster dataset; corresponds to the value in the raster column of the business table |
NOT NULL |
|
name |
varchar(65) |
The optional raster band name |
|
|
band_flags |
integer |
A bitmask containing properties about the band |
NOT NULL |
|
band_width |
integer |
The pixel width of the band |
NOT NULL |
|
band_height |
integer |
The pixel height of the band |
NOT NULL |
|
band_types |
integer |
A bit mask containing properties about the band |
NOT NULL |
|
block_width |
integer |
The pixel width of a block |
NOT NULL |
|
block_height |
integer |
The pixel height of a block |
NOT NULL |
|
block_origin_x |
double precision |
The x-coordinate of the raster origin |
NOT NULL |
|
block_origin_y |
double precision |
The y-coordinate of the raster origin. |
NOT NULL |
|
eminx |
double precision |
The minimum x-value of a raster band |
NOT NULL |
|
eminy |
double precision |
The minimum y-value of a raster band |
NOT NULL |
|
emaxx |
double precision |
The maximum y-value in a raster band |
NOT NULL |
|
emaxy |
double precision |
The maximum y-value in a raster band |
NOT NULL |
|
cdate |
integer |
The creation date of the raster band |
NOT NULL |
|
mdate |
integer |
The last modification date of the raster band |
NOT NULL |
The raster description table stores the description of the images within a raster column.
|
Field name |
Field type |
Description |
Null? |
|---|---|---|---|
|
raster_id |
integer |
The unique identifier of the raster dataset; corresponds to the value in the raster column of the business table |
NOT NULL |
|
raster_flags |
integer |
Reserved for future use |
|
|
description |
varchar(65) |
The description of the raster dataset |
Other system tables to track rasters
Like other types of data, raster catalogs and datasets are tracked in the gdb_items and sde_layers tables. Columns of type raster are tracked in the sde_raster_columns table—there is one entry for every table containing a raster column.
There can be additional attribute tables as part of the raster dataset or raster catalog. There would only ever be one raster attribute table per raster dataset, but raster catalogs could have several such tables. The raster attribute tables are used to define attributes for particular raster cell values. See Raster dataset attribute tables for information on using these tables.
You can use the Build Raster Attribute tool of the Raster Properties toolset in the Raster toolset of the Data Management toolbox. See the topic Build Raster Attribute Table (Data Management) for details on this tool.
For raster datasets, the additional attribute tables are named in the format sde_vat_<raster_column_ID>. For raster catalogs, the table name is in the format sde_vat_<raster_column_ID>_<Object_ID>.
View a diagram of a raster dataset using bytea storage in PostgreSQL.
Dashed lines indicate implicit relationships between columns.
Note:You need Adobe Acrobat Reader to open the file.
Rasters stored in ST_Raster format
ST_Raster is a user-defined object type that is made up of subtypes. A raster dataset that uses ST_Raster storage is made up of three tables: the business table, auxiliary table, and block tables. When ST_Raster storage is used in a geodatabase, the equivalent information that would be stored in the raster and raster band tables for binary rasters is part of the ST_Raster object in the base table. The ST_Raster object also stores the geometry for the raster.
Rasters stored in ST_Raster format have auxiliary (sde_aux_<raster_ID>) and block (sde_blk_<raster_ID>) tables (see the "Raster image tables" section of this topic), but do not use raster band (sde_bnd_<raster_ID>) or raster (sde_ras_<raster_ID>) tables
View a diagram of a raster dataset using ST_Raster storage in PostgreSQL.
Dashed lines indicate implicit relationships between columns.
Note:You need Adobe Acrobat Reader to open the file.
Rasters in an XML workspace document
Raster datasets are enclosed in DataElement tags in an XML document. The tags have the value "esri:DERasterDataset".
<DataElement xsi:type="esri:DERasterDataset">
<CatalogPath>/V=sde.DEFAULT/RD=m8db.rocket.qa_ras_seattle2_xf</CatalogPath>
<Name>m8db.rocket.qa_ras_seattle2_xf</Name>
<Children xsi:type="esri:ArrayOfDataElement">
<DataElement xsi:type="esri:DERasterBand">
<CatalogPath>/V=sde.DEFAULT/RD=m8db.rocket.qa_ras_seattle2_xf/RB=Band_1</CatalogPath>
<Name>Band_1</Name>
<DatasetType>esriDTRasterBand</DatasetType>
<DSID>-1</DSID>
<Versioned>false</Versioned>
<CanVersion>false</CanVersion>
<HasOID>true</HasOID>
<OIDFieldName>ObjectID</OIDFieldName>
<Fields xsi:type="esri:Fields">
<FieldArray xsi:type="esri:ArrayOfField">
<Field xsi:type="esri:Field">
<Name>ObjectID</Name>
<Type>esriFieldTypeOID</Type>
<IsNullable>false</IsNullable>
<Length>4</Length>
<Precision>0</Precision>
<Scale>0</Scale>
<Required>true</Required>
<Editable>false</Editable>
</Field>
<Field xsi:type="esri:Field">
<Name>Value</Name>
<Type>esriFieldTypeInteger</Type>
<IsNullable>true</IsNullable>
<Length>0</Length>
<Precision>0</Precision>
<Scale>0</Scale>
</Field>
<Field xsi:type="esri:Field">
<Name>Count</Name>
<Type>esriFieldTypeInteger</Type>
<IsNullable>true</IsNullable>
<Length>0</Length>
<Precision>0</Precision>
<Scale>0</Scale>
</Field>
</FieldArray>
</Fields>
<Indexes xsi:type="esri:Indexes">
<IndexArray xsi:type="esri:ArrayOfIndex" />
</Indexes>
<IsInteger>true</IsInteger>
<MeanCellHeight>0.175996089009095</MeanCellHeight>
<MeanCellWidth>0.176000337991447</MeanCellWidth>
<Height>1024</Height>
<Width>2048</Width>
<PixelType>U8</PixelType>
<PrimaryField>1</PrimaryField>
<TableType>esriRasterTableValue</TableType>
<Extent xsi:type="esri:EnvelopeN">
<XMin>-179.906382261841</XMin>
<YMin>-90.1303147686327</YMin>
<XMax>180.542309944643</XMax>
<YMax>90.089680376681</YMax>
<SpatialReference xsi:type="esri:GeographicCoordinateSystem">
<WKT>GEOGCS["GCS_WGS_1984", DATUM["D_WGS_1984", SPHEROID["WGS_1984",6378137.0,298.257223563]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]]</WKT>
<XOrigin>-400</XOrigin>
<YOrigin>-400</YOrigin>
<XYScale>11258999068426.2</XYScale>
<ZOrigin>0</ZOrigin>
<ZScale>1</ZScale>
<MOrigin>0</MOrigin>
<MScale>1</MScale>
<XYTolerance>8.98315284119521E-09</XYTolerance>
<ZTolerance>2</ZTolerance>
<MTolerance>2</MTolerance>
<HighPrecision>true</HighPrecision>
<LeftLongitude>-180</LeftLongitude>
</SpatialReference>
</Extent>
</DataElement>