Best possible IFC – Part1
March 17, 2014 by Jiri Hietanen
What is a best possible IFC – what are its characteristics? You will often hear arguments in favor of always having all up-to-date data, from all stakeholders at all stages of the lifecycle of a property. But what about the opposite approach? Let’s start by thinking about a single, well defined information exchange, like architectural design to quantity take-off. This raises for example the question ‘what is the best possible IFC that an architect can deliver to a quantity surveyor?’
- A best possible IFC contains only relevant information. In any information exchange the receiver needs a certain set of information. If the exchange contains more information than this, the extra information will simply be ignored by the receiver. And even worse, the unnecessary information can cause unnecessary technical problems, ranging from bloated file sizes to a complete failure to use the information.
- A best possible IFC contains only reliable information. The exchanged information loses a lot of its value if it cannot be trusted by the receiver. Mixing reliable and unreliable information in the same exchange also corrodes the trust in information that would actually be reliable. Project specific agreements, like naming conventions should be respected, there should be no default values and the information should accurately represent the current state of the design.
- A best possible IFC is normalized (well-structured). As a standard IFC is quite flexible and there are usually many different ways to encode the same information in an IFC model. On the other hand, each exchange has a receiving application and the exchange has no real value if the receiving application cannot successfully import the exchanged IFC model. This means that the requirement for the detailed structure of the IFC exchange is ultimately defined by the receiving application.
When we put all this together we can conclude that there is no universal best possible IFC. The definition is always context dependent. In the context of one exchange the best possible IFC contains only the information needed by the receiver, that information is reliable and the exchanged IFC model can successfully be imported into the receiving application. It is not any more complicated than this.
In the next post I will write about why we should strive towards the best possible IFC.