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.|
Select a level of parallel processing to apply. Default is No Parallelism.
Note: How parallel processing works with FME: see About Parallel Processing for detailed information.
This parameter determines whether or not the transformer should perform the work across parallel processes. If it is enabled, a process will be launched for each group specified by the Group By parameter.
Parallel Processing Levels
For example, on a quad-core machine, minimal parallelism will result in two simultaneous FME processes. Extreme parallelism on an 8-core machine would result in 16 simultaneous processes.
You can experiment with this feature and view the information in the Windows Task Manager and the Workbench Log window.
No: This is the default behavior. Processing will only occur in this transformer once all input is present.
By Group: This transformer will process input groups in order. Changes of the value of the Group By parameter on the input stream will trigger batch processing on the currently accumulating group. This will improve overall speed if groups are large/complex, but could cause undesired behavior if input groups are not truly ordered. Specifically, on a two input-port transformer, "in order" means that an entire group must reach both ports before the next group reaches either port, for the transformer to work as expected. This may take careful consideration in a workspace, and should not be confused with both port's input streams being ordered individually, but not synchronously.
Considerations for Using Input is Ordered By
Using Ordered input can provide performance gains in some scenarios, however, it is not always preferable, or even possible. Consider the following when using it, with both one- and two-input transformers.
Single Datasets/Feature Types: Are generally the optimal candidates for Ordered processing. If you know that the dataset is correctly ordered by the Group By attribute, using Input is Ordered By can improve performance, depending on the size and complexity of the data.
If the input is coming from a database, using ORDER BY in a SQL statement to have the database pre-order the data can be an extremely effective way to improve performance. Consider using a Database Readers with a SQL statement, or the SQLCreator transformer.
Multiple Datasets/Feature Types: 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, using Ordering with multiple feature types is more complicated than processing a single feature type.
Multiple feature types and features from multiple datasets will not generally naturally occur in the correct order.
One approach is to send all features through a Sorter, sorting on the expected Group By attribute. The Sorter is a feature-holding transformer, collecting all input features, performing the sort, and then releasing them all. They can then be sent through an appropriate filter (TestFilter, AttributeFilter, GeometryFilter, or others), which are not feature-holding, and will release the features one at a time to the transformer using Input is Ordered By, now in the expected order.
The processing overhead of sorting and filtering may negate the performance gains you will get from using Input is Ordered By. In this case, using Group By without using Input is Ordered By may be the equivalent and simpler approach.
In all cases when using Input is Ordered By, if you are not sure that the incoming features are properly ordered, they should be sorted (if a single feature type), or sorted and then filtered (for more than one feature or geometry type).
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. All list attribute transformers are displayed in the Contents pane of the Transformer Help under Lists. 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|
FME Knowledge Center
The FME Knowledge Center 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 Knowledge Center.
Examples may contain information licensed under the Open Government Licence – Vancouver