What is the best practice for optimizing complex translations? (i.e from IFC to 2D extent). I often have a requirement to process hundreds of IFCs at a time. What is the best method to simplify or pre-process an IFC so it is read as simply as possib

Happy new year and thanks for your response!

Unfortunately, I need detail more than the envelope / bounding box extent. I need the actual solid geometry from the IFC file in the smallest data size / most efficient way.

As you mentioned bounding box accumulator - I did some tests.

Are you able to provide some steps as to how I would 'cut' using the clipper, the IFC geometry out of it's own 3D bounding box? I feel as though this could be the most efficient way however I am having trouble because for some reason I cannot generate a single (all encompassing) 3D bounding box for my IFC file. It is lots of intersecting boxes. Do I need to create an aggregate?

e.g.

IFC reader -> boundingboxcreator (3D) -> clipper (using the original IFC again plus its' bounding box) -> usable 3D solid or surface?

My main concern is processing speed, time, and the vast numbers of files I need to process. I am just looking for advice on how to gut or clean out the junk attribution / ifc formats and simply have the geometry in its most basic form in 2D or 3D.

I have several functional workflows however I've seen on various occasions IFC files taking several hours to process, it's not ideal for me. These are not ridiculous file sizes (10-100mb). I have successfully converted albeit slowly IFCs up to 500mb in size.

Thanks for getting back to me - I've had a look and have linked two similar files below. The context of my work is high-speed rail. I am involved with themes from earthworks to electrical and fire systems, all held in IFC format. Therefore, it is relatively difficult to expect similar IFCs and my workflows are quite broad.

http://openifcmodel.cs.auckland.ac.nz/Model/Details/341

http://openifcmodel.cs.auckland.ac.nz/Model/Details/322

Hi @jacobbuckley​ ,

I think the simplest method would be to use the Directory and File Pathnames reader to get the names and sizes of all the IFC files in a folder (enable Retrieve File Properties in the reader Parameters). Then you can use a Tester filter out the too-large files before sending the file names to a WorkspaceRunner to run the IFC to GDB workspace.

One nice feature of the IFC reader is that it doesn't actually construct the geometry from the CSG description until that geometry is manipulated in an FME process. This means that you can read an IFC file very quickly if you discard the geometry early in the process.

You could read the IFC file, remove the geometry, then use an Aggregator to count the number of features. For files that have too many features, you could send to a WorkspaceRunner running a modified version of the IFC to GDB workspace that has Start Feature and Max Features to Read published as parameters, allowing you to only read a portion of the IFC file.

A daisy chain of these WorkspaceRunners, each reading a portion of the IFC file, and appending to the output GDB, would convert even the largest IFC file, while still not overloading your system.

Hey - I would suggest de-aggregator feeding into Geometryfilter. You can then exclude the unreadable / remnant geometry. You'll want to collect solid, collection, surface depending on your use-case.

However, I struggle sometimes to get satisfactory outputs - usually I place this on the input IFC. You can put this through an IFC checker or solibiri to check integrity.