FeatureJoiner

Joins features by combining the attributes and/or geometry of features based on common key attribute values. Performs Left, Inner, and Full joins.

Jump to Configuration

Typical Uses

  • Performing simple joins between features, using attribute value(s) as keys

How does it work?

The FeatureJoiner performs simple join operations, much like a SQL join, without requiring knowledge of SQL query construction.

It has two input ports - Left and Right - where two streams of features to be joined are routed into the transformer. One or more attributes are selected to join on.

A Left feature matches a Right feature when every pair of keys specified in the Join On table has the same value. When a match occurs, attributes/geometry from the Left and Right feature are combined, and the combined feature is output to the Joined port.

Join Mode

The Join Mode parameter defines the type of join to be performed, determining which features will be output via the Joined output port.

Join Mode

Joined Output

 

Inner
  • Only features that have matching Left and Right pairs.
Left
  • Features that have matching Left and Right pairs, AND
  • All other unmatched Left features.
Full
  • Features that have matching Left and Right pairs, AND
  • All unmatched Left and Right features.

Join Behavior

A Joined feature is produced each time a Left feature is matched to a Right feature through its keys. The number of output features produced will depend on whether or not multiple Left and Right features match.

The type of join is determined by the nature of the data used (it is not a parameter). Any of these types of joins may be produced by any of the Join Modes (Inner, Left, or Full).

Cardinality

Description

Output (assuming 1 key value)

1:1 One to One: If each Left feature has a single match among the Right features (for example a single point feature is mapped to an address table via a unique address ID key), this is a 1:1 match and produces a single Joined feature.

1 Left matches 1 Right:

1 Joined Feature output

1:M One to Many: If each Left feature has multiple matches among the Right features (for example a single address record is mapped to a list of planning applications for that address), this is a 1:M (one-to-many) match and produces a Joined feature for every match that occurs.

1 Left matches 10 Right:

10 Joined Features output

M:1 Many to One: If multiple Left features match a single Right feature record (for example a number of addresses match to the same census data via a postal code field) this is a M:1 (many-to-one) match and produces a Joined feature for every match that occurs

10 Left match 1 Right:

10 Joined Features output

M:N Many to Many: If multiple Left features match multiple Right features (for example a number of addresses match to a number of records for electrical power outages) this is a M:N (many-to-many) match and produces a Joined feature for every match that occurs.

10 Left match 10 Right:

100 Joined Features output*

*When all features have identical key values - all Left match all Right.

Unmatched Features

Features (both Left and Right) that do not find a match are handled according to the Join Mode (Inner, Left, or Full). Both the Left and Full modes will result in some or all unmatched features being output via the Joined port, depending on Mode:

Join Mode

Unmatched Left features output

Unmatched Right features output

Inner UnjoinedLeft UnjoinedRight
Left Joined UnjoinedRight
Full Joined Joined

 

Usage Notes

  • FeatureJoiner versus FeatureMerger:
    • If the join requirements are simple, FeatureJoiner should give better performance.
    • If join requirements are more complex, such as constructing keys, using expressions, naming conflict resolution, consider using the FeatureMerger.
    • If you wish to get only one joined feature, regardless of the number of joins (1:M join produces 1 feature with a list of joins, rather than 1 feature for each join as the FeatureJoiner does), use the FeatureMerger.
    • The FeatureJoiner does not perform some of the advanced list building or geometry handling operations that the FeatureMerger does, but these may be possible by using the FeatureJoiner plus other transformers.
  • For complex joins using SQL syntax, or more than two input feature streams, consider using the InlineQuerier.

Choosing a Feature Joining Method

Many transformers can perform data joining based on matching attributes, expressions and/or geometry. When choosing one for a specific joining task, considerations include the complexity of the join, data format, indexing, conflict handling, and desired results. Some transformers use SQL syntax, and some access external databases directly. They may or may not support list attribute reading and creation.

Generally, choosing the one that is most specific to the task you need to accomplish will provide the optimal performance results. If there is more than one way to do it (which is frequently the case), time spent on performance testing alternate methods may be worthwhile. Performance may vary greatly depending on the existence of key indexes when reading external tables (as opposed to features already in the workspace).

Configuration

Input Ports

Output Ports

Parameters

Editing Transformer Parameters

Using a set of menu options, transformer parameters can be assigned by referencing other elements in the workspace. More advanced functions, such as an advanced editor and an arithmetic editor, are also available in some transformers. To access a menu of these options, click beside the applicable parameter. For more information, see Transformer Parameter Menu Options.

Defining Values

There are several ways to define a value for use in a Transformer. The simplest is to simply type in a value or string, which can include functions of various types such as attribute references, math and string functions, and workspace parameters. There are a number of tools and shortcuts that can assist in constructing values, generally available from the drop-down context menu adjacent to the value field.

Reference

Processing Behavior

Group-Based

Feature Holding

Yes

Dependencies None
FME Licensing Level FME Base Edition and above
Aliases  
History  
Categories

Filters and Joins

FME Community

The FME Community is the place for demos, how-tos, articles, FAQs, and more. Get answers to your questions, learn from other users, and suggest, vote, and comment on new features.

Search for all results about the FeatureJoiner on the FME Community.

 

Examples may contain information licensed under the Open Government Licence – Vancouver