#
SherbendGeneralizer

Uses the Sherbend algorithm to simplify lines by reducing unnecessary details based on the analysis of the line’s bends.

Sherbend is a constraint-based algorithm that preserves the spatial relationship of the lines and points in the input data. The Sherbend algorithm iteratively generalizes the bends in a line by using the *Diameter* parameter to select bends for generalization. The generalization process may eliminate, reduce, or combine bends, while resolving conflicts.

The strategy for generalizing bends in a line is as follows:

- Calculate the area of a reference circle whose diameter is specified by the
*Diameter*parameter. - For each line, determine the locations of the bends.
- For each bend, calculate its perimeter. Next, construct a circle whose circumference is equal to that perimeter. Finally, determine the adjusted area of the bend, which is 75% of the area of that circle.
- For each bend, generalize the bend if its area is below the area of the reference circle and spatial constraints are met.
- Repeat the above steps until there are no more bends to generalize.

## Input Ports

Input lines for generalization. They are assumed to not self-intersect or intersect with another line or point.

Input points for the sidedness constraint. When the “Sidedness” constraint is enabled, these points will prevent a bend generalization if that would change the spatial relationship between the bend and the points.

## Output Ports

The generalized lines.

Bends that, if generalized, would violate the selected constraint.

Invalid input features will be output to the <Rejected> port.

## Parameters

### Transformer

Only lines and points in the same group are subject to constraint checking. If no group is specified, all lines and points are placed in the same group.

**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.

### Parameters

This parameter specifies the diameter of the reference circle (described at the beginning of this documentation), which roughly describes the width of a bend below which the bend will be generalized. Different lines can have different diameters specified as an attribute. The bigger the diameter, the more likely bends will be generalized.

Enables spatial constraints, which are only applied to lines and points in the same group.

*None:*constraints will not be applied.*Self Intersection*prevents a line from intersecting with itself, with the assumption that input lines do not self-intersect when entering SherbendGeneralizer.*Self, Line-Line Intersection*prevents a line from intersecting with itself or another line, with the assumption that no input line self-intersects or intersects another line when entering SherbendGeneralizer.*Self, Line-Line Intersection, Sidedness*, in addition to maintaining non-intersecting lines, maintains the relative positioning of all lines and points. For example, if a line is entirely on the right side of another line, that line will remain entirely on the right side of that other line after the generalization process.

In this diagram, the blue bend cannot be generalized as it would violate the “Sidedness” constraint:

In this diagram, the blue bend cannot be generalized as it would violate the “Self Intersection” constraint:

This parameter, if set to *No*, will re-order (rotate) the coordinate list of each closed line in an attempt to improve the quality of generalization. To preserve juncture connectivity, the transformer must ensure that the starting and end coordinates of every line are kept stationary. Therefore, if it is important to keep the positions of the first and last coordinates in a closed line (perhaps because they are on a juncture), this parameter should be set to *Yes*.

If this parameter is set to *Yes*, the endpoints of a line will not be moved. This behavior allows the preservation of juncture connectivity.

## Examples

In this example, a bend is reduced (green = input, red = output):

In this example, a bend is eliminated:

In this example, three bends are combined into one:

The following diagram illustrates the generalization process on a single line in a real-world dataset:

This example illustrates the generalization process on a set of contours:

## Additional Information

The aim of line generalization is to reduce the details on a line for representation at a smaller scale. While the well-known Douglas-Peucker algorithm, is good at reducing the number of points in a line, it is not so good at removing unnecessary details in a line. The Generalizer transformer contains a selection of algorithms under its parameters including the Douglas-Peucker algorithm.

In comparison, the Sherbend algorithm is well suited for the generalization of natural features (contours, lakes, rivers, wooded areas, etc.) because it preserves the general shape of the line. Moreoever, if spatial constraints are enabled, the spatial relationship between the input entities are preserved. The Douglas-Peucker algorithm with a small tolerance is often used before or after Sherbend to further reduce the number of points to further fulfill the goals of generalization.

## Performance and Usage Notes

- The Sherbend algorithm iteratively detects and generalizes bends, and then detects and resolves spatial conflicts. The generalized lines from one iteration are passed to the next iteration until the lines cannot be generalized further. Due to this iterative process, the algorithm is time-intensive, which is a tradeoff to improved accuracy and quality of generalization.
- Constraint checking is a highly time-intensive operation. Use constraints only as necessary.
- To generalize each feature independently, consider using the Generalizer transformer.

## 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.

## Transformer Categories

## FME Licensing Level

FME Professional edition and above

## Search FME Community

Search for samples and information about this transformer on the FME Community.