If you set the accumulation mode to "Merge Clipper" or "Prefix Clipper" it will pass the Clipper attributes on to the Clippees that are inside.

A couple of things occur to me.

1) If the clipper ID attribute is the same name as the that on the clippee (dxf) then it might not overwrite. As @redgeographics suggests, try setting a prefix

2) How are you inspecting the output? Is it being directed to an Inspector direct from the Clipper? Or are you writing to a dataset and inspecting that? You want to be sure that it's the Clipper that is the problem and not the writer (maybe that attribute isn't defined on the writer, or is defined with the wrong data type?)

3) I would set a Breakpoint on the clippee input to the transformer and run this in debug mode to check each feature step-by-step to make sure you know exactly what is happening and to confirm that it's the Clipper that is the problem. Or maybe connect a Logger to the Inside port of the Clipper to log what is being output. It *should* have the attributes from the Clipper

Hope something there helps

Mark

Hi,

• I have an ESRI-Shape with several thousand tiles (rectangles) with a single ID (in my case "KACHEL" translated "TILE")

• I have an Input-file with vectors (in my case a Bentley DGN-File) with points, lines and areas.

1. A folder with a single file per tile - with just the tile geometry (FANOUT)
2. A file with all used tiles - just the tile geometry (NO FANOUT)
3. A folder with a single file per tile - with the clipped vectores AND the tile geometry (FANOUT)

• with the "Chopper"-Transformer I chopped lines and areas from the vector-file into points
• after that I made an overlay with the "PointOnAreaOverlayer"-Transformer to find out which tiles where used
• after that I used the "Tester"-Transformer to divide the tiles in USED and UNUSED by the attribute '_overlaps'

< Image of the workflow attached >

For starters, I'm not sure whether it's really necessary to test which tiles are used. I suspect it may add overhead. I would also recommend testing this on a small sample of the data first, if you limit the DGN reader to say the first 1000 features you can test whether this is working before letting it run through the entire set of 1M features.

If you make sure the shapefile gets read first and set the Clipper's 'Clipper Type' parameter to Clippers First you'll be able to more quickly work through the data, that way it doesn't need to chache all data before it can start clipping.

In your sample you've set the accumulation mode to 'Only use Clipper', that means you'll lose all original DGN attributes. If that's what you want then fine, otherwise maybe change it to one of the other options.

The attribute KACHEL is coming out of the Clipper, so you should be able to fan out on that. You just need to send the original tiles to the same writer, which should have that same attribute. Hope this helps.

Hi,

thanks for the help - it works :-)

I tried it with less objects, but for 14 Tiles and 4.500 lines and points it lasted nearly 3 hours.

Is there a trick to speed it up?

fme-2.png

Hi,

about the performance-problems, I found out that this seems to be 'clipper-specific':

https://knowledge.safe.com/questions/3857/clipper-speed-comments-from-safe.html

Has anyone an idea?

Same performance issue in FME 2017

Has noone ever had the same problem?

I don't think 14 tiles and 4500 should take 3 hours of processing.

Why not go straight for a LineOnArea overlayer (instead of chopping them to pints first) and then test for overlaps? (and check fme_feature_type if needed).

Seems to save quite a lot of comparisons.