Working with Geodatabase Domains: Writing A Coded Domain

Introduction

A domain is a set of rules defining an attribute's permitted values. It is used to constrain data values to ensure data integrity. A domain in a geodatabase is a unique entity that can be applied to any attribute in any feature class within the geodatabase that contains the domain definition.

There are two types of geodatabase domains (coded domains and range domains), and FME supports both. A coded domain is a list of multiple valid values, while a range domain is a single permitted range of numeric values.

Domain Reading

When reading a geodatabase, FME has an option to resolve domains.

When this option is checked, an additional attribute called _<attribute>_resolved_ will be added, which contains the textual description of the coded attribute value.

Domain Writing

We recommend using a geodatabase template described in How to Use an Esri Template. This is generally easier and more flexible than defining domains within FME feature types.

FME can write to existing or create new geodatabase tables. As such, when writing geodatabase domains, the workflow requirements will tend to fall under one of two scenarios:

• Write to an existing table using an existing domain.
• Write to a new table using an existing domain.

These scenarios will be controlled primarily by the following writer parameters:

• Data Type: coded_domain / range_domain
• Validate Features to Write parameter value: Yes / No

Despite the scenarios mentioned below, it should be noted that using an XML Workspace Document (containing the required domain definitions) or a file geodatabase as a template on a geodatabase writer is the most efficient and highly recommended means of writing geodatabase domains. For more information on importing an XML document or a geodatabase Template with a schema, please see the Geodatabase Writer documentation.

Scenario 1: Writing to an existing table using an existing domain

Any data written to an existing domain field is, by default, inserted as normal. As the table already exists, its attribute(s) will already be associated with the required domain and there is no need to set any parameter to define this connection.

However, if you wish to validate incoming data – for instance, compare it to a domain definition to ensure it has valid attribute values – then you must set the writer parameter “Validate Features to Write” to Yes. If the validation parameter is set to No, the data will pass into the Geodatabase without error, even though some data values may not meet domain rules.

Scenario 2: Writing to a new table using an existing domain

When creating a new table that uses an existing domain, the attribute associated with a domain should be given the data type coded_domain or range_domain (depending on its type) in the schema definition. One would then click the Edit button in the attribute width field and enter the name of the existing domain in the "Domain Name" section.

Limitations

There are a few limitations regarding domain writing.
Firstly, it is impossible to write to an existing table and either create an association with an existing domain or create an entirely new domain. This association is wrapped up in the table definition, and FME cannot change an existing table definition. You would need to drop the existing table and re-create it entirely to be able to do this.

Secondly, for the same reason stated above, creating a domain is a one-off translation. You would set the data type to coded_domain/range_domain for the initial process, but subsequent data loads should be done with the data type changed back to the actual data type (char, integer, etc.)

Finally, it is not possible to create a domain dynamically (i.e., the domain definition should be manually defined before execution and not defined during the workspace process).

The following example demonstrates Scenario 2: Writing to a new table and using an existing domain through a template.

Requirements

The Esri Geodatabase (File Geodb) reader/writer used in the following example requires a licensed version of ArcGIS to be available to the user. For more information on needed ArcGIS license levels, please see Comparison of Esri-Based Readers and Writers in FME.

Video

Source Data

Roads (Autodesk AutoCAD DWG/DXF)

The above image visualizes the source Roads AutoCAD DWG. The values subject to the destination geodatabase domain definition can be seen in the autocad_layer format attribute.

Step-by-step Instructions

1. Read Source Data
Add an Autodesk AutoCAD DWG/DXF writer to the canvas in a blank workspace. Browse to the Road.zip dataset provided in the Files section of this tutorial. You can leave the file zipped. Change the Workflow Options to Single Merged Feature Type. Then, open the parameters.

In the parameters, set the Group Entities By to Attribute Schema, then click OK twice to add the reader.

Double-click on the reader feature type to open the parameters once the reader has been added to the workspace canvas. Switch to the Format Attributes tab, enable the autocad_layer, and click OK.

2. Map Attributes
There are two ways to map attributes to domains: domain code or resolved domain values. If following along with the demo, select one of the options at a time.

Option 1: Map Attributes to Domain Codes

Next, we will use an AttributeValueMapper to map the incoming values from the source DWG to the domain codes, which we will apply to the domain definition.

Add an AttributeValueMapper to the canvas and connect it to the <ALL> reader feature type. In the parameters, set the Source Attribute to autocad_layer and enter StreetCategory as the Destination Attribute. Enter 99 as the Default Value, as this will be the domain code we will use for Unknown street types.

In the Value Mapping part of the parameters dialog, enter the values as seen in the table.

Option 2: Map Attributes to Resolved Domain Values

As an alternative to the step described above, one could use an AttributeManager to take the value from the source DWG file and map it to the domain definition based on the domain definition's resolved value.

To do so, add an AttributeManager to the workspace and open the parameters dialog. Rename autocad_layer to StreetCategory_resolved—the resolved version of the domain.

The above tends to be most applicable when your workflow falls under Scenario #1 (writing to an existing table using an existing domain definition) or Scenario #2 (writing to a new table in the geodatabase using an existing domain). In both scenarios, it would be assumed that one does not know the actual domain codes contained in the domain definition and instead knows the resolved value.
 
3. Write Features and Create Domain
Add an Esri Geodatabase (File Geodb) writer to the canvas. Browse to a location to save the geodatabase. Leave the Feature Class or Table Definition set to Copy from Reader, then open the parameters. 

In the parameters, enable Overwrite Existing Geodatabase, then browse to the RoadsTemplate.gdb for the Template File Geodatabase. Next, expand the Advanced section and set Validate Features to Write to Yes.

This setting will ensure that the incoming source data adheres to our domain definition. Then click OK twice to add the writer. 

Connect the writer to either the AttributeValueMapper or the AttributeManager, then open the writer feature type parameters.

In the feature type parameters, change the Feature Class or Table Name to something more meaningful, such as Streets.

Next, switch to the Attributes tab, rename autocad_layer to StreetCategory, and click OK.

4. Save and Run the Workspace
Save the workspace and then run it. View your output in ArcGIS Pro. 

Data Attribution

The data used here originates from open data made available by the City of Vancouver, British Columbia. It contains information licensed under the Open Government License - Vancouver.