Creating and Associating Geodatabase Domains Dynamically Using A Feature Class and GDB Table

Downloads

Introduction

A domain
is a set of rules that define permitted values for an attribute. They
are used
to constrain data values in order to ensure data integrity. A domain
is defined in a Geodatabase as a unique entity and can be applied to any
attribute in any feature class within the Geodatabase that contains the
domain definition.

Given the complexity of domain definitions, it is highly recommended that one use ArcGIS to define their Geodatabase domains. However, what happens if you are provided with data where the domain definitions have not been applied to the Geodatabase and instead exist in a lookup table? The following exercise will demonstrate how to use a Geodatabase table containing domain codes and values to create a coded domain definition using FME.

Source Data

Streets Feature Class (ESRI Geodatabase - File Geodb)

In the above image, we see a visualization of the source Streets feature class. The values that will be subject to the destination Geodatabase
domain definition can be seen in the StreetCategory attribute.

StreetCategory Geodatabase Table(ESRI Geodatabase - File Geodb)

In the above image, we see a visualization of the source StreetCategory Geodatabase Table. The values in this table will provide the values for the Geodatabase
domain definition. It is important to note that the name of the Geodatabase table corresponds to the attribute that will be subject to the coded domain definition.

Workspace Description

1. Read Source Data

Information that will comprise our coded domain definition will be read from an independent Geodatabase table using the Esri Geodatabase (File Geodb) reader while Street feature geometry and the underlying schema of the data will be read from the Streets feature class using a FeatureReader transformer. This will allow us to do the underlying schema manipulation needed to create the domain definition from the information contained in the Geodatabase table. When adding the FeatureReader transformer, open the parameters dialogue and ensure that the settings resemble the following screen shot:

In addition, once the FeatureReader has been added to the canvas, add a Creator transformer and connect the Creator to the Initiator input port on the FeatureReader. The Creator ensures that the FeatureReader will trigger when the workspace is run.

2. Build String for Coded Domain Definition from Table

FME writes coded domains using a specific syntax which is then applied to the underlying schema of a Geodatabase - coded_domain(<DomainName>:<DataType>:code:value:code:value:.....). The domain for Street categories that we will create from our Geodatabase table will appear as follows once our workspace is complete:

To get the data contained in the Geodatabase table into the format noted above, we will need to do some string manipulation. The StringConcatenator is used to create and save individual code:value pairs (i.e. 1:Arterial) into an attribute called StreetCategoryKeys.

The ListBuilder creates a list from those incoming code:value pairs, while the ListConcatenator merges those code:value pairs into a single string attribute (StreetCategoryConcate) wherein the code:value pairs are separated by a colon (i.e. 1:Arterial:2:Secondary).

An AttributeCreator is used to create an attribute that will hold the value of the fme_feature_type of the Geodatabase table (in this case, the name of the table - StreetCategory). The value of this created attribute will allow us to search and alter the data type of the feature schema later in the workflow.

3. Merge Lookup Table to Feature Schema

The FeatureMerger transformer is used to merge the newly created domain definition code:value list onto the schema of the source Street feature class. The coded domain definition will act as the Supplier data in the FeatureMerger while the Schema port from the FeatureReader will provide the Requestor input source. Once the FeatureMerger has been added to the canvas and the inputs connected, open the transformer's parameter dialogue and ensure the parameters appear as follows:

4. Search Schema

Now that the code:value list has been applied to the feature schema, we need to now tell the schema that it will be a coded domain data type. First, we'll search through the schema list using a ListSearcher in order to return the index number of the feature attribute that will be subject to our coded domain. Once we have the index number, we will be able to alter the underlying native data type of that attribute from String to that of a coded domain (see step 5).

5. Create Coded Domain & Handle Attributes

An AttributeCreator is used to alter the data type of the feature attribute that will be subject to the coded domain definition. To do so, we take the index value from the step above and apply it to the underlying native data type property (attribute{}.native.data.type) for the coded domain feature attribute. This data type attribute will be assigned the full completed syntax that comprises the coded domain definition - coded_domain(StreetType:integer:@Value(StreetCategoryConcate)).

At the same time, the AttributeCreator will be used to create a Sort attribute that will be used later in the workflow to control the order in which our features and schema reach the File Geodatabase writer.

Now that we've dealt with our coded domain definition and feature schema manipulation, we can now deal with the features coming from the FeatureReader. An AttibuteManager is used to map the attribute values contained in the StreetCategory attribute of our feature to the newly defined coded domain values. This is done by applying a Conditional Value definition (as seen below) to the StreetCategory attribute.

As you may notice in the screen shot above, at the same time we are mapping the StreetCategory attribute to our coded domain definition, we are also creating a Sort attribute and setting its value to 2.

6. Sort Schema/Feature & Write Domain Dynamically

The Sort attributes that were created in the previous two steps will be used to ensure that our
features will be written to the destination Geodatabase after the
altered schema has been applied. A Sorter transformer is used to control this part of the workflow.

Finally, the Esri Geodatabase (File Geodb) writer set to a dynamic table definition will take the modified schema and apply it to the destination Geodatabase. After the schema has been applied, the features from the source Streets feature class will then be written
with the coded domain definition applied to the StreetCategory attribute.