Feature Representation

geodb_type: geodb_table

Features with this value consist of no coordinates. This value is used by both the reader and the writer.

geodb_type: geodb_point

Features with this value are point features. This value is used by both the reader and the writer.

geodb_type: geodb_polyline

Features with this value are features or multi-part features consisting of one or more linear features (that are linked together). This type of linear feature is allowed to touch or cross over itself. This value is used by both the reader and the writer.

geodb_type: geodb_multipoint

Features with this value are multi-part features consisting of points. This value is used by both the reader and the writer.

Note: If a multipoint feature is written to an existing point feature class, then the feature will be split up and each point written out as a separate feature. Each new feature will have the same attribution as the original feature; the only difference will be the geometry. If a multipoint feature is written to a point feature class that has not yet been created, then a multipoint feature class will be created instead of a point feature class.

geodb_type: geodb_arc

Features with this value contain either a circular arc or an elliptical arc. Arc features are like ellipse features, except two additional angles control the portion of the ellipse boundary which is drawn.

geodb_type: geodb_ellipse

Ellipse features are point features used to represent both circles and ellipses. The point serves as the centre of the ellipse.

geodb_type: geodb_polygon

Features with this value are features or multi-part features consisting of polygons and/or donut polygons.

geodb_type: geodb_multipatch

Features with this value consist of a 3D geometry, used to represent the outer surface of features which occupy a discrete area or volume in three-dimensional space. Geodatabases directly support 3D polygonal faces, triangle fans, triangle patches and triangle strips. By definition, the surfaces which compose a multipatch do not need to be connected. This value is used by both the reader and the writer.

Multipatches support appearances, but only one appearance per surface is supported. For two-sided surfaces, the writer will favor non-default appearances with textures, with the front side taking precedence over the back side. If this behavior is not desired, the writer can be forced to choose the front side by using the AppearanceRemover transformer in FME Workbench to remove all back appearances.

For writing, all 3D geometry types are supported. Any types of 3D geometry which are not directly supported in a geodatabase (e.g., solids) are decomposed into a set of 3D polygonal faces prior to writing.

geodb_type: geodb_annotation

Feature-linked Annotation

Annotations are separate features but can be linked to other features through feature-linked annotations. Feature-linking occurs when there is a relationship between an annotation feature class and some other feature class. The attribute geodb_linked_feature_id controls which annotations are linked to which features.

If the feature to be linked to by the annotation has not yet been written, then it is possible for the Geodatabase writer to write the feature, retrieve the object ID of the new feature, and then write the annotation feature linking to it, supplying the correct value for geodb_linked_feature_id. This is accomplished by supplying attributes (Geodatabase-specific annotation attributes and user-defined attributes) from the annotation feature on the non-annotation feature; of the annotation feature attributes, only geodb_text_string must be specified. In addition, the following attributes must also be specified:

1. geodb_text_feat_class_name – specifies the annotation feature class to which the annotation will be written
2. geodb_text_x_coord & geodb_text_y_coord – specifies the location of the annotation

The result is that the one FME feature contains enough information to write two features: one annotation feature and one non-annotation feature.

To specify multiple feature-linked annotations, the list attribute geodb_text{i} must be used to group together each annotation's attributes. There are 4 mandatory annotation attributes that must be present for each annotation in the list:

1. geodb_text{i}.geodb_text_string - the text string to write
2. geodb_text{i}.geodb_text_feat_class_name - the name of the destination annotation feature class
3. geodb_text{i}.geodb_text_x_coord - the x coordinate of the annotation's location
4. geodb_text{i}.geodb_text_y_coord - the y coordinate of the annotation's location

Other than these 4 attributes, as many or as few annotation attributes can be used. Keep in mind that default values will be used for attributes that are not specified. A list of all available annotation attributes is given at the end of this section on annotations.

For example, to insert 3 annotation features, each belonging to a different anno feature class, for the one 'streets' feature written, a feature like this would be needed.

feature type: streets
fme_geometry = fme_line
fme_type = fme_line
geodb_type = geodb_polyline
user_defined_field_1 = value
user_defined_field_2 = value
user_defined_field_3 = value
...
geodb_text{0}.geodb_text_feat_class_name = street_names
geodb_text{0}.geodb_text_x_coord = 7504799.45082186
geodb_text{0}.geodb_text_y_coord = 731099.587626632
geodb_text{0}.geodb_text_angle = 10
geodb_text{0}.geodb_text_line_spacing = 0
geodb_text{0}.geodb_text_ref_scale = 100
geodb_text{0}.geodb_text_scale = true
geodb_text{0}.geodb_text_size = 8.2
geodb_text{0}.geodb_text_string = "displayed street name"
geodb_text{0}.user_field_1_for_street_names = value
geodb_text{0}.user_field_2_for_street_names = value
...
geodb_text{1}.geodb_font_bold = false
geodb_text{1}.geodb_font_charset = 0
geodb_text{1}.geodb_font_italic = false
geodb_text{1}.geodb_font_name = Arial
geodb_text{1}.geodb_font_size = 20(
geodb_text{1}.geodb_font_strikethrough = false
geodb_text{1}.geodb_font_underline = false
geodb_text{1}.geodb_font_weight = 400
geodb_text{1}.geodb_text_feat_class_name = alternate_street_names
geodb_text{1}.geodb_text_x_coord = 7504783.11300916
geodb_text{1}.geodb_text_y_coord = 731109.158628889
geodb_text{1}.geodb_text_angle = 56.8
geodb_text{1}.geodb_text_size = 4.3
geodb_text{1}.geodb_text_string = "alternate street name"
geodb_text{1}.user_field_1_for_alternate_street_names = value
...
geodb_text{2}.geodb_text_feat_class_name = old_street_names
geodb_text{2}.geodb_text_string = "old street name"
geodb_text{2}.geodb_text_x_coord = 7504788.43294883
geodb_text{2}.geodb_text_y_coord = 731105.044247817
geodb_text{2}.user_field_1_for_old_street_names = value
...
Geometry Type: Line (2)

Number of Coordinates: 4 -- Coordinate Dimension: 2 -- Coordinate System: _FME_0'

(7504779.48166667,731111.522380952)
(7504797.35380952,731098.524285714)
(7504813.13690476,731104.327142857)
(7504805.59357143,731109.201190476)

Lastly, the TRANSACTION_TYPE directive must be set to EDIT_SESSION or VERSIONING whenever writing feature-linked annotations.

Note: geodb_text_line_spacing is equivalent to Font Leading in Geodatabase.

Note: For accurate placement of multiline text, ensure that the line endings are Windows-style line endings (“\r\n”).

In addition to text geometries, annotation feature classes can also contain non-text graphical elements known as graphic shapes. These shapes may be composed of polygon or line geometries or hierarchies containing them. Currently, graphic shapes are only supported on writing.

When writing line or polygon geometries or aggregates of them to an annotation feature class, they will be written out as graphic shapes. Basic symbology may be associated with the graphic by supplying the fme_color and fme_fill_color attributes. Graphic shapes are not text elements and therefore the format attributes associated with text annotation will not be written.

The following attributes are used to store the annotation information within an FME annotation feature.

In ArcGIS 9.1, the schema of annotation feature classes changed and a considerable number of additional fields were added. These new fields contain information about the annotation such as its font, size, angle, offset, leading, etc. When writing, these fields should never be set directly; instead the attributes in the table below must be used to control the properties of the annotation. After the translation, the fields will display the desired values because the attributes below correspond to some of the fields.

FME supports “Simple Line Callout” and “Line Callout” annotation leader lines represented as format attributes. Common between both are tolerance, line width, line color, and the anchor point. Simple Line Callouts can optionally have a geometry associated with them stored in geodb_leader_line. Line Callouts in Geodatabase have no geometry associated with them and are rendered directly in ArcGIS based on their attributes. To assist in emulating the rendering, FME provides a textbox envelope that can be used along with the style, gap, margin and anchor point attributes to determine where to place the leader line and accent bar.

Leader lines attributes will only be on annotations with an actual leader line. If the annotation is split, then the leader line attributes are only placed on the first part with the textbox being the envelope of the whole annotation.

Leader line attributes will override leader line symbols if a symbol id or annotation class id is provided. If just providing an anchor point, only the anchor point will be overridden; otherwise, the whole leader line symbol will be overridden.

geodb_type: geodb_dimension

Dimension features are defined by the following attributes:

geodb_type: geodb_simple_junction

This type is supported by both the reader and the writer. However, simple junction feature classes must be created in ArcCatalog prior to running the translation. Simple junction features are defined by the following attributes:

geodb_type: geodb_simple_edge

This type is supported by both the reader and the writer. However, simple edge feature classes must be created in ArcCatalog prior to running the translation. Simple edge features are defined by the following attributes:

geodb_type: geodb_complex_junction

This type is deprecated, and only supported by the Reader. Complex junction features are defined by the following attributes:

geodb_type: geodb_complex_edge

This type is supported by both the reader and the writer. However, complex edge feature classes must be created in ArcCatalog prior to running the translation. The attributes present on an FME feature depend on the value for the reader directive SPLIT_COMPLEX_EDGES. If the value is NO, the following attributes will be present:

If the value is YES, these attributes will be present:

geodb_type: geodb_relationship and geodb_attributed_relationship

Relationship features contain information about a single relationship between an origin and destination feature. They can be both read and written using FME: attributed relationships can be inserted, updated and deleted, while non-attributed relationships can only be inserted and deleted. Relationships are not rows in a table or feature class like other features, but rather implied through the primary and foreign key values of an origin and destination feature. Attributed relationships have intermediate tables associated with them, which can be updated by providing an RID (relationship id) as a key field, much as an OBJECTID must be provided when updating a table or feature class.

Relationship classes cannot be created through FME, and must be set up through ArcCatalog prior to running the translation.

When reading, the following attributes are stored on the feature, and are required for writing relationships; they must be supplied, if the feature was not read from Geodatabase:

The following attributes are stored on all related origin or destination features, and are required for writing relationships; they must be supplied if a feature was not read from Geodatabase:

In particular, it's possible to write to origin and destination feature classes, as well as associated relationship classes, all in one pass. This is automatic when reading from one Geodatabase and writing to another, but can be achieved in other cases with additional care. This applies to attributed and non-attributed relationships. It applies to relationships that reference the OBJECTID field in the origin and destination tables, as well as relationships that reference other fields in the origin and destination tables.

When writing origin or destination features that will be referenced by relationship features written during the same pass, they must have:

geodb_oid = <temporary local object id>

geodb_feature_has_relationships = "yes"

The <temporary local object id> does not become the ultimate OBJECTID in ArcGIS. However, it can be used to reference origin and destination features when writing relationship features in a single pass.

When writing relationship features, they must have:

geodb_rel_origin_oid = <temporary local object id> OR <true object id>

geodb_rel_destination_oid = <temporary local object id> OR <true object id>

geodb_type = "geodb_relationship" (for non-attributed relationships), or

"geodb_attributed_relationship" (for attributed relationships)

If there is an overlap between true object IDs and temporary local object IDs, FME preferentially assumes the ID is a temporary local one. This allows the user to ignore the true object IDs if desired.

The writer feature type parameters for relationship classes should have

"Allowed Geometries" = "geodb_relationship" or "geodb_attributed_relationship"

as appropriate. (This explanation is for Workbench; mapping file authors should set geodb_type to one of the above on the DEF line. See Geodatabase Table Representation for more details.)

Note: When writing relationship features with FME, you must always provide object IDs, *not* the values of the actual origin and destination key fields if they are different than OBJECTID.

geodb_type: geodb_metadata

Metadata features contain metadata about the feature type. Metadata can be read and written. The metadata used is of the same form as when using Esri’s ArcCatalog to export table metadata to (plain) XML.

When reading, the following attributes are supplied on the feature, where applicable:

If the feature type represents a feature class, the geometry of the metadata feature returned is a polygon, representing the extents of the feature class and the coordinate system of the feature class also gets set on the feature.

When writing, the geodb_type of the feature must be geodb_metadata; however, the geodb_type of the destination feature type must not be geodb_metadata, but rather the type of the table itself.

The metadata within geodb_metadata_string will overwrite any previous metadata that exists in the table. If multiple metadata features are written to a single table, then the last metadata feature will be used. Viewing the metadata within ArcCatalog after the translation will automatically update certain fields, such as table name & record count, if they were set incorrectly in geodb_metadata_string. However, if you use FME to read back the metadata before viewing the results in ArcCatalog then the incorrect fields will not have been corrected. None of the other attributes supplied on an FME feature when reading metadata will get used when writing metadata.

Writing metadata features does not increase the number of features in a table.

Difference features are produced when reading version differences. The features record the changes made to a table or feature class between the connection version and a baseline version.

Three types of differences are considered: inserts, updates, and deletes. Each difference feature always contain an fme_db_operation attribute that contains the type of difference and the geodb_oid that identifies the record that has changed.

Features additionally represent the current state of the row, so INSERT and UPDATE features contain the complete feature representation including geometry and attributes, whereas DELETE features only contain the fme_db_operation and geodb_oid of the deleted row.

Features with this value consist of a raster geometry, and are used to represent a two-dimensional grid of values. FME supports the writing and reading of both single- and multi-banded numeric rasters, and three-banded color rasters.

Additionally, the writer supports a single alpha band that is treated as a nodata mask for all bands, where an alpha value of 0 at a given cell represents nodata.

Nodata within rasters are represented as nodata values per band for unmanaged rasters and as a single alpha band for managed rasters. The single alpha band is a combination of the nodata bitmasks of the other bands, where a value of zero at a given cell represents nodata and only occurs when all the bands have nodata at the given cell. On write, nodata per band is fully supported as nodata values per band. If nodata values and an alpha mask are both present on write, then only the nodata values will be used and the alpha band is ignored.