Computes intersections between all input features, breaking lines and polygons wherever an intersection occurs and creating nodes at those locations. Overlapping segments are reduced to one segment before being output.
- Identifying intersections within a dataset
- Reducing geometry to line segments
- Intersecting linear features at junctions to create clean topology
- Cutting overshoots at their intersection
- Creating points (nodes) at intersections to find likely features
How does it work?
The Intersector takes all input features and compares them to each other. Features are split wherever an intersection. Split features receive attributes from intersecting features (a spatial join), and the number of overlaps encountered and segments created is counted.
Intersected segments are output, as well as nodes (point features) placed at the location of each intersection. Optionally, a list attribute can be created which will retain attributes for multiple matches.
An optional self-intersection mode is also available.
Aggregates can either be deaggregated before processing or rejected.
In this example, we start with a set of park polygons and bike path lines, and want to split the polygons where the lines intersect them. To do that, we will first use the Intersector, then build the segmented areas.
The first step is to route both datasets into one Intersector.
The default settings will produce the results we want.
The Intersector reduces all of the geometry to line segments, and creates nodes at the intersection points.
By routing only the Intersected features through an AreaBuilder and then filtering for Parks only, we end up with park polygons, split where the bike paths ran through them.
In this example, we start with a dataset of street centerlines. The street geometry is as contiguous as possible - the line segments are not broken at intersections, as shown here with a selected street highlighted in yellow. We want to create intersections, and find out which streets cross at those intersections, using a list attribute.
The street dataset set is routed into an Intersector.
In the Intersector parameters dialog, Generate List is enabled. The list is named Intersections, and one selected attribute - NAME - will be captured in the new list.
At each intersection of the lines, they are split, and a node is placed at the intersection. The nodes have a list called Intersections, which contains the NAME attribute we requested, as well as the angle and direction of line it is referring to.
The selected node shown here has four items in the list, as four line segments converge at that point - Haro St incoming and outgoing, and Jervis St incoming and outgoing.
The lists can be further manipulated - see About List Attributes.
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.
Can Merge Attributes
Counts Related Features
|NeighborFinder||Yes||In some cases||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.
Features to be compared for intersections. Point, line, and area features are supported.
The intersected features are output to this port. If the List Name parameter was specified, these features will have an attribute containing their number of overlapping input features. They will also have all attributes of the original features.
The locations of topologically significant nodes are represented by point features and are output to this port. The transformer parameters modify which attributes are included on the output features.
If a tolerance is specified, the features which were smaller than the tolerance value collapse to a point and are output to this port.
All null, surface, solid, raster, and point cloud features are output through this port.
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.
|Group By||The default behavior is to use the entire set of features as the group. This option allows you to select attributes that define which groups to form.|
|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.
The minimum distance between geometries in 2D before they are considered equal, in ground units. If the tolerance is None, the geometries must be exactly identical to be considered equal. If the tolerance is Automatic, a tolerance will be automatically computed based on the location of the input geometries. Additionally, a custom tolerance may be used.
|Duplicate Nodes at Each Elevation||
The creation of nodes can be calculated in 3D, if requested. Constructing nodes in 3D would mean that line segments would only share a node if they shared the same Z value at the point they intersected. Constructing nodes in 2D would mean that all intersecting segments would share a common node, regardless of their respective Z values.
For example, a situation where two lines (that crossed) represented roads, where one road was an overpass above the other road. with differing elevations.
If you constructed nodes in 3D, these two roads would not be linked to the same node where they crossed. Two nodes would be produced at the crossing point – each one with a different Z value.
If you constructed nodes in 2D, these lines would both link to a common node, which would be present at the location where they crossed.
In either the 2D or 3D case, the full dimensionality of the input is preserved in the output – 3D features are never converted to 2D.
The 2D or 3D choice only indicates how the nodes are created and which lines are linked to them; it does not affect the dimension of the features that are output.
Yes - Whenever 3D lines intersect at differing heights, two 2D nodes will be output via the Node port. Each node will have the same x and y coordinates, but a different node number.
No - Whenever 3D lines intersect at differing heights, a single 2D node is output at the intersection point.
|Separate Collinear Segments||
If Yes - causes overlapping segments not to be merged into a single segment: one copy is output for each original feature sharing the segment. Each such segment will have the respective original feature’s attributes as its main attributes, and attributes from all other collinear features will be added as a list attribute, if the list name was supplied.
When a coverage of polygons is input, the set of topologically significant lines which form their boundaries is output.
|Split Self-Intersecting Features||
If Yes - Self-intersections in the input features are removed by splitting the feature.
No feature-to-feature comparisons are made.
In this case, the value set to the Overlap Count Attribute will be the number of features that result from removing self-intersections. If the feature did not self-intersect, the attribute will be set to 1.
If the segment had several overlapping input features, the attributes of each of the input features will be added to the feature in the list identified by List Name, if one was specified. In any case, each output feature is also assigned the attributes of one of its original input features. This transformer also adds a "direction" attribute for each attribute resulting from the List Name parameter, labelling it as same if the geometry is oriented in the same direction, and opposite if the geometry is oriented in the opposite direction to the current geometry.
Deaggregate: All input aggregates will be deaggregated, and each split part will be processed independently. With this setting, the transformer might output more features than were given as inputs.
Reject: All input aggregates will be rejected.
|Treat Measures as||
When new coordinates are added due to intersection, the measures at those coordinates are determined from existing coordinates.
Continuous: New measures will be computed from a linear interpolation of the neighboring coordinates along that segment.
Discrete: Measures will be set to the measures of the nearest coordinates along the intersected segment.
|Overlap Count Attribute||
Names an attribute that will be added by the transformer, containing the number of collinear input lines that overlapped the output segment.
|Segment Count Attribute||
Names an attribute that will be added by the transformer, containing the number of segments into which the segment’s original feature was divided.
If an input feature was broken into n output segments, each of those segments will have an attribute named <attribute name> which has a value of n.
|Node Number Attribute||
Names an attribute that will be added by the transformer to all node features, containing a unique ID for each topologically significant node.
Specifies how attributes should be accumulated.
Drop Attributes: All incoming attributes are removed from the features.
Merge Attributes: Merges all attributes from overlapping segments.
Use Attributes From One Feature: Takes all attributes from one representative feature.
|Prefix||When Separate Collinear Segments is Yes, and Accumulation Mode is Merge Attributes, this value prefixes all incoming attributes on collinear segments. It does not affect node (point) output.|
When enabled, adds a list attribute to the output features, and the attributes of intersecting features are added to the list. Nodes will receive list attributes from all intersecting features, including direction and angle.
Enter a name for the list attribute.
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 attributes will be added to the output features.
Selected Attributes: Enables the Selected Attributes parameter, where specific attributes may be chosen for inclusion.
|Selected Attributes||Enabled when Add To List is set to Selected Attributes. Specify the attributes you wish to be included.|
|Direction Attribute||An optional attribute to include in the generated list, which indicates whether the direction of that input feature has been preserved (using same) or reversed (using opposite) in the output feature.|
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.
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.
Set values depending on one or more test conditions that either pass or fail.
Expressions and strings can include a number of functions, characters, parameters, and more - whether entered directly in a parameter or constructed using one of the editors.
|These functions manipulate and format strings.|
|A set of control characters is available in the Text Editor.|
|Math functions are available in both editors.|
|These operators are available in the Arithmetic Editor.|
|These return primarily feature-specific values.|
|FME and workspace-specific parameters may be used.|
|Working with User Parameters||Create your own editable parameters.|
|FME Licensing Level||FME Base Edition and above|
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 Intersector on the FME Community.
Examples may contain information licensed under the Open Government Licence – Vancouver