This section describes the directives that are used when reading geometric feature classes and tables.
TRANSLATE_SPATIAL_DATA_ONLY
Required/Optional: Optional
This directive is used for translating spatial data only. When set to YES, non-spatial tables, relationships, domains, and subtypes will not be translated. If this directive is specified when generating a workspace or mapping file, then no schemas will be returned for non-spatial tables.
Parameter: <translate_spatial_data_only>
Values: YES | NO
Default Value: NO
Workbench Parameter: Spatial Data Only
Example:
GEODATABASE_MDB_TRANSLATE_SPATIAL_DATA_ONLY YES
RESOLVE_DOMAINS
Required/Optional: Optional
This directive specifies whether to resolve attributes that have a coded value domain associated with them (either a default domain, or one set up through a subtype). This means that when an attribute of a feature has a coded value domain associated with it, another attribute will also be added that represents the textual description of the coded attribute. The new attribute will be <attribute-name>_resolved, where <attribute-name> is the name of the attribute containing the code.
Parameter: <resolve_domains>
Values: YES | NO
Default Value: NO
Workbench Parameter: Resolve Domains
Example:
GEODATABASE_MDB_RESOLVE_DOMAINS YES
RESOLVE_SUBTYPE_NAMES
This directive specifies whether to resolve the subtype field of a feature. A feature that exists in a table that has subtypes will have an attribute that is the subtype field. The subtype field will hold an integer value that specifies which subtype the feature belongs to, and this integer value also has a string name equivalent called the description. If YES is specified for this directive, the corresponding description will be added as an attribute on the feature, and the attribute will be geodb_subtype_name. When set to YES during the generation of a mapping file/workspace, the schema for a table with subtypes will contain the attribute geodb_subtype_name.
Required/Optional
Optional
Parameter: <resolve_subtype_names>
Values: YES | NO
Workbench Parameter: Resolve Subtypes
Example:
GEODATABASE_SDE_RESOLVE_SUBTYPE_NAMES YES
IGNORE_NETWORK_INFO
This directive determines whether to read the network information belonging to a network feature. When set to YES, junctions will be treated as point features, and edges will be treated as polyline features, with the geodb_type being set to geodb_point and geodb_polyline, respectively.
When set to NO, Geodatabase specific attributes describing network information such as network connectivity will be inserted on the feature. The geometry of the feature remains the same regardless of the value given to this directive. The speed of reading network features is vastly improved if the network info is ignored.
Required/Optional
Optional
Parameter: <ignore_network_info>
Values: YES | NO
Default Value: NO
Workbench Parameter: Ignore Network Info
Example:
GEODATABASE_SDE_IGNORE_NETWORK_INFO YES
IGNORE_RELATIONSHIP_INFO
This directive determines whether to read relationship features present in a source dataset. When set to YES, feature types containing simple relationship will be ignored, and feature types containing attributed relationships will be treated as non-spatial tables. When set to NO, relationships will be read normally as either simple or attributed. The speed of reading features is vastly improved if relationships are ignored.
Required/Optional
Optional
Parameter
<ignore_relationship_info>
Values
YES | NO (default)
Workbench Parameter
Ignore Relationship Info
Example
GEODATABASE_SDE_IGNORE_RELATIONSHIP_INFO YES
SPLIT_COMPLEX_EDGES
Parameter: <split_complex_edges>
Values: YES | NO
Default Value: NO
Workbench Parameter: Split Complex Edges
Example:
GEODATABASE_MDB_SPLIT_COMPLEX_EDGES YES
RETRIEVE_ALL_SCHEMAS
This parameter is applicable only when generating a mapping file, generating a workspace, or when retrieving schemas in an FME Objects application.
When set to yes, schemas for all of the tables and feature classes in the database are returned.
When set to no (or missing), and if RETRIEVE_ALL_TABLE_NAMES is similarly set to no (or missing), only schemas requested by the IDs parameter are returned.
Required/Optional
Optional
Values
YES | NO (default)
NO: The reader will return the schemas for the feature types specified in the IDs. If no features are specified in IDs, then FME returns the schema features for all the tables.
If this value is not specified, then it is assumed to be No.
YES: Indicates to the reader to return all the schemas of the tables in the database.
Mapping File Syntax
Not applicable.
FME Objects applications would include RETRIEVE_ALL_SCHEMAS followed by “YES” in the parameters array passed to IFMEUniversalReader::open().
Workbench Parameter
Not applicable
RETRIEVE_ALL_TABLE_NAMES
This parameter is only applicable when generating a mapping file, generating a workspace or when retrieving schemas in an FME Objects application.
When set to yes, and if RETRIEVE_ALL_SCHEMAS is set to no (or missing), names for all of the tables and feature classes in the database are returned. When set to no (or missing), and if RETRIEVE_ALL_SCHEMAS is similarly set to no (or missing), the schemas requested by the IDs directive are returned.
Note: If RETRIEVE_ALL_SCHEMAS is also set to Yes, then RETRIEVE_ALL_SCHEMAS takes precedence.
Required/Optional
Optional
Values
YES | NO (default)
Mapping File Syntax
Not applicable.
FME Objects applications would include RETRIEVE_ALL_TABLE_NAMES followed by “YES” in the parameters array passed to IFMEUniversalReader::open().
Workbench Parameter
Not applicable (used when you browse a Table List)
CHECK_SIMPLE_GEOM
This directive specifies whether a check should be performed on features read from geodatabase to determine whether they are simple. This is an expensive check and impacts reader performance.
If this directive is set, the format attribute geodb_feature_is_simple is set to Yes if the geometry is simple, and No if it is not.
Required/Optional
Required
Parameter
<check_simple_geom>
Range:
YES | NO (default)
Workbench Parameter
Check for Simple Geometry
Example
GEODATABASE_MDB_CHECK_SIMPLE_GEOM YES
READ_FEAT_LINKED_ANNOS
This directive specifies whether feature-linked annotations should have their text, angle and position properties merged as attributes onto the main feature that they are linked to, when reading. If set to yes, this will produce a list attribute as detailed in the section on Annotations with all annotation attributes set and the annotation table(s) need not be read explicitly. If set to no, feature-linked annotations will be read normally as annotations when encountered.
Required/Optional
Required
Parameter
<read_feat_linked_annos>
Range
YES | NO (default)
Workbench Parameter
Merge Feature Linked Annotations
Example:
GEODATABASE_MDB_READ_FEAT_LINKED_ANNOS YES
SPLIT_MULTI_PART_ANNOS
This directive specifies whether or not to split multi-part annotations into separate features for each ‘element’ when reading. If set to yes, a single feature for each element (usually a word) in a multi-part annotation will be produced on reading, resulting in feature-specific attributes such as angle and text position being stored according to the location of each element. If set to no, multi-part annotations will be read normally, as a single feature storing a single set of attributes describing the positioning of the text.
Required/Optional
Optional
Parameter
<split_multi_part_annos>
Values
YES | NO (default)
Workbench Parameter
Split Multi-Part Annotations
Example:
GEODATABASE_SDE_SPLIT_MULTI_PART_ANNOS YES
BEGIN_SQL{n}
Sometimes, you must execute some SQL statements prior to opening a table. For example, it may be necessary to ensure that a view exists before attempting to read from it.
Upon opening a connection to read from a database, the reader looks for the directive <ReaderKeyword>_BEGIN_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL block into SQL statements, which will then be sent to the database for execution. Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors ; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader or writer (depending on where the SQL statement is executed) with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.
Required/Optional
Optional
Workbench Parameter
Begin SQL
END_SQL{n}
Sometimes you must execute some SQL statements after a set of tables has been read. For example, it may be necessary to clean up a temporary view after creating it in BEGIN_SQL.
Just before closing a connection on a database, the reader looks for the directive <ReaderKeyword>_END_SQL{n} (for n=0,1,2,...), and executes each such directive’s value as an SQL statement on the database connection.
Multiple SQL commands can be delimited by a character specified using the FME_SQL_DELIMITER directive, embedded at the beginning of the SQL block. The single character following this directive will be used to split the SQL block into SQL statements, which will then be sent to the database for execution. Note: Include a space before the character.
For example:
FME_SQL_DELIMITER ; DELETE FROM instructors ; DELETE FROM people WHERE LastName='Doe' AND FirstName='John'
Multiple delimiters are not allowed and the delimiter character will be stripped before being sent to the database.
Any errors occurring during the execution of these SQL statements will normally terminate the reader or writer (depending on where the SQL statement is executed) with an error. If the specified statement is preceded by a hyphen (“-”), such errors are ignored.
Required/Optional
Optional
Workbench Parameter
End SQL
SPLIT_COMPLEX_ANNOS
Geodatabase annotations offer a rich set of options to place text which are often not supported or do not directly translate to other formats. By enabling this option richer text representations are broken into simpler representations that preserve text style and placement.
To maintain accurate placement, text elements are split into separate features on line breaks, format changes, irregular character spacing, and on any curves. This option also implies that Multi-part annotations will be split (see SPLIT_MULTIPART_ANNOS).
Each resulting feature will have a rotation angle and a point representing the bottom left corner of the text. All the text will be bottom, left justified without an X or Y offset.
Each feature will contain all the attributes of the original text element including all the geodatabase format attributes. The annotation related format attributes represent the current part and not the original text element. An additional geodb_text_part_count format attribute is added to indicate the part index of the original text element.
Required/Optional
Optional
Parameter: <split_complex_annotations>
Values
YES | NO (default)
Workbench Parameter
Split Complex Annotations
CACHE_MULTIPATCH_TEXTURES
This directive allows the user to specify what kind of memory optimizations are used when reading multipatches with textures. If set to YES, then textures will be stored in local texture caches and no effort will be made to clean them, resulting in better performance but higher memory usage over time. If set to NO, then extra effort will be made to clear texture caches which may result in slower performance.
The default behavior to cache texture should be used in most scenarios as it will result in better performance. If, however, memory is an issue and there are many multipatch features with associated texture materials, like the buildings of a city, then consider disabling caching to improve memory usage.
Note: This directive is provided as an option to work around an existing implementation limitation. It may be deprecated in time.
Required/Optional
Optional
Parameter: <cache_multipatch_textures>
Values
YES | NO (default)
Workbench Parameter
Cache Multipatch Textures
ALIAS_MODE
This directive allows the user to specify what kind of alias handling should be performed. See the Workbench Reader Parameters for more details.
Required/Optional
Optional
Parameter
<alias_mode>
Values
NONE (default) | SCHEMA | ON_DATA_FEATURES
Workbench Parameter
Alias Mode