Moves the attributes/geometry from one feature to another feature. Features that contain the desired attributes/geometry are connected through the SUPPLIER port, and the features that will receive the attributes/geometry are connected through the REQUESTOR port.
When a Requestor finds a Supplier, the attributes from the Supplier are merged with the Requestor. If the Requestor already had an attribute that the Supplier also had, the Requestor's original value for that attribute is preserved. A single Supplier may be used by many Requestors.
Any merged geometry preserves arcs, ellipses and text.
Requestor features are joined to Supplier features when their respective Join Attribute parameters have the same value.
The source of new attributes for features that enter through the REQUESTOR port.
Receives the new attributes from the features connected to the SUPPLIER port.
Requestors that find a Supplier.
Requestors that do not find a Supplier.
Requestors that have no value for the Join Attribute.
Suppliers that are used by at least one Requestor.
Suppliers that are not used by any Requestor.
Supplier features with the same Join Attribute value as an earlier Supplier feature. Note that Duplicate Suppliers will not be output if a List Name is specified or Process Duplicate Suppliers is set to Yes.
The input features may be partitioned by the Group By parameter. If you choose any Group By attributes, then references between features will only be resolved if they share a common value for the selected attributes.
If you do not choose any Group By attributes, all features are processed together.
If you have more than one Reader, a typical use is to group by reader_id to ensure that references are resolved within the correct set of features.
You would use this transformer if you have a group of features that you want to combine with another group of features to get either their geometry or their attributes, or both. These choices are determined through the Merge Type parameter:
Attributes Only: Existing attributes on a Requestor feature will never be overwritten by attributes of the same name on any Supplier features. Note that any fme_* attributes present on the Supplier features will not be transferred to the Requestor feature.
Build Polygons: If the Suppliers consist exclusively of polygon and donut polygon features, any common border segments will be removed. If the Suppliers contain at least one non-donut or non-polygon feature, then the transformer will form polygons and donuts from the Suppliers and will join connected line segments of the Supplier features before setting the geometry of the Requestor feature. In this case, the geometry may be an aggregate if several disjoint geometries were created.
Build Aggregates: The transformer will create an aggregate of the geometries of the Supplier features. (If there is only one Supplier feature, then the Requestor geometry will be an aggregate with one element.)
Build Lines from Points: The transformer will connect the points of the Supplier features into lines. Note that any non-point features that are referenced will be ignored when building lines.
The attribute of Requestor features that will be matched against the Supplier Join Attribute for Supplier features.
The attribute of Supplier features that will be matched against the Requestor Join Attribute for Requestor features.
Normally the Suppliers all have unique values in their Supplier Join Attribute, and any duplicate Suppliers are ignored by the transformer. However, if the Process Duplicate Suppliers parameter is set to Yes, then all Suppliers that match the Requestor Join Attribute value will be combined onto that Requestor.
Note that if a List Name is specified, then duplicate Suppliers will automatically be allowed regardless of the parameter setting. If a List Name is specified, then any Suppliers that are combined with a Requestor will have their attributes added to the specified list on the Requestor, in addition to being merged onto the Requestor feature.
When multiple Suppliers are associated with one Requestor, this parameter governs what happens to Requestors that cannot locate all of their Suppliers.
If this parameter is set to Yes, then the Suppliers that were found will be combined onto the Requestor and it will be output (after being changed) via the INCOMPLETE port. The Suppliers used will be output via the REFERENCED port. If this parameter is set to No, then the Requestor will be output untouched via the Incomplete port and the Suppliers will be output via the UNREFERENCED port.
If more than one Supplier is found for a given Requestor, and Process Duplicate Suppliers is No (and a List Name is not given), then every Supplier after the first is output via the DUPLICATE_SUPPLIER port. Only the first of the Suppliers will be matched with a Requestor. If set to Yes, then the duplicate Suppliers are all matched with the corresponding Requestor.
The InlineQuerier is the powerful cousin of the FeatureMerger. Whereas the FeatureMerger joins two datasets and uses a simple, single attribute key to match features, the InlineQuerier allows any number of input datasets to be merged, using the full power of SQL across any number of tables and columns. Furthermore, the InlineQuerier allows its input data to be reused multiple times in a single transformer, whereas if multiple joins are to be done with a FeatureMerger, multiple FeatureMergers must be employed and copies of the features sent to each. On the other hand, there is some overhead for the InlineQuerier to load the underlying SQLite database. Using a single InlineQuerier instead of several FeatureMergers also simplifies the workspace.
Unless only a single FeatureMerger is needed in a workflow, the InlineQuerier may be a better choice. Older workspaces with multiple cascading FeatureMergers may experience a performance improvement by replacing the FeatureMergers with a single properly configured InlineQuerier.
If all the data to be queried already exists in a SQL-capable data source, it is always more efficient to use the SQLCreator or SQLExecutor, because this allows the queries and filtering of the data to be executed directly by the database before it enters the FME environment.
The FeatureMerger joins two datasets and uses a simple, single attribute key to match features. You can concatenate attributes to simulate a multi-key join. The FeatureMerger is also able to perform certain geometric operations on incoming features using its Merge Type parameter. FeatureMerger does all joins in memory so it can be faster than the Joiner if you have more than one relationship on the same data. The article FME2011 Use Case: Joiner vs FeatureMerger contains a more detailed comparison of these transformers.
About Transformer Parameter Options
Search for samples and information about this transformer on FMEpedia.
Keywords: concatenated foreign key tag cross-reference "cross reference" FeatureMerger