Fair criticisms of IFC

IFC is the best schema for exchanging construction and facilities management project information.

There are many unfair criticisms of Industry Foundation Classes (IFC) files when often it is bad software implementation, bad setup, or bad model management at fault.

But that’s doesn’t absolve IFC from any criticism at all.

This article is based on my day-to-day experience of creating, exporting, importing, developing, and managing data with IFC and is where I believe it is fair to say IFC has got it wrong.

Version numbering

IFC2X3

Why is it an X instead of a full stop like every other app or schema in the world? IFC 2.3 makes much more sense. Not to mention the latest IFC2 version is actually IFC2X3 TC1. Again, how much more understandable would IFC2.3.1 be?

No IFC3

IFC was skipping version numbers before Windows and iPhones made it popular. Skipping number 9 is pure marketing strategy but there’s no excuse for missing 3 in this context.

IFC4add1

Obviously with IFC4 people realised that X is a bit silly, but then instead of adopting best practise and going for IFC 4.1 we now have IFC4add1 and IFC4add2 in the works. There’s even discussions of IFC5. Or perhaps it’ll be IFC5x2TC5Add1ITVBBQ?

Ugly documentation

Once you get used to it, the online documentation is actually quite functional but my goodness, it looks appalling and fails massively from a user experience point of view. Documentation can be both functional (for the power user) and visually appealing (for the new comer). Introductory diagrams full of circles, triangles, and hexagons talking about “resource domains” and “geometry topologies” are not helpful to wide adoption.

Emma Hooper of Bond Bryon BIM put together a great tutorial on using the documentation, but when an animated tutorial is needed to use documentation you know that something somewhere has gone very very wrong.

Ancient schema language

I’m certainly not suggesting that just because something is old it is not useful (my Dad is still good at DIY) and just because something is popular doesn’t mean it is good.

But, with the EXPRESS schema language and STEP file format being over 25 years old and in little use outside of IFC, there are very few people able to transfer existing knowledge or apply existing technologies to IFC.

This means almost every technology for IFC has to be learnt and built from scratch specifically for IFC, increasing cost significantly and meaning we’re unable to take advantage of developments in other domains. For the vast majority of people understanding IFC is still a very steep learning curve.

Too flexible

IFC proudly claims to support a huge array of geometry, but with very little restriction.

For example, one of the simplest possible construction items is rebar. Its just a bent bar of metal. But I’ve seen an exported piece of rebar’s IFC geometry described differently in nearly every rebar detailing tool. This causes inconsistency in how it is displayed in different tools and makes implementation of custom tools very difficult.

The Coordination View MVD (helpfully renamed to Reference View in IFC4) restricts geometry somewhat, but still leaves a little too much wriggle room. And of course usage of MVDs is still not widely understood and implemented.

IFC, IDM, MVD, bsDD, IFD, WTF??

Too many acronyms.

Emphasis on file based exchange

The emphasis on a file based approach is increasingly at odds with modern cloud and web based approaches.

The emphasis needs to switch to APIs and databases instead of files to allow for microservices and lightweight apps. The likes of speckle.works is headed in the right direction.

Summary

As I always say, IFC is the best available schema for construction and facilities management project information. But, I believe it needs to modernise to be suitable for the next generation.