User Attributes

Readers: For information on the parameters in this dialog that are common to all readers, see:

Writers: For information on the parameters in this dialog that are common to all writers, see:

This section defines the attributes for a table.

  • The <attribute name> specified within the workspace must obey the following rules:
    • Attribute Name case must conform to the conventions and restrictions of the underlying RDBMS database. When writing to a File Geodatabase, the case is preserved, but when writing to an Enterprise Geodatabase whether or not the case is preserved depends on the underlying database (i.e., in Oracle, attribute names are made uppercase, whereas in Microsoft SQL Server at ArcSDE 9.2 or later, case is preserved).

    • Attribute Names must obey all length and character restrictions of the Geodatabase. There is a limit of 30 characters when writing to Geodatabase.

      Note: If a table is being created and one of the attribute names conflicts with a Geodatabase system field (i.e., the object ID or one of the shape fields), then a different name will be selected for the system field and a warning message logged.

  • The <attribute name> definition defines the type and has the form <attribute name> <attribute type>.

The supported attribute types are listed below.

Attribute name restrictions if attributes begin with a number.

This format does not allow attribute names to begin with a number. When automatically generating writer schema, FME will prepend any attribute name that begins with a numeric character with an underscore '_' in order to produce valid output.

For example: If reading a dataset that has attributes named for the years 2010 and 2011, the writer schema will list these attributes as _2010 and _2011.

Using an AttributeRenamer transformer to rename the attribute or add a specific prefix will prevent the underscore from being added, as long as the new name does not also begin with a number.

Attribute Type

Description

boolean

This type is used to represent Boolean values. The possible values are true and false.

char(n)

This type is used to represent character values with a length not exceeding n characters. FME will read from and write to geodatabases using the UTF-16 encoding.

date

This is used to store and retrieve date information within a Geodatabase.

When a date field is read by the Geodatabase reader, it is placed in the FME feature with the form HHMMSS, YYYYMMDD, or YYYYMMDDHHMMSS. The time portion is specified using the 24-hour clock. When writing, the date attribute must also be in one of these three forms. These forms are compatible with all other FME dates.

When the Geodatabase writer creates a new table, all the fields, except for the object ID field, will be defined as allowing null values.

domains

The domains can be specified at the DEF lines using the following syntax:

<attribute name> range_domain(domain_name:field_type:min_val: max_val)
<attribute name> coded_domain(domain_name:field_type:name_1:value_1: …..
						     name_n:value_n)

This syntax is used to create new domains along with the new field. The domains defined as above are added to both the workspace and the field of the table. If the domain name already exists in the workspace, a comparison is made against the existing definition. A warning is issued if they differ, and the existing domain is used.

Note: The argument list (i.e., everything between the parentheses) must be colon-separated and must be encoded using a special XML-like encoding. Workbench automatically encodes the list properly.

Example 1:

To define a domain with the following code and values for a float field type:

Code

Values

1.2

val1

3.6

val2,val3

4.5

test “quotes” here

you would use the following format:

coded_domain(floatCodedDom:float:1.2:val1:3.6:val2<comma>val3:4.5:
<quote>test<space><quote><quote>quotes<quote><quote><space>here<quote>)

To use an existing domain, you can use the following short syntax:

range_domain(domain_name)
coded_domain(domain_name)

An error will be generated if the domain does not exist in the workspace or is not defined elsewhere using the long syntax (i.e., the syntax specified at the beginning of this section) for domains.

Note: If the same new domain is referenced multiple times in the translation, the long syntax form only needs to be specified on one attribute; all other instances can use the short form. It does not matter on which attribute the long form is specified within the workspace.

To specify the length of a text field while specifying an existing domain, you can use the following variant of the short syntax:

coded_domain(domain_name:char<openparen><textsize><closeparen>)

Note: The <openparen> and <closeparen> are the result of applying FME’s XML-like way of escaping certain characters. Contact Safe Software if more information is needed, keeping in mind that Workbench automatically performs this encoding when creating new domains and subtypes.

For example,

coded_domain(textDomain:char<openparen>50<closeparen>)

It is important to note:

  • The variant of this short syntax is allowed for text fields only.
  • Since ArcGIS allows text fields to have only coded value domains, using this field type with range_domain will result in an error.
  • If no text length is specified for a text field, that is, if the syntax used is:

coded_domain(domain_name)

then FME will insert a default length of 254 characters.

double

This type is used to represent 64-bit float values.

double(n,m)

This type is used to represent double values with a precision not exceeding n and a scale not exceeding m.

If an invalid width and/or decimal is specified for this data type then FME will correct the value(s) and output a warning saying that it has done so. A valid value for the width lies between 1 and 38 inclusive. A valid value for the decimal lies between 0 and the value of the width inclusive.

Note: This only applies to Geodatabase SDE. It will behave like a regular float in the other Geodatabases.

float

This type is used to represent 32-bit float values.

float(n,m)

This type is used to represent float values with a precision not exceeding n and a scale not exceeding m.

If an invalid width and/or decimal is specified for this data type then FME will correct the value(s) and output a warning saying that it has done so. A valid value for the width lies between 1 and 6 inclusive. A valid value for the decimal lies between 0 and the value of the width inclusive.

Note: This only applies to Geodatabase SDE. It will behave like a regular float in the other Geodatabases.

globalid

This is used to store and retrieve GlobalIDs within a Geodatabase. When a GlobalID field is read by the Geodatabase reader, it is placed in the FME feature without surrounding braces.

The Geodatabase writer will accept GlobalID values with or without surrounding braces.

A GlobaldID is a field of type UUID (Universal Unique Identifier) in which values are automatically assigned by the geodatabase when a row is created. The GlobalID field is necessary for maintaining object uniqueness across replicas.

guid

This is used to store and retrieve GUIDs within a Geodatabase. When a GUID field is read by the Geodatabase reader, it is placed in the FME feature without surrounding braces.

The Geodatabase writer will accept GUID values with or without surrounding braces.

integer

This type is used to represent 32-bit integer values.

integer(n)

This type is used to represent integer values with less than or equal to n digits.

If an invalid width is specified for this data type then FME will correct the value and output a warning saying that it has done so. A valid value for the width lies between 1 and 10 inclusive.

This only applies to Geodatabase SDE. It will behave like a regular integer in the other Geodatabases.

smallint (n)

This type is used to represent small integer values with less than or equal to n digits.

If an invalid width is specified for this data type then FME will correct the value and output a warning saying that it has done so. A valid value for the width lies between 1 and 5 inclusive.

This only applies to Geodatabase SDE. It will behave like a regular smallint in the other Geodatabases.

subtypes

Subtypes allow you to define a subclassification of a table based on a field. For instance, a table named road may have a field called condition which can have values good, bad, and miserable. In the Geodatabase, the field must be an integer type of some sort in order to be able to create subtypes on it.

For the Geodatabase writer, subtypes can be created when creating a new table using the following syntax on DEF lines

<attribute name> subtype(value1:value2:value3:.....valuen)

or

<attribute name> subtype_codes(code1:val1:code2:val2:....coden:valn)

The argument list (i.e., everything between the parentheses) must be colon-separated and must be encoded using a special XML-like encoding. Workbench automatically encodes the list properly.

In the first case, descriptions can be supplied as strings, in which case codes are generated by the Geodatabase writer starting at zero. In the second case, the input list consists of pairs of codes and corresponding descriptions.

The first code in the list will be used as the default subtype code. In the first case where only descriptions are specified, the code created for value1 will be used as the default subtype code. For instance, if the DEF line is specified as follows

subtype_codes(1:a:3:b:4:c:5:d)

then 1 will be used as the default code (which maps to a).

The following restrictions are applied when subtypes are created:

  • Each table can have only one subtype.
  • All the codes have to be unique and valid integers.
  • All the value,description pairs have to be unique.
  • You cannot add subtypes to an existing table. If you do, the DEF line definition will be ignored and the table will use the existing subtype, if one exists. If a subtype does exist on the table, then a comparison will be made between the DEF line definition and the existing subtype’s definition. A warning message will be logged if they are different.

When writing features, the subtype attribute must contain the code (which is stored as an integer by Geodatabase). To supply the description instead of the code for a feature, use the special attribute geodb_subtype_name. If the subtype attribute is not specified, then the writer will look for the geodb_subtype_name attribute and will convert the description to its corresponding code. See the section Writing Subtypes and Domains for more information.