Here’s the promised second post on the SchemaMapper transformer.
In the first post we mapped attributes from one name to another, and now we’ll map some Feature Types.
The SchemaMapper dragon is happy now he’s getting some attention.
Remember that Schema is the FME term for what you might call data model. The source schema is “what we have” and the destination schema is “what we want to get”. The act of connecting the source schema to the destination, to fulfill the “what we want” aspect, is called Schema Mapping.
Usually Schema Mapping is done through connections in a workspace; but can alternatively be carried out by the SchemaMapper transformer.
Feature Type Mapping with the SchemaMapper
Let’s take this case of Feature Type mapping. There are no attributes on the data, just different source Feature Types being mapped to different destination types:
With this example, both Lakes and Rivers get combined into a new type called Hydrology, and the rest of the data is similarly mapped.
Like the previous post on attributes, all I need to map these features with a SchemaMapper is a simple CSV file defining the relationships:
SourceType, DestinationType Lakes, Hydrology Rivers, Hydrology
This time in the SchemaMapper I use the Index Fields dialog:
Note that I’m using the format attribute fme_feature_type to determine what the feature’s original Feature Type was, and a new attribute called NewDestinationType to define what it must become.
The logic is basically:
Where Source Attr = Source Field, then set Destination Attr to Destination Field
or in our case
Where fme_feature_type = Lakes then NewDestinationType = Hydrology
Again I can now enter all my other mappings (eg Roads to Transportation) into the CSV file to complete the mapping of Feature Types from one schema to another, giving me a workspace which looks like this:
The question is now, how do I connect the SchemaMapper to the output? Well, there are two ways. The first is to set a fanout using NewDestinationType as the attribute to fanout on:
This will create all my newly mapped layers in the output dataset. However, there is a limitation: this only works because I don’t have any attributes on the output. We can’t fanout like this if each different type of data had a different set of attribute (of course it would also work where I did have attributes, but they were all exactly the same for each feature type).
So, when there are attributes, and they do differ, then the usual technique is to divide the data up in the workspace using an AttributeFilter transformer. Again NewDestinationType is used to filter the data:
What would be ideal is a destination Feature Type which would write out data regardless of attribute schema. If only such a function existed! Well of course it now does with the Dynamic Schema functionality in FME2010. More on that another time…..
So again, in this static situation, you’re entitled to ask what exactly all of this has bought you. Well remember that, although this is just a really, really simple example:
- It’s still easier for non-FME’ers to edit the mappings in a text file than a workspace.
- If you go dynamic then it can simplify the workspace greatly.
- If you use the Filter Fields dialog in the SchemaMapper then you can set up a where clause (eg if pipelineDiameter > 20 then NewDestinationType = Large)
I think this is a good place to stop again. In the next post I’ll demonstrate how to use the Filter Fields dialog to set up conditional mappings.
Mark IrelandMark, aka iMark, is the FME Evangelist (est. 2004) and has a passion for FME Training. He likes being able to help people understand and use technology in new and interesting ways. One of his other passions is football (aka. Soccer). He likes both technology and soccer so much that he wrote an article about the two together! Who would’ve thought? (Answer: iMark)