What is it good for?
Absolutely nothing, say it, say it, say it
Oh IFC, is an enemy to all mankind
The thought of IFC blows my mind
IFC has caused unrest within the AEC community
Frustration, then dissatisfaction, who wants to fail?"
with apologies to EDWIN STARR
Looking through blog posts and discussion groups there seems to be a lot of dissatisfaction with IFC. Some samples:
"It can (if done properly) be used for a static as-built record Information, but even when used for this purpose validation of the data is critical."
"Data Loss IFC has a horrible habit of losing information or dropping data when exporting from its native format."
" IFC is that it doesn't currently support all the clever time saving parametric stuff that we expect from BIM components these days. IFC is all about the geometry and data and upon export it normally dumbs it down to just that."
" The biggest barrier in my opinion is that no matter how good IFC becomes, it will never be as good or have the functionality as the native BIM package it was created in. "
"It annoys me when I see new BIM users (most of the time without software experience) shouting about how we must all adopt IFC & openBIM now-today, because on the outside it looks like a perfect solution, when in fact its actually a load of work arounds."
So what is going on? We keep getting lectured by BIM evanglists about how wonderful IFC is. These same evanglists are busily lobbying governments and large corporations to mandate IFC deliverables. There seems to be a lot of claims about what IFC can do, but little on what it can't do. I don't put myself forward as an expert on IFC and welcome comments that prove me wrong, but I thought I would share my investigation into IFC.
WHAT IS IFC
I won't go into a lot of detail of what IFC is, but paraphrased from wikipedia:"IFC is an object-based file format with a data model developed by buildingSMART to facilitate interoperability in the architecture, engineering and construction (AEC) industry, and is a commonly used format for BIM. The IFC model specification is open source and is an official International Standard ISO 16739:2013.
For more information look at the buildingSMART web site, and as an example of their view of what Revit users need to know.
PROBLEMS WITH IFC
EXCHANGE FORMAT DOES NOT EQUAL OPEN FORMAT
One of the things many people don't seem to appreciate is that IFC (and by extension COBie) is an exchange format. It is not a common format, like open source formats (DOCX, JPEG, XVID, etc.), or common proprietary formats (DWG, PDF etc.)IFC is designed to be a format that only exchanges data between other formats. When you import IFC into a software it gets converted into that software's format.
Software that can open IFC files directly are IFC viewers, they can't actually edit the IFC file.
It is a good idea, an agnostic data format.
But what it means is that there are two points of possible error creation - when the IFC is exported, and when it is imported.
With common formats there is only one - at import when using the software's format, or at export when using different software.
So although an exchange format like IFC may be theoretically more efficient across an industry, in practical terms for individuals it is not. To get a specific result it is easier (and quicker) to write one set of code in one software than to write two sets of code in two separate softwares.
FUNCTIONALITY
IFC doesn't seem to capture all the functionality of BIM authoring softwares. For example it contains size dimensions, but doesn't know which geometric entities these dimensions control. So it can't transfer working parametric objects.Effectively an IFC import creates static objects, no longer editable.
This behaviour perpetuates problems that BIM is supposed to overcome. If size parameters are exchanged and are editable, but the geometry doesn't change with those edits, there is potential for situations where the scheduled size of equipment doesn't match its geometric size. Which makes spatial planning and clash detection unreliable.
BUILDINGS ONLY, NOT COMPONENTS
Although you can create an IFC file of a building that contains components, you can't create an IFC file of only one component. The file is effectively a building with one component in it.I find this surprising. You would think an open format for distributing components would be high on the priority list.
There are a number of initiatives to create BIM component standards, like the UK NBS National BIM Library. But they have had to include Revit files due to the lack of functionality of IFC files.
That said, it should be entirely possible for a component IFC file schema to be created, and I believe buildingSMART is looking at this. See this presentation.
But currently IFC is not a suitable format for components.
ARCHIVAL QUALITY
IFC is pushed as an archival format. The argument being that the constant upgrades to proprietary software formats means any files retained now will be unreadable in the future. Whilst IFC, being a published standard, will always be readable.But as explained above IFC is not a software format. It is an exchange format that requires other softwares to create and read it. Therefore it relies on proprietary softwares to maintain the ability to read older IFC formats. Which seems to me no different from relying on those proprietary softwares to maintain the ability to read their own formats. One could argue it is more likely they will do this for their own format than for an external format they derive no income from.
There is a mitigating factor though, the fact that IFC rarely gets updated means proprietary softwares don't have very many versions of IFC converters to maintain.
But the fact remains the problems of archival storage of digital data are NOT solved by using IFC.
AS-BUILT and FUTURE WORKS
IFC is pretty much useless for As-Built BIM that will be used as a resource for future changes to a building. As an exchange format IFC can't be directly edited. And most data that handles the original authoring software functionality has been lost in the exchange. So at best IFC can only be used as a static background in an authoring software with editing capability restricted to deleting parts.Even if you import this static model there is the problem of loss of fidelity when an IFC file is imported into an authoring software. Without painstakingly checking every element it is not known whether everything from the IFC model has been replicated.
Then once the changes have been made in the authoring software, the export back to IFC is also problematic. If only part of the building has been changed how do you integrate that into the original IFC model? If the whole building is exported back replacing the original IFC model how do you deal with the time lag that means differences in data content, or the problems that arise if the IFC model is linked to a third party database.
COMPLEXITY
I have looked through the IFC and COBie descriptions, and I'm sure if I tried really hard I could understand it. But I don't want to try, I've got more important things to learn that are actually relevant to my area of expertise. I'm an architect, not a computer programmer. I'm sure most people in the AEC industry feel the same way.Just look at what IFC stands for - Industry Foundation Classes. What does that even mean? (when I talk about IFC to a project team they ALWAYS get confused and think IFC is "Issued for Construction").
Does this really matter? IFC is a software standard, not a human process standard. In theory us users should be shielded from the inner workings of IFC by the software we use. But the reality is we end up having to delve into IFC because the softwares don't provide what is required for us to do our work. We are also getting owners with specific IFC deliverables, that describe these deliverables in IFC terms.
DOES IFC ACTUALLY WORK IN THE REAL WORLD
This issue is one I can't answer because I am not a computer programmer. All I can go on is what I read in discussions and blogs by people who know a lot more than I do. And I have to say what I have read is concerning, some of the issues seeming to be rather fundamental.It seems some that have tried to use IFC are, if not exactly giving up, accepting IFC limitations.
Jon Mirtschin at GeometryGym has been using IFC as an exchange method to transfer data generated in Rhino by Grasshopper to BIM authoring softwares. I saw him speak at an IFC 4 launch, and what he does is amazing, and he is a strong IFC supporter. But he admitted he was having problems with IFC and has started to write code to import directly into Revit to overcome them. It seems you can only go so far with IFC.
On another front Bentley have announced they are developing an "RFA interpreter" that can import rfa files (Revit's component file format) into their BIM product.
But even given IFC's problems, and despite my scepticism, IFC is actually being used around the world.
WHAT IS IFC USEFUL FOR?
Lets not throw out the baby with the bathwater. Underneath the practical limitations there is a fundamentally good idea. The fact is it is not, and never will be, the panacea it is claimed to be. But IFC must be useful for something.ANALYSIS
Generally a BIM model used for analysis purposes doesn't require the whole model. Structural analysis only requires the structural components, thermal analysis only requires spaces, zones and envelope data. Some analysis software only requires parts of a building, or does the analysis one part at a time (e.g. floor by floor). Because IFC is an open format receivers of IFC files can break up them up without requiring the authoring software. Their analysis software may do it, or it can be done manually with third party software like simpleBIM at datacubist.com.As IFC is usually simpler than the format of the authoring software so analysis softwares require less code to get the information they require, and it is easier for them to manipulate that data before importing it. This issue is becoming more important as cloud computing is taken up for analysis.
If all an analysis software does is the analysis then a static model like IFC is sufficient, but if you want to modify the model based on the results of the analysis IFC won't work for you.
So if you want to provide your model to some-one else for them to do an analysis IFC is a good idea, but if you want to do an analysis yourself that will result in changes to your model your authoring software is better.
FACILITIES MANAGEMENT
A Facilities Management system does not need the ability to easily modify a building's geometry. The geometry is mainly there as a navigation tool for the data the system holds. In fact you don't want people to accidentally move fixed elements around (which can happen in authoring softwares).You also don't want an unnecessarily complex file format that can do more than you need.
So using IFC for FM makes sense. It is a simple format that has its geometry locked down. It also makes sense, in theory, for FM software houses to utilise IFC as they can then import data from multiple sources. I say in theory because they then become victim to the quality of IFC those sources create.
Of course if you need to make changes to the building's geometry, like add a door or change a wall, you will need to do that with a different software and try and integrate that change back into your IFC model. I'm not aware of a way to do this, but I suggest you make sure you have a robust, tested, process before committing to a reliance on IFC for FM.
COORDINATION
Current specialized clash detection software work by importing static models. They don't attempt, or have the capability to, alter imported geometry. Therefore IFC is a prime candidate for these types of software.The ideal situation would be to have the ability to alter model geometry to over come clashes whilst doing the clash detection. But currently authoring softwares are not good enough at clash detection to make this practical. And then there is the issue of who makes the changes. Should the BIM Manager, who is not a structural engineer, have the ability to make changes to the structural model?
So at present, until authoring software improves and the responsibility problems are resolved, IFC is fine for clash detection and coordination.
WHAT IS IFC NOT USEFUL FOR
AS-BUILT FOR FUTURE WORK
IFC is not an authoring software format and in its current form is too limited to be really useful for making changes to an existing building.However the pain associated with dealing with IFC could be alleviated by careful construction of the IFC model. For example by breaking it down into linked sub-models. If it is contemplated that IFC be used for As-built, as a minimum the process for updating building geometry should be established before hand-over to FM.
EXCHANGES BETWEEN AUTHORING SOFTWARES
IFC's inability the keep the data authoring softwares rely on to make them useful means IFC is a bad choice for model exchange. If all you require is a static background IFC may be usable, but only if you are confident all objects survive the double transfer - firstly from the originating software and secondly into the receiving software.The other problem is even if you get the IFC into your authoring software the control you have over it (visibility, display, data content) may be limited.
COMPONENTS
IFC simply doesn't have the ability to contain the parametric properties we expect from BIM components. Maybe one day it will, but for now don't waste your time.SHOULD IFC BE SUPPORTED?
When ever I bring up the shortcomings of IFC in public I get berated for not getting involved. It is open source, they say, anyone can contribute they say. But I'm an architect, I don't have the expertise to solve any of these problems. My contribution is limited to bringing up the short-comings of IFC. And I don't see how bringing up these issues in a closed forum could possibly be more effective than doing it publicly.But should we practitioners support IFC? I believe we should. It is fundamentally a good idea.
Certainly volunteer to buildingSMART if you think you can contribute directly.
But if you want to contribute some of your time for free, my view is the most effective thing you can do is give IFC a try. Test it out, experiment with it.
And share you experiences. If things don't work bitch and complain, if they do heap praise on it.
IFC RESOURCES
IFC DISCUSSIONLinkedin:
http://www.linkedin.com/groups/Industry-Foundation-Classes-IFC-3690870
IFC VIEWERS
Solbri:
viewer: http://www.solibri.com.au/other-products/solibri-model-viewer
optimizer: http://www.solibri.com.au/other-products/solibri-ifc-optimizer
Tekla:
http://www.teklabimsight.com/downloads.jsp
List of IFC software:
http://www.ifcwiki.org/index.php/Free_Software
IFC / REVIT
Open source Revit to IFC Exporter:
http://sourceforge.net/projects/ifcexporter/files/
IFC to Revit importers (both are optimized for services and/or structure):
GeometryGym: http://geometrygym.wikidot.com/downloads
ArchiCAD: http://www.graphisoft.com/downloads/interoperability.html
Tekla (optimized for structure):
http://www.tekla.com/international/solutions/building-construction/Pages/export-revit-tekla-structures.aspx
IFC SOFTWARE
Software like simpleBIM (http://datacubist.com) can clean up IFC files.
EXAMPLES OF IFC USE:
Geometry Gym:
http://geometrygym.blogspot.com.au
http://geometrygym.wikidot.com
NBS [UK] Revit Plug-in:
http://www.thenbs.com/products/nbsplugins/index.asp
|
Bored with BIM? Need a present for that special woman in your life? The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, architecture and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon, Google Books, Kobo and iBooks. |
Hi Antony,
ReplyDeleteI agree with you that COBie is a pain in the a*s but about IFC itself I have been using it for exchange between software like Revit Structure-Tekla Structure or Revit Structure-SDS/2 and it works fine. At least we can save a day or more depending on the size of the project to build the framing stick in the detailling software. As a manufacturer we receive a lot of models from structural engineering firms and IFC it the format we use for complex stadiums data exchange. You can track design changes with color coded views based of IFC GUIDs in Tekla for instance for fastrack projects with design and detailling teams working together and its very helpfull. I understand many of your concerns from an architect point of view but as a Structural designer/manufacturer we simply cant live without IFC !
Carl, good to see an example of IFC success. It seems the structural area is where IFC is being found most useful. I suspect this is because structure is a bit simpler than architecture, and possibly services. Hopefully this indicates IFC is workable, just needs more development.
DeleteFrom your description I assume your workflow is one-way. Not really data "exchange". Which is fine, it does what you need. I just object to IFC promotion as a solution for full data exchange, when it is more of a standardized export format.
Hello Antony -
ReplyDeleteI liked your framework for evaluating IFC as an ISO Standard and am surprised that you have not received more comments so far. A number of others have presented alternatives to IFC such as BIMxml.
Will you be continuing this thread in future blogs?
As a side note, have you explored IFC 4?
Regards,
Bob
Bob, I've only been to a presentation of IFC 4. There are certainly improvements, the ability to utilize NURBS will certainly make IFC imports look better. It took 6 years for IFC 4 to be released, and it looks to me like it has caught up to where BIM authoring softwares were in 2004.
DeleteBut no, I haven't explored it because I'm not a computer programmer. IFC is a format, not software, so I need software that utilizes IFC 4. And from the talk I went to it seems it will be a few years before IFC is integrated into enough softwares to make it practical. Remember, both the importers and exporters of each software in a workflow will need to deal with IFC 4.
Hi Antony, I agree that it will be some time before IFC 4 becomes the new standard for IFC. However, with our latest release of the open source exporter for Revit 2014, we've taken the first step and now export "basic" IFC 4 files. I say "basic" because we don't yet take advantage of much of the new IFC 4 functionality, but we've taken a big first step in that direction, and plan to continue adding IFC 4-specific functionality. When the next major application is ready for IFC 4, there will be Revit IFC files waiting for them to import.
DeleteAs usual a fantastic post Antony. I like your closing paragraph best that lets people know how to influence IFC instead of totally disregarding it. Feedback is needed. Now if only the Open BIM people would get off their high horse long enough to listen to it, something might actually change.
ReplyDeleteA lot of your points are dead-on for the general user. I sometimes think that those that work on IFC don't think about the general user at all. The best thing you wrote was "In theory us users should be shielded from the inner workings of IFC by the software we use". Until that is the case I will not consider IFC to be a success.
I'm afraid I will have to be the one to disagree...
ReplyDelete1. The difference between an common format and exchange format is non-existant. They are not comparable. I can have both open and closed exchange formats as well as open and closed common formats. And, more important, how does one define a building in an "exchange format" differently from an "common format"?
As for the direct use of IFC: the Vectorworks format is a direct derivement from IFC, practically the same. If I'm not mistaking you can open and save IFC's directly. The simple fact that there is no direct IFC authoring tool does not mean that it cannot be done. It only means that there apparently is no business case for it.
And then there is the two points of possible error. Well, show me one direct exchange workflow that does NOT use an intermediate format (usually the STEP format which is the predecessor of IFC, or some other xml language) and I would be willing to buy this. But as far as I know, almost every direct translator uses a "middle-man" in the process.
The problem with translating IFC's is more that it is a generic format. Which all software interprets differently. Which leads to errors when you try to translate on a certain level of detail. Think of it as Google Translate. Try this: type in a long, complex piece of text in Google Translate. Then translate to German and back to english. Same text to Chinese and back. Same text to Swahili and back. You will get different outcomes for each language. What went wrong? Each translation interprets the text differently. Which leads to errors and different outcomes. Direct translators don’t have this issue, that’s why they work better (even when based on IFC). But they also defeat the purpose of IFC: having the freedom of choosing your own authoring software.
2. About the functionality: again, disagree. Go to the NBS webpage, download some walls and import in Revit. Trust me, they're converted to fully parametric Revit components.
And, as Jon once old me, it IS possible to create a parametric IFC (like Windows and such). The building blocks are there. Yet nobody has done this, but again, this is not proof that it's not possible. It's just proof that it's not a viable business opportunity. Or that it's difficult and leads to other errors that are not yet solved.
3. The buildings vs components: agree on that one. But it falls short on the NBS example. The Revit/Archicad/DWG components are not there because the IFC wouldn't be parametric or fall short other wise, it's there because the NBS has a different opinion about an open standard: they came to the conclusion that "open" does not mean "readable". It means "available" for all software formats. And availability can also be guaranteed by having the component in all kinds of different formats using the same standard of definition.
ReplyDelete4. Archival. Again I disagree with the line of reasoning. The bottom line is that even when my propriety format no longer supports an ancient IFC version I can still write an updater based on the published scheme that translates my current version in a newer, still supported version. I can still write an authoring tool for the IFC file. With enough money I can always use the IFC. I cannot do the same for a propriety format.
5. As-built and future works. Do not agree. Like I said before, it IS possible to maintain parametric relationships in IFC. It IS possible to create an IFC-based modeller. It's just not done yet. So in practical terms you're right on this one, but that's an implementation issue, NOT an inherent flaw of the format.
As for aggregrating IFC's, that's basic functionality for 80% of the IFC-based software tools (Solibri, dRofus, SimpleBIM, even autodesk FabReview or Navisworks can do that)
As for differentiating between phases: as long as it's based on parametric values phases can always be retrieved.
6. Complexity. I would have applauded and bowed down if this was named "lack of documentation". Off course it's complex. A building is complex, so any way of describing a building is complex. But what we need is a documentation in layman's terms. That I can only agree to.
Anyway, that's my humble opinion. There are loads of issues with IFC but from where I stand these are not the main ones.
Thanks for your considered comments Martijn, it is great to hear from some-one with an enthusiasm for IFC. I don't disagree with a lot of what you say, the differences are more about emphasis.
Delete1. It is true on the surface there is no difference between an exchange format and a software format, both are just structured data. The difference is one of intent. A software format is structured to suit the functionality of the software, an exchange format is structured to communicate data, not support functionality. For example IFC doesn't support parametric geometry because it is not required for the uses IFC is targeting, but this functionality is incredibly useful for productivity, so is important to the authors of BIM.
As an aside I think Vectorworks is a bit older than IFC, although it is entirely possible the IFC schema has been used to add BIM functionality to what is essentially a 3D drawing package. A good idea, some-one should do it to SketchUp.
I don't know what you mean when you say all exporters (or importers) require an intermediate format. If you write a DWG exporter in Revit you write code that writes to the DWG format, if you write an importer you write code that reads DWG format. You don't need an intermediate format. You might use code libraries, but that is different.
I agree that IFC is like Google Translate. And that is the problem. IFC is a totally artificial language written by a single organization, it shouldn't have these problems.
2. Simple IFC walls work to a large degree in Revit (and in most other software). But walls from Revit that contain different materials on a face, or have modeled skirtings, cornices, dado etc don't. Because IFC can only contain simple data. Start getting into complex objects like curtain walls and IFC just can't do it, no matter what you do. As I said in my post, the reality is people are having to write direct exporters and importers to transfer this more complex data.
But I agree this doesn't kill IFC, it just needs improving to make it a more practical proposal.
3. The fact remains IFC doesn't capture binding of parameters to geometry. That doesn't mean it can't or won't happen in the future. There are buildingSMART proposals to do this. But my focus is the current limitations of IFC, what we can do now, not in some distance future.
4. You are correct about the advantages of IFC being human readable and documentation being freely available. My point is IFC is being sold as if this alone is enough to ensure all future software will be able to read all previous formats of IFC. But, as you say, it requires the services of software programmers to write code, with cost and time implications. Which means although possible, it may not actually be a practical proposition.
5. I don't know if you have ever tried to edit an IFC file provided by some-one else, but I can tell you it is not a practical proposition in any of the proper BIM software. Sure you could use simple pseudo BIM software but productivity goes through the floor. And that is another of my points about the limitations of IFC. If you are not careful it can serious diminish productivity - and for what? To deliver information in a particular format that could be in any case delivered using other methods.
6. I don't think it is a matter of IFC documentation. AEC professionals shouldn't be expected to become computer programmers just to deliver one part of their deliverables. But this is not a fault of IFC, it is lack of software tools that make use of IFC.
It is not my intention to trash IFC. But lets be realistic, it is only one tool of many we can use to create our deliverables. If we are going to make use of IFC we need to know its current strengths and weaknesses so we can assess in what situations it is appropriate. Only talking about its future potential, or its strengths, is not helpful to those of us who will have to deal with it on a day to day basis.
Hi Anthony,
DeleteJust to add some of my thoughts. You keep saying "IFC can't do" when in reality (in my opinion) you often should be saying "XXX implementation of IFC can't do" (insert your nominated BIM vendor).
2. IFC can convey features of walls etc, refer http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcsharedbldgelements/lexical/ifccoveringtypeenum.htm and you'll see a covering has explicit nomination as a skirting, there are also feature items such as http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifcproductextension/lexical/ifcprojectionelement.htm
3. It is possible to have an IFC file with a "library" project (http://www.buildingsmart-tech.org/ifc/IFC2x4/rc4/html/schema/ifckernel/lexical/ifcproject.htm doesn't seem to mandate a root building or site to be defined). I agree, this is an area with scope for improvement for IFC. Some of the object types with parametric dimensions (such as windows and doors) have dimensions stored on the object (rather than the type) although I have been preparing some example files using property sets to define this.
5. I've recently been enabling scheduling within IFC of projects which is really powerful, and it is possible to assign products to tasks so phasing is available (ie you can set a previous construction task, and new tasks such as demolition and construction). I'm yet to see anyone other than Constructivity to implement this aspect of IFC to date.
I really encourage blog posts and industry discussion about what IFC is capable of and how it can be used to improve our industry. I totally understand the frustration to date, but if we don't highlight where present implementations are failing and motivate those responsible to improve, the situation is never going to improve.
I certainly hold high hopes for more improvements to IFC technical capability and hope to contribute to this process. The more that do the same the better the result that will be achieved.
Hi Anthony,
ReplyDeleteThanks for your reply. Usually these kind of debates end up in a flame war with no exchange of arguments whatsoever.
1. Sorry, still don't see the difference. The Revit database does not contain functionality, the software does. Functionality loss with the use of IFC is not because of the format itself, it's because the import/translation of an IFC is incomplete. If an IFC import would be 100% accurate, the resulting model should be 100% useable.
2. Funny you use this example. Let's look at it closer: how does one get a single wall in Revit to hold multiple surface materials? By using Parts (which isn't properly implemented YET) or by using Divide Surface + Paint. Which, imho, is an ugly hack that you will get slapped on the wrist for by Revit if you don't watch your steps. But more importantly: it's not a "true" object definition in Revit. It screws up the internal database (do a wall schedule and find the parts you painted), so how can you really expect IFC to understand it?
As for the modelled skirtings: they CAN be exported properly, whether you modelled them as a Wall Sweep, In Place Family or what-not.
However, and this is my main point: people think IFC should work as printing to PDF or plotting a drawing or even exporting to dwg. Those come out right, without a lot of hassle right? But go back in time to the last time you worked on your project template. Everything you did there (set up Line Weights, Object Styles, and so on) was aimed at getting those to export properly. You did NOT just push the button on the ootb settings (or maybe you did once, and was scared out of your mind). Why should you be able to do that for IFC?
3. Again, as Jon said: it's there. It is already possible to store parametric information in an IFC. Differently then in Revit, true. And it sure as hell needs to be better. But it's there, and doable. If you have the funds to implement it yourself since none of the software vendors have.
4. Agreed, entirely not practical. But when you're supposed to be able to reproduce your BIM models until eternity, no matter what, a very important difference nonetheless. If you're not, well then it's no part of the equition.
5. Yes, once, just for the fun. And I agree: if you need to edit the model, then IFC is not your friend. BUT that's not the same as data-distribution. CHANGING data is not the same as USING data. It's active vs passive. It's a whole different ballgame. I agree that it will be years and years before that's even remotely possible. But that's not why I use IFC. I use IFC to USE data. I want to know where the structural columns and beams are, so I can place my coverings. I do not want to change the actual column (and my SE would sue me if I did).
The scope of your intents when sending people a BIM model is very important. IFC is only useable for a part of that range.
6. Well, I disagree.
I spent the last 12 months investigating IFC and it's merits. Before that time, I generally had the same point of view you expressed here. In those 12 months (and with a lot of frustration and agony) I came to realise that one an solve 80% of the daily problems with IFC import and export by just treating it the same as PDF, dwg or hardcopy: as a part of your project template that needs setting up.
Now why did it take 12 months? basically because the documentation sucks. Try learning Revit with just the API and no User Interface to work with.
If you look at IFC as something you need to set up in your template, then the documentation on how it works should be there. Not talking about coding or anything. Just talking about the simple possibilities you have when using the ootb Revit ex- and importers.
Do you know what the IFC export/import mapping tables are? Ever tried to edit them? what IFC Class should the Air Terminal be mapped to? IfcAirTerminalType or IfcAirTerminalBoxType? How does one get an IfcChiller as an distuingishable element in Revit?
Imvho it's all about documentation...
Martijn,
DeleteI like your metaphor of printing to PDF and exporting to DWG for IFC. That is how I see IFC. A way of providing a sub-set of data for a particular purpose. PDF for printing, DWG for 2D editing, IFC for BIM data tied to a rough geometric representation.
My point about IFC not being an authoring format is that it doesn't contain data to support functionality specific to a particular software. And nor should it. To expect one format to contain all possible requirements for all possible softwares is clearly unrealistic.
But there is this perception going around that softwares that don't interact nicely with IFC must be deficient in some fundamental way. The reality is the softwares with the most authoring functionality have the most trouble interacting with IFC because IFC doesn't capture the data they require for that functionality. And as I said above, nor should it, but we need to be realistic about what IFC can and can't do.
I think you have hit the nail on the head - IFC is NOT an authoring format, it is purely for the exchange of specific data. The range of that data may expand over time as IFC improves, but it will always be a sub-set of all that an authoring software has.
Good on you for spending the time learning IFC, but I don't believe AEC professionals should have to learn computer programming languages, whether IFC or a software API, to do the job they are paid to do. I spent 15 years writing thousands of lines of code to make AutoCAD productive. One of the reasons I was attracted to Revit was because the originators also believed that and didn't build in an API.
But that is not to say AEC professionals shouldn't BUY software. So I agree, there needs to be better documentation of IFC so programming professionals can offer me and my colleagues practical software that utilizes IFC.
Antony,
ReplyDeletebut it CAN support all the data you want. The Dutch Revit User Group is currently working on a second addition to the ADSK Open Source Exporter to add the ability to create custom parameters when exporting to IFC. That's my whole point: it IS possible, but not yet done. I.o.w.: maybe the day IFC can carry through all information you could ever wish for is closer then you think (although getting it in the IFC is easier then getting it back out).
Having said that: I fully agree to the fact that IFC should only carry through information needed by the recipient. Nothing more and nothing less. Like I WANT to know the pressure loss in a duct when I receive an IFC from the MEP-guy.
As for me learning IFC, I may have misled you there. I know NOTHING about the actual code. Nor do I want to. Translated in the Realm of Revit, cause that is what we know best, this is what I did try to find out:
- What categories are there? Problem here: I had to manually google "IFC, Air terminal" to find the class IfcAirTerminalType. (right now there's a real handy webpage that lists them all together, but it wasn't there last year)
- Which can I use to create geometric objects? And which are there as a part of the "coding infrastructure" and not useable for the working class.
- What properties do they hold?
- How do I get Revit properties to IFC (WITHOUT coding). We ended up writing code for it because the ootb functionality was utter crap. But that's a different story. And I didn't do the coding...
- How is an element defined and what (modelling) constraints are there?
- And so on...
So basic stuff, that you will get in your first 2 days of basic Revit training. And that should be the case for IFC too: it shouldn't take more then a week to get the hang of it. But I do think everyone should know this. After all, you also know which settings to use on your PDF-printer. Or when exporting to dwg...