SpatialRelator
Determines what type of spatial (topological) relationships exist between sets of point, line, area, and text features. Tags - but does not alter the geometry of - features when selected relationships exist, and performs a spatial join to optionally copy attributes between features.
Typical Uses
- Identifying what kind of spatial relationship(s) exist between features
- Performing a spatial join to transfer attributes from one feature to another based on their spatial relationship
How does it work?
The SpatialRelator takes in two streams of features - Requestors and Suppliers. The Requestors are the features you would like to identify information about, determining what spatial relationship(s) they have with the Supplier features. Only the Requestor features are output from the transformer. Suppliers are used to perform the analysis, and then discarded.
The transformer can be configured to look for one or more specific types of spatial relationship, and to add attributes from the Suppliers to the Requestors. These attributes, as well as the details of the spatial relationships, are (by default) added to the Requestor features as list attributes.
Each input Supplier feature is compared against the Requestor features, based on the tests chosen in the Spatial Predicates to Test parameter. When one of the comparisons is true, an entry is added to the Requestor’s list attribute. The list attribute is only created for features that have a match. Each entry contains:
- The DE9IM string representing the spatial relationship
- The name of the type of spatial relationship
- Attributes from the Supplier (all, some, or none, depending on your selection), performing a spatial join
Every Requestor feature, whether they match a supplier or not, receives a new attribute containing a count of the number of features they match.
Output for a feature that matches two Suppliers might look like this, using default attribute names and selecting a single Supplier attribute for inclusion:
The SpatialRelator does not alter geometry.
In this example, we compare a set of line features (bike paths) with polygons representing city parks. The bike paths are the Requestor - the features we want information about - and the parks are the Supplier that they will be compared to. Only bike paths with added attributes will be output - the parks will be discarded after they have been used to perform the spatial analysis.
In the SpatialRelator parameters dialog, we make the following selections:
- Spatial Predicates to Test: for this case, we will select the spatial relationships we are interested in:
-
Generate List: generating a list is the default choice, and supports adding attributes for multiple matches. Under Add to List, we choose Selected Attributes, and then select DogPark and ParkName:
Looking at the results in the Data Inspector, with the Parks layer shown for reference, we can see that all of the path segments now have a _related_candidates attribute showing how many park features they matched. Feature 10, highlighted in blue, crosses from one park into another, and so shows two entries for INTERSECTS in its _relationships list attribute.
The geometry of the features has not been altered.
Usage Notes
- See Spatial Relations Defined for more information on spatial predicates and an illustration of spatial relationships.
-
Spatial relations are based on the OGC specification and are undefined for geometries that are not OGC valid or aggregate geometries.
-
Aggregates are accepted by a subset of predicates, but should be used with care.
Choosing a Spatial Transformer
Many transformers can assess spatial relationships and perform spatial joins - analyzing topology, merging attributes, and sometimes modifying geometry. 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.
To correctly analyze spatial relationships, all features should be in the same coordinate system. The Reprojector may be useful for reprojecting features within the workspace.
Transformer |
Can Merge Attributes |
Alters Geometry |
Counts Related Features |
Creates List |
Supported Types* |
Recommended For |
---|---|---|---|---|---|---|
SpatialFilter | Yes | No | No | No |
|
|
SpatialRelator | Yes | No | Yes | Yes |
|
|
AreaOnAreaOverlayer | Yes | Yes | Yes | Yes |
|
|
LineOnAreaOverlayer | Yes | Yes | Yes | Yes |
|
|
LineOnLineOverlayer | Yes | Yes | Yes | Yes |
|
|
PointOnAreaOverlayer | Yes | No | Yes | Yes |
|
|
PointOnLineOverlayer | Yes | Yes | Yes | Yes |
|
|
PointOnPointOverlayer | Yes | No | Yes | Yes |
|
|
Intersector | Yes | Yes | Yes | Yes |
|
|
Clipper | Yes | Yes | No | No |
|
|
NeighborFinder | Yes | In some cases | No | Yes |
|
|
TopologyBuilder | Yes | Yes | No | Yes |
|
|
* NOTE: Curve includes Lines, Arcs, and Paths. Area includes Polygons, Donuts, and Ellipses.
Spatial analysis can be processing-intensive, particularly when a large number of features are involved. If you would like to tune the performance of your workspace, this is a good place to start.
When there are multiple ways to configure a workspace to reach the same goal, it is often best to choose the transformer most specifically suited to your task. As an example, when comparing address points to building polygons, there are a few ways to approach it.
The first example, using a SpatialFilter to test whether or not points fall inside polygons, produces the correct result. But the SpatialFilter is a fairly complex transformer, able to test for multiple conditions and accept a wide range of geometry types. It isn’t optimized for the specific spatial relationship we are analyzing here.
With a SpatialFilter:
The second example uses a PointOnAreaOverlayer, followed by a Tester. The features output are the same as in the first method, but the transformer is optimized for this specific task. The difference in processing time is substantial - from 54.3 seconds in the first configuration, down to 13.7 seconds in the second one.
With a PointOnAreaOverlayer and a Tester:
If performance is an issue in your workspace, look for alternative methods, guided by geometry.
Configuration
Input Ports
Point, line, area, and text features that will be compared and then output with a tagged list describing the relationships.
Point, line, area, and text features that will be used to compare with Requestor features, but not output.
Output Ports
These are the Requestor features with the new attributes added. One list entry is made for each of the Suppliers that has at least one matching predicate.
Requestor and Supplier features with invalid geometries will be rejected and output via this port. If predicates are provided via an attribute, Supplier features with no or invalid predicates will also be output via this port.
Rejected features will have an fme_rejection_code attribute with one of the following values:
INVALID_BASE_GEOMETRY_NOT_OGC_VALID
INVALID_BASE_GEOMETRY_TYPE
INVALID_BASE_GEOMETRY_VERTICES
INVALID_CANDIDATE_GEOMETRY_NOT_OGC_VALID
INVALID_CANDIDATE_GEOMETRY_TYPE
INVALID_CANDIDATE_GEOMETRY_VERTICES
INVALID_CANDIDATE_PARAMETER_PREDICATE
INVALID_GEOMETRY_TYPE
MISSING_CANDIDATE_PARAMETER_PREDICATE
Rejected Feature Handling: can be set to either terminate the translation or continue running when it encounters a rejected feature. This setting is available both as a default FME option and as a workspace parameter.
Parameters
Group By | This parameter is used to indicate that only Requestors and Suppliers that have the same value for certain attributes should be compared. Both the Requestors and Suppliers must having matching attribute names and values. |
Group By Mode |
Process At End (Blocking): This is the default behavior. Processing will only occur in this transformer once all input is present. Process When Group Changes (Advanced): This transformer will process input groups in order. Changes of the value of the Group By parameter on the input stream will trigger processing on the currently accumulating group. This may improve overall speed (particularly with multiple, equally-sized groups), but could cause undesired behavior if input groups are not truly ordered. Considerations for Using Group By
There are two typical reasons for using Process When Group Changes (Advanced) . The first is incoming data that is intended to be processed in groups (and is already so ordered). In this case, the structure dictates Group By usage - not performance considerations. The second possible reason is potential performance gains. Performance gains are most likely when the data is already sorted (or read using a SQL ORDER BY statement) since less work is required of FME. If the data needs ordering, it can be sorted in the workspace (though the added processing overhead may negate any gains). Sorting becomes more difficult according to the number of data streams. Multiple streams of data could be almost impossible to sort into the correct order, since all features matching a Group By value need to arrive before any features (of any feature type or dataset) belonging to the next group. In this case, using Group By with Process At End (Blocking) may be the equivalent and simpler approach. Note: Multiple feature types and features from multiple datasets will not generally naturally occur in the correct order. As with many scenarios, testing different approaches in your workspace with your data is the only definitive way to identify performance gains. |
Support Mode |
Support Aggregates: (default) Both multi and aggregate geometries will be supported. However, the only available predicates will be Contains, Equals, Intersects, Touches, and Within. The Overlaps predicate and the Crosses predicate will not be supported. 9-character masks representing Dimensionally Extended 9 Intersection Matrices will also not be supported. Support All Predicates: All the predicates described in the Spatial Relations Defined page will be supported, except Disjoint. However, aggregate and multi geometries will not be supported. |
Spatial Predicates to Test |
This parameter lists the spatial predicates that will be used for comparisons between the Requestor and Supplier features. These can either be selected directly from the list, or taken from attribute values. Tests include:
Not all tests are available for aggregate or multi geometry. If the Support Mode is Support All Predicates, you may also test relationships using arbitrary 9-character masks. Such masks consist of the rows of a Dimensionally Extended 9 Intersection Matrix. Note that in order to use these masks with the SpatialRelator, you must assign them to an attribute on the Supplier features, and include the value of that attribute in the Tests to Perform clause (you cannot specify them directly). Multiple predicates may be specified in one attribute by separating them with a space. Note that this transformer does not allow a matrix representing a disjoint relationship to be used. This includes any matrix that has F or * in all of the four top-left elements. If you wish to find features that are disjoint to another feature, the SpatialFilter may be used. For more information about predicates, see Spatial Relations Defined. |
Attributes that Must Differ | This attribute controls which attributes must have different values before a match is declared. |
Curve Boundary Rule | This parameter specifies how to determine the boundary of curve and multicurve geometries. The Default Rule is that any curve endpoints that occur an odd number of times in the geometry as a whole, will be considered its boundary – that is, a linear loop (a line whose start point equals its endpoint) will not have any boundary. The other rule specifies that the curve or multicurve's boundary is the set of all its endpoints. |
Related Suppliers Count Attribute | This attribute specifies the name of an attribute that will be added to each Requestor, which stores the number of Suppliers with which the Requestor had at least one true relationship. |
Calculate Cardinality of Intersections | If Yes, then for each Supplier that matches a Requestor, three attributes will be added to the corresponding list entry: card_point, card_line, and card_area. These count the number of points, lines, and areas that comprise the intersection of the Requestor and Supplier. For instance, a point is counted if two polygons touch at a vertex, a line is counted if they touch at an edge, and an area is counted if they overlap. |
Merge Attributes
When checked, enables options for merging feature type attributes.
Accumulation Mode |
Merge Supplier: Attributes from all features are merged. Conflicts are handled according to parameter Conflict Resolution. Prefix Supplier: All Supplier attributes are prefixed with a value specified by the Prefix parameter. Only Use Supplier: Only attributes from Supplier features are used. |
Conflict Resolution |
Specifies how to handle attribute conflicts when Accumulation Mode is Merge Supplier. Use Requestor: Gives priority to Requestors. Use Supplier: Gives priority to Suppliers. |
Prefix | When Accumulation Mode is Prefix Supplier, the specified value prefixes Supplier attributes. |
When attributes are merged down from Supplier to Requestor features, existing attributes are not replaced. Therefore if the Suppliers and Requestors have attributes with the same name, the values will not be transferred down.
This can be worked around by renaming, removing, or prefixing attributes to avoid name collisions. (See AttributeManager and BulkAttributeRenamer.)
Generate List
When checked, enables options for list generation. The default is On.
The list attributes will contain relationship and spatial join attribute values. Spatial relationship information is added in this form:
<LIST_NAME>{i}.de9im = [DE9IM string]
<LIST_NAME>{i}.pass{0} = [true PREDICATE 1]
<LIST_NAME>{i}.pass{1} = [true PREDICATE 2]
...
<LIST_NAME>{i}.pass{n} = [true PREDICATE n+1]
List Name |
This parameter specifies the name of the list attribute that will be added to the Requestor features. Note: List attributes are not accessible from the output schema in Workbench unless they are first processed using a transformer that operates on them, such as ListExploder or ListConcatenator. Alternatively, AttributeExposer can be used. |
Add To List |
All Attributes: All Supplier attributes will be added to the Requestors. Selected Attributes: Enables the Selected Attributes parameter, where specific attributes may be chosen to be added from the Suppliers to the Requestors. |
Selected Attributes |
Enabled when Add To List is set to Selected Attributes. Specify the attributes you wish to be added from the Suppliers to the Requestors. |
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.
Using the Text Editor
The Text Editor provides a convenient way to construct text strings (including regular expressions) from various data sources, such as attributes, parameters, and constants, where the result is used directly inside a parameter.
Using the Arithmetic Editor
The Arithmetic Editor provides a convenient way to construct math expressions from various data sources, such as attributes, parameters, and feature functions, where the result is used directly inside a parameter.
Conditional Values
Set values depending on one or more test conditions that either pass or fail.
Parameter Condition Definition Dialog
Content
Expressions and strings can include a number of functions, characters, parameters, and more.
When setting values - whether entered directly in a parameter or constructed using one of the editors - strings and expressions containing String, Math, Date/Time or FME Feature Functions will have those functions evaluated. Therefore, the names of these functions (in the form @<function_name>) should not be used as literal string values.
These functions manipulate and format strings. | |
Special Characters |
A set of control characters is available in the Text Editor. |
Math functions are available in both editors. | |
Date/Time Functions | Date and time functions are available in the Text Editor. |
These operators are available in the Arithmetic Editor. | |
These return primarily feature-specific values. | |
FME and workspace-specific parameters may be used. | |
Creating and Modifying User Parameters | Create your own editable parameters. |
Reference
Processing Behavior |
|
Feature Holding |
Yes |
Dependencies | |
FME Licensing Level | FME Professional Edition and above |
Aliases | |
History | |
Categories |
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 SpatialRelator on the FME Community.
Examples may contain information licensed under the Open Government Licence – Vancouver