| Exercise | Coded Domains |
| Overall Goal | To show how Coded Domains can be used |
| Demonstrates | Using Coded Domains within a GeoDatabase |
Working with Geodatabase Domains: Writing A Coded Domain
1) Download the Required Data and Workspace Templates
Download the resources from here: Download Resources Here
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.
There are two types of Geodatabase domains (coded domains and range domains) and both are supported by FME. A coded domain is essentially 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 will be added called _
Domain Writing
Note: If you can, we would recommend using a Geodatabase Template. This is generally easier and more flexible than defining domains within FME feature types.
FME has the capability to 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 would pass into the Geodatabase without error, despite the fact that 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 is to use an existing domain, the attribute that needs to be 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 of limitations in regards to domain writing.
Firstly, it is not possible to write to an existing table and to either create an association with an existing domain or create an entirely new domain. That is because this association is wrapped up in the table definition, and an existing table definition cannot be changed by FME. You would need to drop the existing table and re-create it entirely in order 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 loads of the data should be done with the data type changed back the actual type of data (char, integer, etc.)
Finally, it is not possible to create a domain dynamically (i.e. the domain definition should be manually defined prior to 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 the use of a template.
Source Data
Roads (Autodesk AutoCAD DWG/DXF)
In the above image, we see a visualization of the source Roads AutoCAD DWG. The values that will be subject to the destination Geodatabase domain definition can be seen in the autocad_layer format attribute.
Workspace Description
1) Read Source Data
Road feature geometry is read from the source AutoCAD DWG file using the Autodesk AutoCAD DWG/DXF reader while values that will be subject to the Geodatabase domain will be read from the format attribute autocad_layer. When adding the Autodesk AutoCAD DWG/DXF reader, be sure to set Workflow Options to Single Merged Feature Type. This means that we’ll only get a single reader feature type to read all the source data.
In addition, click on the parameters button, and, in the Group Entities By section, select Attribute Schema.
Once the reader has been added to the workspace canvas, double-click on the reader and select the Format Attributes tab. Scroll down and check the box next to autocad_layer. Click OK.
2) Map Attributes to Domain Codes
The AttributeValueMapper is used map the values coming from the source DWG to the domain codes we will apply to the domain definition. Add the AttributeValueMapper to the canvas and open the parameters dialog. Select autocad_layer as the Source Attribute 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 screenshot below:
2) (Alternate) Map Attributes to Resolved Domain Values
As an alternative to the step described above, one could instead use an AttributeManager, to take the value from the source DWG file and map it to the domain definition based on the domain definitions 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 (you will need to type in StreetCategory_resolved).
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 know the resolved value.
3) Write Features and Create Domain
Add the ESRI Geodatabase (File Geodb) writer to the workspace, copying the schema from the reader and specifying the output Geodatabase to which the data will be written (i.e.Domains). Click on the parameters tab and expand the Advanced section. Set Validate Features to Write to Yes. This setting will ensure that the incoming source data adheres to our domain definition. Once added, connect the output of the AttributeValueMapper (or, depending on what workflow your workspace followed, AttributeManager) to the Geodatabase writer.
Double click on the writer and, under the General tab, enter a more meaningful name for the output feature class/table (i.e. Streets). Next, click on the User Attributes tab and, under Name, change the autocad_layer attribute to StreetCategory and set the Type to char.
Finally, ensure From_HBlock is set to Type char.
Save and run the workspace.
Completed Workspace(s)
Workspace Utilizing Domain Codes
Workspace Utilising Resolved Domain Values
Results in ArcMap
| CONGRATULATIONS |
|
The tasks above demonstrates using coded domains with a Geodatabase |