Dynamic Feature Types

There are three main components of a schema:

Feature Type
Attributes
Geometry

This section looks at Feature Types, and how a workspace author can change the feature types that are written in a dynamic translation.

Defining Feature Type Names

In all writer feature types, the feature type name is usually a fixed value, but it can also be defined by an attribute (or string constructed from attributes). We call that a Fanout.

In a dynamic translation, by default an FME attribute called fme_feature_type is used as the feature type name:

That is - in effect - a fanout using fme_feature_type. This FME attribute stores the name of the original feature type on incoming features. It makes sense to default to this attribute because then all data is written to the same feature type as it came from, and we get an output that is a duplicate of the input.

However, should you wish, there's no reason why a different attribute couldn't be used, in order to define a different set of output feature types:

Here, for example, the author is using ZoneCategory to supply the name of the layers to create. For example features might have the value Residential, Industrial, or Commercial.

At runtime FME will look in each of the Schema Sources to find a table called Residential. It will use the schema of that table to define the attributes and geometry allowed in the dynamic writer's output.

This will work well where - for example - the incoming data is a single dataset containing a single layer of zones, while the output should have a table for each category of zone. By setting an attribute different to fme_feature_type, the output can be a file-based dataset, whose schema is obtained from a database referenced in the Schema Source.

Schema Requirements

Of course, be aware that this isn't the exact same thing as a fanout. A fanout creates layers from a static definition. A dynamic workspace fetches that definition from somewhere else (the schema source).

i.e. the feature type names chosen must match a layer that exists in that source schema.

Failure to do so will lead to the data being dropped - instead of written - with a log message reporting the problem. For example, if the ZoneCategory attribute had values (like "Historic Area") that didn't exist as a table in the schema source, the log messages would look like this:

                       Features With No Schema defined
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Comprehensive Development                                                  237
Historic Area                                                                5
Light Industrial                                                            19
Multiple Family Dwelling                                                    45
One Family Dwelling                                                         19
Two Family Dwelling                                                         26
==============================================================================
Total Features NOT Written                                                 416
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

What the author must ensure is that the schema used actually contains these layers. Then the translation will proceed as expected.

Dynamic Feature Types