A GeoRaster database is typically very large. For storage and performance reasons, a database schema should use one or more user tablespaces for GeoRaster data storage (avoid using the system tablespace for storing GeoRaster data), and you should add data files to the tablespaces appropriately. If Oracle Automatic Storage Management (Oracle ASM) or a bigfile tablespace is not being used, you should create many data files for each tablespace and distribute the data files on different disks if possible. You also should create data files or alter existing data files, so that they automatically increase in size when more space is needed in the database.

A GeoRaster table can contain a large (potentially almost unlimited) number of GeoRaster objects. A raster data table (RDT) should be used to contain the raster blocks of a limited number of GeoRaster objects, depending on the size of the rasters. In contrast with GeoRaster tables, an RDT should not grow too large, unless partitioning is to be applied. Also, RDTs can be created on different tablespaces, so that the raster blocks are distributed to different disks. (See also Creating the GeoRaster Table and Raster Data Tables.)

A GeoRaster database may use a temporary tablespace for some operations. When compression is involved in GeoRaster operations, particularly for large scale mosaicking operations, some temporary spaces are needed to store intermediate compressed or uncompressed data. If the GeoRaster user does not have a temporary tablespace, the database system temporary tablespace is used. This is not efficient and may slow down the mosaicking and other operations. Therefore, you should always create temporary tablespaces for GeoRaster users. For example:

CONNECT system/<password>; 
CREATE TEMPORARY TABLESPACE geor_temp TEMPFILE 'geor_temp_1.f' SIZE 1G AUTOEXTEND ON; 
ALTER USER <georaster_user> TEMPORARY TABLESPACE geor_temp;

In general, the amount of temporary space needed is limited. However, for large scale mosaicking, if the result is to be compressed, the temporary space needed is equal to the uncompressed image size of the result. Therefore, specify AUTOEXTEND ON when you create temporary tablespaces for GeoRaster users.

Before you can work with GeoRaster objects, you must create a GeoRaster table and one or more raster data tables, if they do not already exist.

Topics:

• Creating a GeoRaster Table
  
• Creating Raster Data Tables
  
• GeoRaster DML Trigger
  

Before you can store a GeoRaster image in a GeoRaster table, you must create the GeoRaster object and insert it into a GeoRaster table before you start working on it. To create a new GeoRaster object, you have the following options:

• Initialize an empty GeoRaster object, using the SDO_GEOR.init function.

• Create a blank GeoRaster object, using the SDO_GEOR.createBlank function.

You cannot perform any GeoRaster operations if the object has not been properly created (that is, if the object is an atomic null). The SDO_GEOR.init and SDO_GEOR.createBlank functions initialize GeoRaster objects with their raster data table and raster ID values if these are not already specified, and the GeoRaster DML trigger ensures that the raster data table name and raster ID value pair is unique for the current user.

If the new GeoRaster object will hold raster cell data (resulting from another GeoRaster procedure, such as SDO_GEOR.importFrom, SDO_GEOR.subset, or SDO_GEOR.copy), and if the raster data table for this new GeoRaster object does not exist, you must first create the raster data table. For information about creating a raster data table, including examples, see Creating Raster Data Tables.

To avoid potential GeoRaster data problems (some of which are described in Maintaining GeoRaster Objects and System Data in the Database), an initialized GeoRaster object must be registered in the GeoRaster system views, which is done automatically when you insert the GeoRaster object into a GeoRaster table. This should be done before you perform any other operations on the GeoRaster object. Any GeoRaster operations that need to manipulate the raster data table raise an exception if the source or target GeoRaster object is not registered.

To load and export imagery or raster data, you can consider third-party ETL tools (see the note in GeoRaster Tools: Viewer_ Loader_ Exporter). For example, you can use the gdal_translate command line and other GDAL utilities (http://www.gdal.org/gdal_utilities.html), which fully supports GeoRaster through the Oracle Spatial GeoRaster driver.

You can also use features in GeoRaster to load raster data, With GeoRaster, you have the following options:

• Use the GDAL based ETL tool for concurrent batch loading and exporting. This tool is described in GDAL-Based ETL Wizard for Concurrent Batch Loading and Exporting.

• Call the SDO_GEOR.importFrom procedure to load images into GeoRaster objects.

• Use the GeoRaster JAI-based loader tool or viewer tool, which are described in JAI-Based Viewer_ Loader_ and Exporter.

With the last two options (SDO_GEOR.importFrom and JAI-based tool), you can do the following:

• Compress raster data and store the data in JPEG-compressed or DEFLATE-compressed GeoRaster objects.

• Load an ESRI world file or a Digital Globe RPC text file (.rpb) into an existing GeoRaster object, and georeference the raster data without reloading it. You can also specify an SRID with the world file and generate the spatial extent of the data.

• Load a GeoTIFF format file with georeferencing, with or without raster data. To load and export the georeferencing information of GeoTIFF images, the GeoTIFF libraries are required. See Georeferencing GeoRaster Objects for instructions.

After loading raster data into a GeoRaster object, you must ensure that the object is valid by calling the SDO_GEOR.validateGeoRaster function, as explained in Validating GeoRaster Objects.

Because an ESRI world file or .rpb file does not contain coordinate system information, you can specify the SRID value of a coordinate reference system for the load operation. However, if you do not specify an SRID, the model SRID of the GeoRaster objects is set to 0 (zero) by the loader, which means that the GeoRaster object is invalid, and therefore you must use the SDO_GEOR.setModelSRID procedure to specify a valid model space for this object. If you do not yet know the coordinate system of the model space, you can specify the SRID value as 999999, which means that the coordinate reference system is unknown. (Specifically, SRID 999999 is associated with a coordinate reference system named unknown CRS.) Later, when you know the actual coordinate reference system of the model space, you can set the SRID value accordingly.

For more information about the unknown CRS (SRID 999999) coordinate reference system, see Oracle Spatial and Graph Developer's Guide.

Topics:

• Loading with Blocking and Optimal Padding
  
• Loading JPEG and JPEG 2000 Images Without Decompression
  
• Reformatting the Source Raster Before Loading
  

Before you use a GeoRaster object or after you manually edit the raster data and metadata of a GeoRaster object, you should ensure that the object is valid. Validation for a GeoRaster object includes checking the registration of the GeoRaster object, checking the metadata and the raster cell data, and making sure that the metadata and data are consistent. For example, validation checks the raster type, dimension information, and the actual sizes of cell blocks, and it performs other checks.

If you used the GeoRaster loader tool described in GeoRaster Tools: Viewer_ Loader_ Exporter, the GeoRaster objects were validated during the load operation.

GeoRaster provides the following validation subprograms:

• SDO_GEOR.validateGeoRaster validates the GeoRaster object, including cell data and metadata. It returns TRUE if the object is valid; otherwise, it returns one of the following: an Oracle error code indicating why the GeoRaster object is invalid, FALSE if validation fails for an unknown reason, or NULL if the GeoRaster object is null. You should always use this function after you create a GeoRaster object.

• SDO_GEOR.schemaValidate validates the metadata against the GeoRaster XML schema. You can use this function to locate errors if the SDO_GEOR.validateGeoRaster function returned the error code 13454. The SDO_GEOR.schemaValidate and SDO_GEOR.validateGeoRaster functions do not validate the spatial extent geometry.

• SDO_GEOR.validateBlockMBR validates the blockMBR geometry associated with each raster block stored in the raster data table. If there are any invalid blockMBR geometries, call the SDO_GEOR.generateBlockMBR procedure to regenerate them.

Georeferencing, as explained in Georeferencing, establishes the relationship between cell coordinates of GeoRaster data and real-world ground coordinates (or some local coordinates). If you need to georeference GeoRaster objects, the following approaches are available:

• If the original image is already georeferenced and if the georeferencing information is stored in an ESRI world file or .rpb file containing RPC coefficients you can use the SDO_GEOR.importFrom procedure to load an ESRI world file or .rpb file from a file or from a CLOB object, along with the image data itself (in either FILE or BLOB format). You can also use the GeoRaster client-side loader tool (described in GeoRaster Tools: Viewer_ Loader_ Exporter) to load an ESRI world file or .rpb file from a file, along with the image file itself.

  Because an ESRI world file or .rpb file does not specify the model coordinate system, you can set the model space of the georeferenced GeoRaster object using an Oracle SRID in either of the following ways: specify the SRID along with the world file as a parameter to the SDO_GEOR.importFrom procedure or the GeoRaster client-side loader (described in GeoRaster Tools: Viewer_ Loader_ Exporter); or, after loading the world file, call the SDO_GEOR.setModelSRID procedure. You can also call the SDO_GEOR.setModelSRID procedure to change the model space of a georeferenced GeoRaster object.

• If the original image is a georeferenced GeoTIFF image, you can use the SDO_GEOR.importFrom procedure to load the image with georeferencing, by specifying GEOTIFF as the input format. To load only the georeferencing information from a GeoTIFF image, without the raster image data, into an existing GeoRaster object, add the raster=false storage parameter. You can specify a backup SRID with the srid storage parameter, in case the GeoTIFF configuration values do not match any SRID recognized by Oracle Spatial and Graph.

  The GeoTIFF PixelIsArea raster space is equivalent to the GeoRaster upperleft-based cell coordinate system. An export to GeoTiff is always in PixelIsArea raster space, with a half-pixel adjustment of the affine transformation if the GeoRaster object is in center-based cell coordinate system. An import from GeoTIFF is always to the GeoRaster center-based cell coordinate system, with a half-pixel adjustment of the affine transformation if the GeoTIFF file is specified in PixelIsArea raster space.

  You can also use the GeoRaster client-side loader tool (described in GeoRaster Tools: Viewer_ Loader_ Exporter) to load GeoTIFF images with georeferencing, using the storage parameter geotiff=true. If you omit this parameter or specify geotiff=false, the image is loaded as a simple TIFF image without georeferencing. The raster and srid storage parameters also apply to the client-side loader tool.

  To load or export GeoTIFF images with the GeoRaster client-side tools, add the following GeoTIFF libraries to your CLASSPATH definition:

  • xtiff-jai.jar (available from the SourceForge Extensible-TIFF-JAI group)

  • geotiff-jai.jar (available from the SourceForge GeoTIFF-JAI group)

  To load or export GeoTIFF images with the SDO_GEOR.importFrom or SDO_GEOR.exportTo procedure, load these libraries into the MDSYS schema by connecting to the database as the SYSTEM user, editing $ORACLE_HOME/md/admin/sdoldgtf.sql as needed to reflect the paths to the xtiff-jai.jar and geotiff-jai.jar files, and running the sdoldgtf.sql SQL*Plus script. As an alternative to using the sdoldgtf.sql script, you can enter the following commands:

  loadjava -user system/password@database -resolve -force -synonym -schema MDSYS -grant PUBLIC xtiff-jai.jar
  
  loadjava -user system/password@database -resolve -force -synonym -schema MDSYS -grant PUBLIC geotiff-jai.jar
  

  If the database is downgraded to a release before Oracle Database 11g, these libraries should be uninstalled according to the script in $ORACLE_HOME/md/admin/sdormgtf.sql, editing it as needed to reflect the paths to the xtiff-jai.jar and geotiff-jai.jar files, and either running the sdormgtf.sql script or entering the following commands:

  dropjava -user system/password@database -resolve -force -synonym -schema MDSYS -grant PUBLIC xtiff-jai.jar
  
  dropjava -user system/password@database -resolve -force -synonym -schema MDSYS -grant PUBLIC geotiff-jai.jar
  

• You can use the SDO_GEOR.setSRS procedure to add, modify, and delete georeferencing information by directly accessing the GeoRaster SRS metadata. For example, you can create an SDO_GEOR_SRS object and assign the coefficients and related georeferencing information, and then call the SDO_GEOR.setSRS procedure to add or update the spatial reference information of any GeoRaster object. You can use the SDO_GEOR.setSRS procedure to set up the spatial reference information for all supported functional fitting georeferencing models. Examples of setting up the SRS information from an existing DLT model and from an existing RPC model are included in reference section for the SDO_GEOR.setSRS procedure.

  If you know that one GeoRaster object has the same SRS information as another GeoRaster object, you can call the SDO_GEOR.getSRS function to retrieve an SDO_GEOR_SRS object from this GeoRaster object, and then call the SDO_GEOR.setSRS procedure to georeference the first GeoRaster object.

• If the GeoRaster object can be georeferenced using an affine transformation, you can call the SDO_GEOR.georeference procedure to georeference a GeoRaster object directly. As described in the reference information for the SDO_GEOR.georeference, this procedure takes the coefficients A, B, C, D, E, F and other information, converts them into the coefficients a, b, c, d, e, f, and stores them in the spatial reference information of a GeoRaster object. If the original raster data is rectified and if the model coordinate of its origin (upper-left corner) is (x0, y0) and its spatial resolution or scale is s, then the following are true: A = s, B = 0, C = x0, D = 0, E = -s, F = y0.

• If you have ground control points (GCPs) or want to collect GCPs yourself, you can call the SDO_GEOR.georeference function to georeference the GeoRaster object. For more information, see Advanced Georeferencing.

Based on the SRS information of a georeferenced GeoRaster object, transforming GeoRaster coordinate information means finding the model (ground) coordinate associated with a specific cell (raster) coordinate, and the reverse. That is, you can do the following:

• Given a specific cell coordinate, you can find the associated model space coordinate using the SDO_GEOR.getModelCoordinate function. For example, if you identify a point in an image, you can find the longitude and latitude coordinates associated with that point.

• Given a model space coordinate, you can find the associated cell coordinate using the SDO_GEOR.getCellCoordinate function. For example, if you identify longitude and latitude coordinates, you can find the cell in an image associated with those coordinates.

When a GeoRaster object is created, its spatial extent (spatialExtent attribute, described in spatialExtent Attribute) is not necessarily the enclosing geometry in its model space coordinate system. The spatial extent (footprint) geometry might initially be null, or it might reflect the cell space coordinate system or some other coordinate system. The ability to generate and set spatial extents is useful for building large GeoRaster databases of a global or large regional scope, in which the spatial extents are in one global geodetic coordinate system while the GeoRaster objects (imagery, DEMs, and so on) are in different projected coordinate systems. In such a case, you can create a spatial (R-tree) index on the spatial extents, which requires that all spatial extent geometries have the same SRID value.

To ensure that the spatial extent geometry of each GeoRaster object in a table is correct for its model space coordinate system (or for any other coordinate system that you may want to use), you must set the spatial extent. Moreover, to use a spatial index on the spatial extent geometries (described in Indexing GeoRaster Objects), all indexed geometries must be based on the same coordinate system (that is, have the same SRID value).

You can set the spatial extent in any of the following ways: specify spatialExtent=TRUE as a storage parameter to the SDO_GEOR.importFrom procedure or the GeoRaster client-side loader (described in GeoRaster Tools: Viewer_ Loader_ Exporter), use the SQL UPDATE statement, or set the spatial extent during loading with GDAL. If you use the SDO_GEOR.importFrom procedure or the loader, the SRID cannot be null or 0 (zero), and if there is an R-tree index on the GeoRaster spatial extent, the SRID of the spatial extent must match the SRID of the existing spatial index; otherwise, the spatial extent is set to a null value.

In addition, if you do not already have the spatial extent geometry, you can generate it using the SDO_GEOR.generateSpatialExtent function, and use that geometry to update the GeoRaster object. The following example updates the spatial extent geometry of a specified GeoRaster object in the CITY_IMAGES table (created in Example 3-1 in Creating a GeoRaster Table) to the generated spatial extent (reflecting the model coordinate system) of that object:

UPDATE city_images c
  SET c.image.spatialExtent = sdo_geor.generateSpatialExtent(image)
    WHERE c.image_id = 100;
COMMIT;

The following example updates the spatial extent geometry of all GeoRaster objects in the CITY_IMAGES table to the generated spatial extent (reflecting the model coordinate system) of that object:

UPDATE city_images c
  SET c.image.spatialExtent = sdo_geor.generateSpatialExtent(image)
    WHERE c.image.spatialExtent is null;
COMMIT;

If you already know the spatial extent geometry for a GeoRaster object, or if you want the spatial extent geometry to be based on a coordinate system other than the one for the model space, construct the SDO_GEOMETRY object or select it from a table, and then update the GeoRaster object to set its spatial extent attribute to that geometry, as shown in the following example:

DECLARE
 geom sdo_geometry;
BEGIN
-- Set geom to an SDO_GEOMETRY object that covers the spatial extent
-- of the desired GeoRaster object. If necessary, perform coordinate
-- system transformation before setting geom.
-- geom := sdo_geometry(...);
  UPDATE city_images c
    SET c.image.spatialExtent = geom WHERE c.image_id = 100;
  COMMIT;
END;

Topics:

• Special Considerations if the GeoRaster Table Has a Spatial Index
  

1. Insert a row into the USER_SDO_GEOM_METADATA view with the georaster table name (CITY_IMAGES in this example) and the spatial extent of the GeoRaster column name (IMAGE.SPATIALEXTENT). Be sure that the correct SRID value (3371 in this example) is registered.

   INSERT INTO user_sdo_geom_metadata
       (TABLE_NAME,
        COLUMN_NAME,
        DIMINFO,
        SRID)
   VALUES (
        'city_images',
        'image.spatialextent',
        SDO_DIM_ARRAY(
           SDO_DIM_ELEMENT('X', -1000000000, 1000000000, 0.005),
           SDO_DIM_ELEMENT('Y', -1000000000, 1000000000, 0.005)),
        3371
   );
   

2. Create a spatial index on the GeoRaster column, as in the following example which creates a spatial index named CITY_IMAGES_IDX on the spatial extents of the images using default values for all parameters.

   CREATE INDEX city_images_idx 
         ON city_images (image.spatialextent)
         INDEXTYPE IS MDSYS.SPATIAL_INDEX;
   

   The preceding statement may fail if there are some invalid spatial extents or if the SRID values in the GeoRaster table do not match the SRID registered in the preceding step. If the statement fails, ensure that all GeoRaster objects have a valid spatialExtent geometry attribute and that all spatialExtent geometries have the same SRID. (Null for the spatialExtent values is acceptable.) Then re-create the spatial index.

To view GeoRaster objects, you have the following options:

• Call the SDO_GEOR.exportTo procedure to export GeoRaster objects to image files, and then display the images using image tools or a Web browser.

• Use the standalone GeoRaster viewer tool (one of the tools described in GeoRaster Tools: Viewer_ Loader_ Exporter).

• Use Oracle Fusion Middleware MapViewer or its associated Map Builder utility.

With the GeoRaster viewer tool, you can select a GeoRaster object of a database schema (user), query and display the whole or a subset of a GeoRaster object, zoom in and zoom out, scroll, and perform other basic operations. The pyramid level, cell coordinates, and model coordinates (if the object is georeferenced) are displayed for the point at the mouse pointer location. You can display individual cell values and choose different layers of a multiband or hyperspectral image for RGB full color display. The blocking boundaries can be overlapped on the top of the display. Depending on the data and your requests, the viewer can display the raster data in grayscale, pseudocolor, and 24-bit true color over an intranet or the Internet. Some of the basic GeoRaster metadata is also displayed.

The GeoRaster viewer tool allows you to display a virtual mosaic defined as one or a list of GeoRaster tables or views.

The GeoRaster viewer tool provides a set of image processing operators for enhanced display of the GeoRaster objects, especially for those whose cell depth is greater than 8 or is a floating-point number. It can also display and apply bitmap masks on the GeoRaster objects if they have bitmap masks.

The GeoRaster viewer tool also includes menu commands to 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.

Visualization applications can leverage the default RGBA and default pyramid level specifications in the GeoRaster objects. You can set up different bands in a multiband image as the default Red, Green, Blue, and Alpha channels by calling SDO_GEOR.setDefaultColorLayer or SDO_GEOR.setDefaultRed, SDO_GEOR.setDefaultGreen, SDO_GEOR.setDefaultBlue, and SDO_GEOR.setDefaultAlpha. For large images, you can call SDO_GEOR.setDefaultPyramidLevel to set up the best resolution (pyramid) level of an image for initial display in the applications. For example, for a complete overview of a whole image, it is best to set the top pyramid level as the default pyramid level.

To load and export imagery or raster data, always consider third-party ETL tools (see the note in GeoRaster Tools: Viewer_ Loader_ Exporter)

If you use features in GeoRaster to export GeoRaster objects to image files, you have the following options:

• Use the GDAL-based ETL tool for concurrent batch exporting, which is described in GDAL-Based ETL Wizard for Concurrent Batch Loading and Exporting.

• Call the SDO_GEOR.exportTo procedure (which can export either to a file or to a BLOB object).

• Use the GeoRaster exporter tool or viewer tool, which are described in GeoRaster Tools: Viewer_ Loader_ Exporter.

Oracle Workspace Manager provides a versioning capability for the raster blocks of a GeoRaster object. Oracle Label Security supports GeoRaster objects with enhanced security at the row level of raster blocks.

To use GeoRaster with Oracle Workspace Manager or Oracle Label Security, you should create a raster data table (RDT) as a relational table for the GeoRaster objects (see Example 3-3). You do not need to define an object view of SDO_RASTER type on the base relational RDT.

Topics:

• Using GeoRaster with Workspace Manager
  
• Using GeoRaster with Label Security
  

After delete or rollback operations, unused space allocated to a raster data table might not be promptly returned to the underlying tablespace. This could result in wasted tablespace area, and it can be a significant issue if the amount of raster data is large. If the raster data table is created using BasicFiles LOBs in an automatic segment space management tablespace, you can explicitly shrink the rasterBlock LOB segment or the raster data table by altering the raster data table, as shown in Example 3-4 and Example 3-5.

ALTER TABLE city_images_rdt MODIFY LOB (rasterBlock) (SHRINK SPACE);

ALTER TABLE city_images_rdt ENABLE ROW MOVEMENT;
ALTER TABLE city_images_rdt SHRINK SPACE CASCADE;

If you are using SecureFiles, or if you are using BasicFiles allocated in a manual segment space management tablespace, you cannot reclaim unused space using the ALTER TABLE statements as shown in the preceding examples. Instead, you should create some working (for temporary use) raster data tables and try to put any intermittent results in these RDTs, and then drop these working RDTs after they are no longer needed.

For database management purposes, you might need check on GeoRaster tables and objects in the whole database or under a specific schema. After the GeoRaster database is created, you have the following options for checking or listing existing GeoRaster tables, RDT tables, and GeoRaster objects.

• Use the following subprograms check the status of existing GeoRaster objects and related objects in the current schema or the database, depending on the privileges associated with the database connection.

  SDO_GEOR_ADMIN.listGeoRasterObjects lists all GeoRaster objects defined in the current schema; or if you call this function while connected as the MDSYS user, all GeoRaster objects defined in the database are listed.

  SDO_GEOR_ADMIN.listGeoRasterColumns lists all GeoRaster columns defined in the current schema; or if you call this function while connected as the MDSYS user, all GeoRaster columns defined in the database are listed.

  SDO_GEOR_ADMIN.listGeoRasterTables lists all GeoRaster tables defined in the current schema; or if you call this function while connected as the MDSYS user, all GeoRaster tables defined in the database are listed.

  SDO_GEOR_ADMIN.listRDT lists all  raster data tables (RDTs) defined in the current schema; or if you call this function while connected as the MDSYS user, all raster data tables (RDTs) defined in the database are listed.

  SDO_GEOR_ADMIN.listRegisteredRDT lists all registered raster data tables (RDTs) defined in the current schema; or if you call this function while connected as the MDSYS user, all registered RDTs defined in the database are listed . An RDT is registered if at least one entry in the SYSDATA table refers to it.

  SDO_GEOR_ADMIN.listUnregisteredRDT lists all unregistered raster data tables (RDTs) defined in the current schema; or if you call this function while connected as the MDSYS user, all unregistered RDTs defined in the database are listed.. An RDT is unregistered if no entry in the SYSDATA table refers to it.

• Run SQL queries directly against GeoRaster metadata views, and check or list GeoRaster tables and objects stored in the different schemas. This approach is more flexible than calling subprograms. It also enables some query results that cannot be returned by functions defined in the SDO_GEOR_ADMIN package. The following are some sample queries.

  List all GeoRaster objects that are defined in the schema HERMAN and MYTEST and accessible by the current schema.

  SELECT owner,TABLE_NAME,COLUMN_NAME,RDT_TABLE_NAME,RASTER_ID from all_sdo_geor_sysdata where owner='HERMAN' or owner='MYTEST';

  Count the total number of GeoRaster objects accessible by the current schema.

  SELECT count(*) from all_sdo_geor_sysdata;

  Count the total number of GeoRaster objects stored in the GeoRaster table GTF_TABLE in the current schema.

  SELECT count(*) from user_sdo_geor_sysdata where TABLE_NAME='GTF_TABLE';

  List all GeoRaster objects stored in the RDT table RDT_1 in the current schema.

  SELECT TABLE_NAME,COLUMN_NAME,RDT_TABLE_NAME,RASTER_ID from user_sdo_geor_sysdata where RDT_TABLE_NAME='RDT_1';

  Find out all GeoRaster tables that store some raster data in or reference the RDT table RDT_1 in the current schema.

  SELECT distinct TABLE_NAME from user_sdo_geor_sysdata where RDT_TABLE_NAME='RDT_1';

  List all RDT tables that are used by the GeoRaster table GTF_TABLE in the current schema.

  SELECT distinct RDT_TABLE_NAME from user_sdo_geor_sysdata where TABLE_NAME='GTF_TABLE';

Although GeoRaster provides internal database mechanism to prevent the creation of invalid GeoRaster objects and system data, sometimes such GeoRaster objects and system data might exist in the database, especially after an upgrade from a previous release, or after some user errors in operations on GeoRaster system data. Examples of such invalid objects and system data include the following:

• An entry in the GeoRaster system data views (xxx_SDO_GEOR_SYSDATA, described in GeoRaster System Data Views (xxx_SDO_GEOR_SYSDATA)) refers to a nonexistent GeoRaster table or column.

• Two or more GeoRaster objects have the same pair of RDT name and raster ID values.

• Some GeoRaster objects, tables, columns, or RDTs not registered.

• An RDT name is not unique.

• A GeoRaster object is non-empty or nonblank, but an associated RDT does not exist.

After a database upgrade, you should call the SDO_GEOR_ADMIN.isUpgradeNeeded function to check for any invalid GeoRaster objects and invalid system data for the current version. If there are any errors or invalid data, call the SDO_GEOR_ADMIN.upgradeGeoRaster function to have the problems automatically corrected. If you connect as user MDSYS, the SDO_GEOR_ADMIN.upgradeGeoRaster function upgrades all GeoRaster objects in the database; otherwise, it upgrades only GeoRaster objects in the schema of the current user. (See the reference and usage information about SDO_GEOR_ADMIN.upgradeGeoRaster in SDO_GEOR_ADMIN Package Reference.)

For regular maintenance due to possible user errors, several functions and procedures will be helpful in checking for and correcting invalid GeoRaster objects and system data entries:

• To check for errors, call SDO_GEOR_ADMIN.checkSysdataEntries and SDO_GEOR_ADMIN.listUnregisteredRDT.

• To check for dangling raster data, call SDO_GEOR_ADMIN.listDanglingRasterData.

• To correct all invalid system data entries, call SDO_GEOR_ADMIN.maintainSysdataEntries.

• To create correct DML triggers for all GeoRaster columns, call SDO_GEOR_ADMIN.registerGeoRasterColumns.

• To register all existing GeoRaster objects in the sysdata table, call SDO_GEOR_ADMIN.registerGeoRasterObjects.

See the reference and usage information about these procedures and functions in SDO_GEOR_ADMIN Package Reference.

1. Check for and resolve any conflicts, as explained in Checking for and Resolving Conflicts.
2. Perform the data transfer, as explained in Performing the GeoRaster Data Transfer.

Topics:

• Checking for and Resolving Conflicts
  
• Performing the GeoRaster Data Transfer
  

1. Call the SDO_GEOR_ADMIN.registerGeoRasterObjects procedure (described in SDO_GEOR_ADMIN Package Reference) to register all GeoRaster objects in the current schema or new database.
2. Before you use the transported GeoRaster data, perform the "regular maintenance" operations described in Maintaining GeoRaster Objects and System Data in the Database, to maintain GeoRaster objects and system data and to ensure all GeoRaster objects are correctly transported and properly registered.
3. If you find any conflicts, call the SDO_GEOR_UTL.renameRDT or SDO_GEOR_UTL.makeRDTNamesUnique procedure to solve such conflicts, and validate again.