SchemaMapper: Conditional Feature Type Mapping

Liz Sanderson
Liz Sanderson
  • Updated

FME Version

  • FME 2017.x

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 or feature type mappings based on specific conditions. In short, conditional feature type mapping is when the connection between what we have and what we want depends on the value of an attribute.

In the previous Conditional Attribute Mapping article, a single layer containing water main data for the city of Vancouver was divided into Abandoned and Active Feature Types using an AttributeFilter to split the incoming data (we also did some attribute renaming in the SchemaMapper, but our focus here is on the fme_feature_type!)

Using Conditional Feature Type mapping, these two datasets can be divided further based on their pipe material.

Using the SchemaMapper’s “Feature Type Map” action in tandem with a Filter action, we can construct an “IF” statement that will decide how to route our feature types. Here’s an example of the kind of logic we’re looking at:

Basic Feature Type map without conditional logic:

IF [existing] fme_feature_type = xxxx 
THEN SET [new] fme_feature_type to zzzz

By adding the Filter action an “AND” is added to this existing condition.

Conditional Feature Type map:

IF [existing] fme_feature_type = xxxx AND attribute = yyyy 
THEN SET [new] fme_feature_type to zzzz

 

Step-by-step Instructions

Feature Type Mapping Lookup Table

Step 1 - In a text editor create a lookup table to use within the SchemaMapper (or optionally jump to the completed workspace template and skip the step-by-step process). The SchemaMapper lookup table has to define both a clause for the Feature Type and a clause for the attribute values. The table should look something like this:

1 SourceFeatureType,SourceAttribute,SourceAttributeValue,DestinationFeatureType
2 Active,Material,Steel,Steel 
3 Active,Material,Copper,Copper 
4 Active,Material,Cast Iron,CastIron 
5 Active,Material,Ductile Iron,DuctileIron 

Line 1 contains the field names for the lookup table. Other lines contain the information by which to restructure the data. For example, line 2 sets up the conditional execution as follows:

IF Source Feature Type = “Active” AND “Material” = “Steel” 
THEN Destination Feature Type = “Steel” 

Note: To fully map this source data, each different source feature type and attribute value must be added to the lookup table, otherwise they will be excluded from the mapping action.

 

Feature Type Mapping: SchemaMapper Definition

Step 2 - Open the SchemaMapper parameters dialog and set up the transformer to read in the CSV lookup table. Add a Filter action to define a clause where Material Attribute = Material Value.

 

r-M-gU9UtFL1ykYfo8-Vrzy0bSYxKbxaMDs85RC_RvwoogNNmF79DuMi1iLtSciC7SwIy9i-SdlvpeKCTYnOs0IPbzmXxDywYxV9gvFiORuAZ-FCDLqKR2uEAtXSN9vSpFdGH6s

 

Step 3 - Next, define the feature type mapping to be carried out (wherever the above conditions are true). In the SchemaMapper use the Add ? Feature Type Map action and set the Source and Destination Feature Type Fields:

 

ZL8k3Xqpw7p-zck7Cvdg1OmI-lT0XLwxSHpExlymMqrNPl3tq0e5bNcoiOx49HDZAfEj_c8Ke9hdRh8ANqP6AYl4avoHmcUJCyFE2M4YJ5G2unuJQns4DcHiWCtl76DtXSPlqpQ

To reiterate, the logic here is:

IF SourceAttribute = SourceAttributeValue 
THEN MAP SourceFeatureType to DestinationFeatureType

When completed, the SchemaMapper parameters will show our two actions - one for filtering features based on our attribute values, and one for remapping the Feature Types accordingly:

Rl2d2OdM-RrPakW-KNGxOpnTd-Q8G_bhTzrR1qepvE1LV10g4j6WLgSdk70AfPUbELju6S8Gw7EYW0VSLHD00myV-nJbBTJqrFbkG6Dd6MeQWOUcoawFbiw98oasjlVtK_fTGys

The source data has only been mapped to the destination Feature Type. For the destination Feature Types to be created and connected, an AttributeFilter transformer is needed to sort through the remapped Feature Types and route them appropriately to our writer feature types.

 

TFlxuZSeXV2RV0976vUwb-fKnHzblTL7eNUEKHb2hSe6iBgBstsEQ29bbcNKPU3C1XW9POtA5JqW2vPKmyytkeqt369jowgd70aUSCVmvja_bMxhLnh2gYKgz1o_jh0MFXOrmes

 

Updating Data

The SchemaMapper is extendable as it enables the user to edit the lookup table outside of FME in order to handle schema transformation within the workspace. In the following example, a new feature type with additional attribute values is added to the workflow.

Workspace Changes

The workspace ACAD reader is currently set up with two feature types: Active and Abandoned.

O-1PaTm8zpat2WiBjdHN-Alv6x_ehB3BR1mMIR9J7w2xPs7VSn0yLo3kiz-Ea_hkvDwbILHJMnQ7SqlX4u2HoNiN53JWfpp5EKdBORXYMRuRQ9DVA7QthJERJn0_jEbmTejvRaM

The schemas, feature types, and attribute values of these objects are handled perfectly by our current SchemaMapper setup. But suppose we introduce some new and strange data? How would our workflow handle the transformation?

Let’s enable our Additional Feature Type (“Update”) and see if we can integrate it into our current workspace.

cNDHKKtJjqsAjNKzb9729smtDS3AyV0CDMPAabh5a7jdfhxVF1WftsFMvAnWPvpvRVb8-krKss8-90BRlqXjnQQ3C-nptdhGU9Zbb3nphh58fb2MqugSpyzLEBMKZjj0fi_jzzE

 

Lookup Table Changes

The “Update” dataset contains two new Material attribute values: “Earthenware” and “Polybutylene”. In this case the lookup table needs to accommodate both the new feature type and the new attribute values. To accommodate these new values, the updated schema information can be added directly to the lookup table.

 

Add the following lines for the new feature type at the foot of the existing lookup table:

1 Update,Material,Earthenware,Earthenware 
2 Update,Material,Polybutylene,Polybutylene 

Save the lookup table and return to the workspace. After adding the two new feature types to the AttributeFilter transformer and adding “Earthenware” and “Polybutylene” writer feature types, the workspace should now handle the new data defined in the lookup table.

u8NQ2xrHZzDTZvq3XrshiTxSKrwdiPmrGnH3JNEYySdRuDy_GusgmuW5kxP5XSJO2wJu9yXzNp1-Q2LbIIBHZnjzz39j06tSDh9Ihk8q50GPyg5o0_lIycdAX7YaQGaICMJJdjI

 

The next step in this process would be to make the workflow completely dynamic in order to read and write data without the workspace author having to define the feature types beforehand. This topic is covered in detail in the Dynamic Workspaces article referenced by the Additional Resources section below.

 

Additional Resources

 

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.

 

 

Was this article helpful?

Comments

0 comments

Please sign in to leave a comment.