Hello @jacobbuckley​, did you want a building footprint, or an extents rectangle? Perhaps for the latter, you could use a BoundingBoxAccumulator. Let me know if you have anymore questions or success! Happy New Year! Best, Kailin

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.

Are any of these models similar to the one(s) you are working with? That will let us play with similar data while respecting your security.

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

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

Does anyone have any further ideas? Thanks

Hi @jacobbuckley​ ,

I am attaching a workspace that uses the GeometryPropertyExtractor, GeometryPartExtractor and Triangulator to simplify the complex IFC geometry and property structure to one suitable for Geodatabase.

Please give it a try and let me know how it works for you. You will likely need to adjust the attribute names in the AttributeExposers and GDB feature types to match your source data.

Dave, thank you for this. I have now been able to test (GeometryPropertyExtractor, GeometryPartExtractor and Triangulator) and successfully ran 60 IFC files over around 2 hours yesterday. It is a great option and considerably faster than using a REVIT IFC reader. Is the logic behind this that you are reconstructing a simplified version of the IFC collection /solids?

I have a related question. For the above example I had 3 failures due to extreme IFC file sizes. I use the workspace runner to loop through a folder of IFC files. Is there way to implement a stop to a workspace - say if it took more than X number of minutes and the workspace hadn't completed? To then start the next workspace? I am hesitant increasing the number of processes /workspaces as my machine is not the best and this has caused memory issues in the past.

Many thanks for your help.

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.

Hi Jacob, did you have any tips on how to best turn arbitrary and messy Revit models to GDB? It seems I keep getting snagged on non-3d geometry which halts the transformation. I imagine I need to do some sort of recursive filtering and recombining ...

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.