Clipper - Duplicate the Clippee

To be clear, right now we chop up the clippee so that whatever part was inside the first clipper is taken away and not even considered when we look at the second clipper. WIth the option proposed, we'd just look at the original clippee against each clipper, which would result potentially in some overlapping parts of the clippee being output. I think this would be a very simple change, in fact, it is simpler in the processing than what we do today.

I would suggest adding this as an option in the Clipper transformer. I can see situations when you do want duplicate clippees, and situations when you don't (as is the case at this moment).

Is there any chance of implementing this. I have need this behaviour to output all the clippees in each clipper. I use a fanout on the writer to separate the outputs of the transformation by clipper (each clipper is given a unique ID and the attributes merged by the transformer.)

A solution in keeping with other transformers would be to allow a list of clipper attributes to be generated. A ListExploder could then be used to create a feature per clipper.

We are in the processing of overhauling the experience and functionality of Clipper. This request is being considered. To make sure our design will meet your need, I'd really like to better understand the related use cases.

'>

The top left part of this illustration shows a simple example where the two rectangle-shaped clipper areas have overlap, and we want to use them to clip the triangle feature. If I understand correctly, what's requested here is the outcome shown in the "Requested" box on the top right. In comparison, the "Current" box shows what the Clipper currently produces.

@erik_jan and @jdh, You both agreed that there should be a parameter that allows users to choose between the "Current" and the "Requested" behavior. In cases where the clipper features overlap, I'm failing to imagine a scenario where the "Current" behavior is more useful. Could you please share some examples where the "Current" behavior is preferred? (Clipper features could be either areas or solids)

@ianashley, you suggested that the clipper should be able to generate a list that includes attributes from all the clipper features. This way you can then use a ListExploder to achieve the outcome you need. If we go with either the "Requested" or the "Current" approach (or both), each "Inside" port output feature would be the result of intersecting a clippee with only one clipper feature. The only type of output that could have a feature with attributes from multiple clippers is what's illustrated on the "List" box above. There would need to be 3 features output, and the middle one would have a list with attributes from both Clipper 1 and Clipper 2. I'm wondering, in your use case, would the output illustrated in the "Requested" box be sufficient? If you do require a list to be generated, would the outcome of the AreaOnAreaOverlayer be closer to what you need?

Like @jdh, I wrote a custom transformer (unpublished) with a very similar methodology 6-7 years ago to get around this. It would be very handy to have natively.

Looking at the potential output, I would prefer the option with the list.

That would allow (with a bit of postprocessing) to get both the "Current" and "Requested" situations.

Is the most flexible option.

I definitely support this, as I had this issue right this week! My preferred output would be the "Requested" one, although could easily work with the "List" option as well.

(I can share workbench if desired (but not publicly))

@xiaomeng keeping the current behaviour as a parameter would allow backward compatibility with existing workflows and the situation where there should be no overlaps in the clipped results.

I have one or two workflows where the clippers are sorted to allow for a first one wins, usually because the first clipper boundary is more precise than the later clipper.

If we move to a requested only behaviour, then the above can be accomplished by the use of two clippers in sequence, so that is not a show stopper.