ShortestPathFinder

Lines defining the network in which to find a path or paths. Input line features must be a topologically noded network with features connecting at line ends only. That is, all features must be split at junctions.

The From-To line contains vertices that define the source and destination nodes in the network. It can contain intermediate stops before the final destination. For example, a From-To line may be used to find the path from A to B to C to D. This can also be read as “the path from A to D that also passes through B and C.” From-To lines can be created by connecting points together to form a line, using the LineBuilder or VertexCreator transformers.

Note: Intermediate stops on a From-To line need to exactly match an existing node in the network features. To help with this you might use the Chopper transformer (to chop the network into 2-point lines) or the AnchoredSnapper transformer (to snap the intermediate points onto the network).

For each From-To line, if a path is found it will be output as a single feature through the Path port. This output feature contains the attributes and coordinate system of the original From-To line. The geometry of the output feature is made up of all the parts of network that form the shortest path. Note that if Cost Type is set to By One Attribute or By Two Attributes then the “shortest path” is the one where the sum of the values of the applicable Cost Attribute values is the least.

If a path is not found for a given From-To line, then this From-To line will be output through the NoPath port.

All network features that are not used as part of the shortest path are output through the Unused port.

Input From-To lines are output through this port. If Reorder From-To Line is Intermediate Points Only or All Points, a _reordered attribute is added indicating whether the From-To line was reordered.

All non-linear features from either input port are output through the <Rejected> port, as are any From-To lines that have a negative cost (when Cost Type is set to By One Attribute or By Two Attributes).

Rejected features will have an fme_rejection_code attribute with one of the following values: INVALID_DESTINATION_GEOMETRY_TYPE, INVALID_LINE_GEOMETRY_TYPE, INVALID_PARAMETER_WEIGHT.

The default behavior is to use the entire set of input features as the group. This option allows you to select attributes that define which groups to form. You can select attributes from both Network and From-To input features.

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.

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.

By Length: The cost of each input line is set to the length of the line. Orientation of the line is not considered.

By Length (Forward Only): The cost of each input line is set to the length of the line. The algorithm considers only the original orientation of the lines when finding the shortest path.

By One Attribute: The cost of each input line is specified by Forward Cost Attribute. The algorithm considers only the original orientation of the lines when finding the shortest path.

By Two Attributes: The shortest path algorithm will consider both directions of the input lines. The original orientation of the input line has the cost specified by Forward Cost Attribute and the reversed orientation of the input line has the cost specified by Reverse Cost Attribute.

By Straight Line Distance (No Network): Cost is calculated as the straight line distance between vertices in the From-To line. This option is used with Reorder From-To Line.

The values that result from Cost Type are summed for all input lines as they relate to the From-To line, and the shortest sum becomes the shortest-found path.

This parameter is used when Cost Type is set to By One Attribute or By Two Attributes.

This parameter is used when Cost Type is set to By Two Attributes.

Whether to allow the reverse of a line in the network to be used immediately following that line. If No, paths that reverse on each other are not considered when finding a shortest path.

When specified, this attribute list that will hold the attributes for each input Network feature that make up Path output features.

This list also contains a _direction attribute that stores the direction of the segment of the shortest path as compared to its original Network feature. It will either be “same” or “opposite”, depending if the original Network feature had to be reversed or not.

Select Yes to snap the points of the From-To line to the closest end points of the Network lines. The points are only snapped to the network lines if they are within the tolerance specified in Snapping Tolerance.

Note: The shortest distance is calculated based on the specified From-To line and is not affected by snapping.

The tolerance used when From-To and Network Snapping is set to Yes. Points of the From-To line will be snapped to the Network lines if they are within this tolerance.

Specifies whether the points of the input From-To line should be reordered to find a shorter path. This option is useful when the order of points of the From-To line is not important, such as in travelling salesman problems. A metaheuristic is used to find a low-cost ordering of points.

No: The input From-To line is used as-is. No optimization occurs.

Intermediate Points Only: The start and end points of the input From-To line are untouched. Intermediate points are reordered.

All Points: All points of the input From-To line are reordered.

The number of times to run the optimization algorithm. The greater the number of iterations, the closer the result will be to the optimal solution. Increasing this parameter increases translation time.

This parameter must be set to a positive integer. The default value is 10000.

The number of times the optimization algorithm needs to return the same potential result before it is accepted. Setting this parameter to a high value may result in very long translation time or cause the translation to never complete.

This parameter must be set to a non-negative integer. A value of 0 specifies that no verifications are required. The default value is 1.

The greatest cost that will be accepted as valid. Setting this parameter to a low value may cause the translation to never complete.

This parameter must be set to a non-negative value. A value of 0 specifies that there is no restriction on the cost that will be accepted. The default value is 0.