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.
When reading a Geodatabase, FME has an option to resolve domains.
When this option is checked an additional attribute will be added called _<attribute>_resolved_ which contains the textual description of the coded attribute value.
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 three scenarios:
- 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) as a template on a Geodatabase writer, is an efficient and highly recommended means of writing Geodatabase domains. For more information on importing an XML document 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.
Scenario 3: Writing to a new table and creating a new domain
It should be noted that we generally recommended that you use ArcGIS to create and define domains, using FME to associate attributes or validate data when inserting new features. However, creating domains is possible with FME. The process is identical as for using an existing domain, up until the point where one opens the edit dialog. At that point you check the “Create Domain” parameter, enter a new domain name, and define the values for that domain.
Note that, provided the “Validate Features to Write” parameter is set to Yes, incoming features will be automatically validated against any newly defined domain.
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 3: Writing to a new table and creating a new domain.
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.
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. However, this process will work when creating a domain as well.
3. Write Features and Create Domain
Add the ESRI Geodatabase (File Geodb ArcObject) 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 coded_domain.
Click on the Edit button and the Coded Domain dialog window will open. Enter a name for the domain (i.e. StreetType), check the box next to create domain, and enter the data type for your domain definition. Finally, enter the codes and resolved values for the domain definition.
Finally, ensure From_HBlock is set to Type char.
Save and run the workspace.
Workspace Utilizing Domain Codes
Workspace Utilizing Resolved Domain Values
* The ESRI Geodatabase (File Geodb ArcObject) reader/writer used in the above example requires that a licensed version of ArcGIS be available to the user. For more information on required ArcGIS license levels, please see Required ArcGIS License Types for FME Geodatabase Formats.
2 People are following this .