Writer Feature Type Properties: Format Parameters
To access feature type format parameters, open the Feature Type Properties dialog by clicking the properties button on a feature type in the workspace.
These parameters apply only to a selected feature type, not to the entire writer.
Tip: If a feature type parameter listed here conflicts with a writer-level parameter, then the writer parameter will be ignored and this feature type parameter will be used.
Table Settings: General
This parameter lets the user specify how features will be written into the destination table. Supported feature operations are:
- Insert: Append rows onto the destination table using attributes on features.
- Update: Update existing table columns using attributes on features. A selection method must be specified in the Row Selection group.
- Delete: Delete existing table rows. A selection method must be specified in the Row Selection group.
- fme_db_operation: The feature operation will be determined by the attribute fme_db_operation on each input feature. A selection method must be specified in the Row Selection group. The value of fme_db_operation will be processed as follows:
- If the value is null, empty, or missing, it will be treated as Insert.
- The value will next be matched to Insert, Update, and Delete, case insensitively.
- If there is no match, the feature will be rejected.
- If there is a match, the matched feature operation will be performed on the feature.
Tip: The fme_db_operation attribute will cause feature rejection when Feature Operation is set to Insert, Update, or Delete. This behavior differs from previous versions of FME.
More information on Feature Operations.
Controls how the feature type handles destination tables or lists. These options are available:
- Use Existing: If destination table/list does not exist, the translation will fail.
- Create If Needed: Create destination table/list if it does not exist.
- Drop and Create: Drop destination table/list if it exists, and then create it.
- Truncate Existing: If destination table/list does not exist, the translation will fail. Otherwise, delete all rows from existing table or list. This option is not available for all formats.
Row Selection
When inserting into a table, Row Selection is ignored. When updating and deleting from a table, a condition needs to be specified for selecting which rows to operate on. This parameter group offers two methods to construct the selection condition:
The columns specified in the corresponding column picker dialog will be used for matching destination rows. All matching rows will be selected for update or delete. If any feature attributes corresponding to the specified match columns contain null or missing values, the feature will be rejected.
The corresponding WHERE Clause Builder lets you construct a WHERE clause. You can also type in a WHERE clause inline, without launching the WHERE Clause Builder. It is optional to start the clause with the keyword WHERE.
The WHERE Clause Builder makes it easy for users to reference feature attribute values, destination table columns, and invoke FME functions. The WHERE clause is first evaluated as an FME expression, before being passed onto the destination database.
If the WHERE clause is incorrect or if its evaluation results in failure, translation will fail. Otherwise, if the WHERE clause passes FME evaluation but it is SQL invalid, the feature will be rejected or the translation will fail.
For advanced users, conditional FME expressions created through the Conditional Value editor can be used to create WHERE clauses.
Tip: Tip: You can set the WHERE Clause to an attribute. This supports workspace migration and existing workflows involving fme_where. (Direct support for fme_where has been deprecated.) To advanced users who are accustomed to using fme_where, if Feature Operation is set to Update, Delete, or fme_db_operation, an fme_where attribute that conflicts with Match Columns or WHERE Clause will result in feature rejection.
Table Creation Parameters
This specifies additional parameters to be appended to the Oracle CREATE TABLE query used to create the output table. It is used to specify table allocation characteristics and the like. For example, to specify a tablespace, a STORAGE clause, and a comment for a table, the following clause could be appended:
TABLESPACE myTableSpace
STORAGE (INITIAL 50K);
COMMENT ON TABLE myTable IS ‘My new table’;
This parameter specifies the large object (LOB) storage type used for storing raster data. It has an effect only when creating a new Raster Data Table (RDT).
The possible values are:
- BASICFILE specifies the original Oracle LOB storage type.
- SECUREFILE is a new LOB storage type introduced in version 11g which offers many advantages, including better performance.
- Auto depends on the version of the Oracle database being written to. When the version is 11g or later, SECUREFILE will be used; when the version is older than 11g, BASICFILE will be used.
This parameter is similar to the Raster SRID parameter except that this SRID only applies to the spatial extent geometry stored inside the GeoRaster object. This parameter allows users to set a different SRID for the extent of the raster than the raster itself.
Valid values include the valid range of SRID values acceptable to Oracle. The default value is 0, indicating no SRID is present (for example, non-georeferenced spatial data).
Note that this is done in two steps:
- The extents are written with the same SRID as the raster data.
- Reprojection into the specified Extent SRID occurs as a post-processing step.
Extents and Tolerances
Minimum X/Y Coordinate
The minimum x/y value expected in the dataset. If x/y values less than this value are supplied, the affected raster data is still written. However, querying the spatial index outside its extents will produce undefined results.
For best spatial search performance, this value should be as close to the true minimum x as possible.
Maximum X/Y Coordinate
The maximum x/y value expected in the dataset. If x/y values less than this value are supplied, the affected raster data is still written. However, querying the spatial index outside its extents will produce undefined results.
For best spatial search performance, this value should be as close to the true maximum x as possible.
This specifies the comparison tolerance for the x/y coordinates. Coordinates in x/y that are closer than this value are considered equal.
Raster
If this parameter has a non-blank value, the Oracle Spatial GeoRaster writer will create a column to hold the GeoRaster object when writing to the object model. The default column is typically called RAST, but may be changed to any other name.
Note that this parameter merely specifies a default value for the geometry column. If a GeoRaster column or columns are explicitly named on the DEF line, the explicit name will be chosen instead of the default. If the table already exists in the Oracle database, then the GeoRaster column will be chosen from those defined on the existing table.
The Raster Data Table (RDT) name for the given GeoRaster object. This table is where the pixel values of the input rasters will be stored.
The default value is an automatically generated table name based on the raster identifier, both of which are assigned by the database itself. The expected default table name is RDT_<rasterid>$.
This specifies the spatial referencing information for the geometry in the table. It is specified as an integer, and corresponds to the spatial reference identifier (SRID) column in the global table MDSYS.CS_SRS.
All geometry within a given table must have the same spatial reference. If the target table exists in the database and the value specified for Raster SRID parameter does not match the SRID column value in USER_SDO_GEOM_METADATA, the metadata's SRID will be used.
If this parameter is not specified, tables will be created with a null value for the SRID column in USER_SDO_GEOM_METADATA.
Specifies whether to validate the raster once written:
- Yes: This parameter employs native GeoRaster validation and logs either TRUE if the GeoRaster is valid, or else it logs the Oracle error number that defines the reason for invalidity.
- No: No validation will occur. Note that validation is performed post-writing but before pyramiding and compression.
Data Storage
The horizontal size in pixels of a tile in the Raster Data Table (RDT).
The value must be a power of 2.
The vertical size in pixels of a tile in the Raster Data Table (RDT).
The value must be a power of 2.
The type of compression to be used. This parameter is the one used to determine whether or not compression will occur.
Possible values:
- None
- DEFLATE
- JPEG-B
- JPEG-F
If the attribute value is set to None for an existing GeoRaster object, then the object will be uncompressed. Any other value will cause the specified type of compression to occur in a post-writing process.
The JPEG compression quality inversely describes the degree of lossiness caused by the compression. Valid values are integers from 0 (lowest quality) to 100 (highest quality). This value is ignored when not using one of the JPEG compression types.
This parameter specifies the type of interleaving to be applied to the raster data when written. Possible interleaving values are: BSQ (Band SeQuential), BIL (Band Interleaved by Line), or BIP (Band Interleaved by Pixel). If the raster contains only a single band. then interleaving is irrelevant. This interleaving parameter does not apply to palette values which are always BIP interleaved.
This parameter specifies the bit depth of the data when written. Possible values are 1, 2, 4, and Auto. When Auto is selected, the bit depth will be determined by the interpretation of the input raster bands. When a specific bit depth is selected, the interpretation of the input raster bands must be one of UINT8, GRAY8, RED8, GREEN8, BLUE8, and ALPHA8. In this case, data values will be truncated to the specified number of bits. For example, if the number of bits is set to 4, a value of 201 (1100 1001 in base 2) will become 9 (1001 in base 2).
Pyramid Generation
This parameter specifies the type of pyramid to create.
Possible values:
- None
- Decrease
If the attribute value is set to None for an existing GeoRaster object, the existing pyramids will be deleted.
This parameter specifies the maximum number of pyramid levels to be generated. It is a maximum because pyramids will not be generated when the number of rows or columns in a GeoRaster is less than 64.
The default for this value is to auto calculate the correct number of pyramid levels for the raster so that the smallest pyramid has at least 64 rows and columns.
The type of resampling to be applied when generating pyramid levels.
Possible values:
- NN (Nearest Neighbor is the default)
- BILINEAR
- AVERAGE4
- AVERAGE16
- CUBIC
Spatial Index
This parameter specifies whether or not a spatial index is to be created as part of the data writing.
Valid choices are Yes or No.
This parameter specifies whether to drop the spatial index for the table.
This parameter specifies the name of the spatial index that will be created on the table. If this is not specified, a spatial index name will be created based on a database sequence and the name of the table being written.
Advanced
This parameter specifies the Ground Control Point (GCP) table name for the external storage of GCPs that may exist in the source data. This may be unique for each raster.
The default GCP table name is the RDT table name with an suffix of _GCP. If GCPs are not present on any the input rasters, then this table will not be created.
This parameter specifies the index of the red/green/blue band in the raster.
Note that the index is zero-based so that the first band is at index 0. If this index is not present on any the input rasters, then a very simple default method is used to determine whether to treat 3- or 4-band rasters as RGB or RGBA.