SchemaMapper: Conditional Attribute Mapping

Introduction

Conditional mapping makes use of the SchemaMapper’s “Filter Features” action. It is a way to define a simple conditional clause to perform attribute mappings based on specific conditions.

In this tutorial we’ll manipulate a single layer that contains water main data for the city of Vancouver. The layer can be divided up into Abandoned and Active pipes based on an attribute, and we’ll make use of this value, along with conditional clauses, to remap the layer’s schema in two ways: 1) using attribute values as a filter and 2) using FME Feature Types as a filter.

Source

Step-by-step Instructions

Step 1 - The water mains schema contains attributes named OBJECTID and LifecycleStatus, both of which will play a part in our conditional filter. Open the dataset in the Data Inspector and take a look at the LifecycleStatus attribute of a few features. You’ll notice that it has either the value Abandoned or the value Active:

For our tutorial, depending on the value of LifecycleStatus, the fme_feature_type attribute will be mapped to either Abandoned or Active and OBJECTID will be renamed to either AbandonedID or ActiveID.

Conditional Attribute Mapping Lookup Table

If our conditional attribute mapping lookup table followed the simple structure used in the Attribute Mapping Article where the left column holds the attributes and values we’re starting with, and the right column dictates what we want as output, the table would look something like this:

1 SourceAttribute,DestinationAttribute
2 OBJECTID,AbandonedID 
3 OBJECTID,ActiveID

The problem with this lookup table is that OBJECTID is defined as a source twice under SourceAttribute (because we want to map it in two different ways). This is clearly problematic; we need to give more explicit instructions. To correct this, a clause is added stating when to use which definition.

1 FilterAttribute,FilterAttributeValue,SourceAttribute,DestinationAttribute
2 LifecycleStatus,Abandoned,OBJECTID,AbandonedID 
3 LifecycleStatus,Active,OBJECTID,ActiveID

The logic working here is as follows:

IF LifecycleStatus = Abandoned THEN OBJECTID ? AbandonedID
IF LifecycleStatus = Active THEN OBJECTID ? ActiveID

Conditional Attribute Mapping in SchemaMapper

Step 2 - In our demo workspace, open the SchemaMapper transformer’s parameters. A lookup table is provided for you - feel free to inspect the lookup table reader parameters Preview panel to get a sense of the table structure.

Step 3 - Click through to the Create Actions parameters window. Notice that we have two Actions - one for filtering features, and one for mapping attributes.

The Filter Features action defines the clause where LifecycleStatus Attribute = LifecycleStatus Value:

The Map Attributes action defines the attribute map where SourceAttribute becomes DestinationAttribute:

Also worth noting is the Source Attribute: Keep / Remove option. Remove is selected with the aim of tidying the data and focusing on the remapped attribute values rather than the originals. Using the Keep option would retain the original OBJECTID field and values along with the new ones.

Step 4 - Accept the parameters and return to the workspace. Our single water mains layer has now been logically split into two based on the LifecycleStatus attribute: we have features marked with an AbandonedID and features marked with an ActiveID. Using an AttributeFilter , we can now map the two groups of features onto two outgoing feature types and write our AutoCAD file.

Since Workbench does not know that the correct mappings exist in the SchemaMapper, the destination attributes are flagged as unconnected (the red triangles that appear in our writer attribute dropdown). However, when the workspace is run, the output will be correct because the attributes exist, they just aren’t exposed.

Alternatively, the AttributeExposer transformer can be used to expose these new attributes and cause the writer attributes to be visibly connected.

Advanced Example

Conditional Attribute Mapping using Feature Type Names

Filtering is not limited to user-defined attributes since it is also possible to filter by Format Attributes. An example of a useful Format Attribute is fme_feature_type, which contains the Feature Type name. The key to performing this task is to provide the FME Format Attribute in the lookup table. In the following example, two features types exist in the workspace: Water_Distribution/wControlValve and Water_Distribution/wMain. We would like to rename attributes in the resulting schema based on which feature type is being read.

To create this workflow we need a lookup table that uses the >fme_feature_type attribute. A lookup table is provided within the workspace template, but you may wish to create your own which looks like the one below:

1 FilterAttribute,FilterAttributeValue,SourceAttribute,DestinationAttribute
2 fme_feature_type,Water_Distribution/wControlValve,OBJECTID,ValveID 
3 fme_feature_type,Water_Distribution/wControlValve,Diameter,ValveDiameter 
4 fme_feature_type,Water_Distribution/wMain,OBJECTID,PipeID 
5 fme_feature_type,Water_Distribution/wMain,Diameter,PipeDiameter 

As with conditional attribute mapping, each line in our lookup table defines a schema mapping rule. The first rule in this lookup table states:

IF Feature Type Name = Water_Distribution/wControlValve 
THEN OBJECTID becomes ValveID

The SchemaMapper transformer Create Actions dialogue mirrors the example table given above. For example, in the preset Filter Features action window, the two columns which dictate the attribute filter portion of our rules are highlighted:

Run the workspace and notice that the AttributeFilter separates our two feature types, and that we have remapped our OBJECTID attribute along the way.

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.