Geodatabase User Attributes

Represents Boolean values. The possible values are true and false.

Stores and retrieves 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.

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.

Example 1:

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

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.

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>)

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.

Represents 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.

Represents 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.

Stores and retrieves 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.

Represents 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.

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. FME 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.