PostGIS (Raster) Writer Feature Type Parameters
To access feature type parameters, click the gear icon on a feature type in the workspace to open the Feature Type Parameter Editor. To always display the editor in Workbench, you can select View > Windows > Parameter Editor.
General
All feature types share similar General parameters, including the Feature Type Name, Reader or Writer Name, and Geometry.
In most Writer Feature Type parameter dialogs, you can also control Dynamic Schema Definitions. Some database formats accept a Table Qualifier prefix on the output table feature type.
See Editing Writer Feature Types for more information.
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 now 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: Write to an existing table or list. If the 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. The writer will drop and re-create the table before writing any features to it. Tables will be overwritten when the first input feature is processed. If no features are sent to a feature type, then the corresponding table will not be overwritten.
- Truncate Existing: (This option is not available for all formats.) If destination table/list does not exist, the translation will fail. Otherwise, delete all rows from existing table or list.
When updating features, users have a choice to update, or skip, their spatial column(s). Possible options are:
- Yes: The spatial column(s) specified by the user will be updated. IFMENulls will be written as null values and replace existing spatial values.
- No: No spatial columns will be updated.
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.
This parameter opens a WHERE Clause Builder. You can also type a WHERE clause inline, without launching the Builder. It is optional to start the clause with the word 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, the 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: 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
The parameters in this section take effect only when FME creates a table.
Specifies whether a system OID column should be created or not. OIDs are not guaranteed to be unique feature identifiers, and their use is deprecated outside of system tables. If set to No, then the OID column is not created.
This parameter determines whether or not a GiST index is created on the geometry column of the table (as long as one exists). This indexing of the geometry column is required for spatial query performance.
Table Settings: Raster
Specifies the name of the column to be created that will hold the raster data when creating a new PostGIS table.
Specifies the spatial referencing information for the rasters in the table. By default, this value is not set, which causes the conversion of the FME coordinate system of the writer into an SRID to be used as the SRID for the given table.
Alternatively, a specific integer SRID value may be specified. Specified SRID values should correspond to an existing spatial reference identifier value stored in the (SRID) column in the global table spatial_ref_sys.
Note:
- All rasters within a given table must have the same spatial referencing.
- If this parameter is left blank, tables will be created with the SRID of the writer coordinate system.
- If no SRIDs are desired, the value for the SRID field can be set to 0, indicating no spatial reference system.
Drops all raster constraints for the column being written.
Add Constraints
All the constraints below can be added to existing tables.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same SRID.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same x spacing.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same y spacing.
This parameter adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same number of pixels per raster row.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same number of pixels per raster column.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same alignment (skew, scale, and SRID).
Adds a raster constraint for the column being written, and specifies that the rasters in the column form a rectangular grid.
Note: Unlike other constraints, this flag is informational only, and is not enforced.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same number of bands.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same data type.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same NoData value.
Adds a raster constraint for the column being written, and specifies that all rasters in the column must have the same value for the out-db flag.
Adds a raster constraint for the column being written, and specifies that all rasters added to the column must be within the extent of the existing rasters.
An Overview constraint can be added to existing tables.
- Overview Base Schema: Specifies that the current raster column being written is an overview of another raster column. Used with the Overview Base Table and Overview Base Column parameters, it specifies the column that is the “base” column for the current raster column being written.
- Overview Base Table: Specifies that the current raster column being written is an overview of another raster column. Used with the Overview Base Schema and Overview Base Column parameters, it specifies the column that is the “base” column for the current one. If Add Overview Constraint is selected, this parameter is required.
- Overview Base Column: Specifies that the current raster column being written is an overview of another raster column. Used with the Overview Base Schema and Overview Base Table parameters, it specifies the column that is the “base” column for the current one. If Add Overview Constraint is selected, this parameter is required.
- Overview Factor: Specifies that the current raster column being written is an overview of another raster column. This parameter specifies what pyramid level this column represents. Level 1 is assumed to be the base data. Each higher level reduces the number of rows and columns by a factor of 2. For example, if level 1 is 512x512, then level 2 should be 256x256, level 3 should be 128x128, etc. If Add Overview Constraint is selected, this parameter is required.
Table Settings: Advanced
Specifies the maximum allowable size for a raster.
PostGIS stores a raster as a single blob, including all of its metadata. Thus, FME must process the raster as a single component and attempting to write very large rasters may result in out-of-memory errors. By default this is set at a relatively small size. This may be increased to accommodate larger rasters if memory is available.
Sets the byte order of the output raster. Valid values are MSB, LSB, and machine (meaning the native byte order of the machine running FME).
Specifies the bit depth of the data being 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.
Determines if the database function to vacuum and analyze the table is performed once the table is successfully written. This will build statistics for the table.
Allows the writer to overwrite the values of automatically populated serial columns specified on feature tables.
(Note that in PostgreSQL, serial columns are equivalent to a sequence.)