tag:blogger.com,1999:blog-5634085675780254011.post1738585361776716559..comments2024-03-26T02:30:27.201+11:00Comments on practical BIM: IFC, What is it good for?Antony McPheehttp://www.blogger.com/profile/15366532205983073622noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-5634085675780254011.post-36653599529552382802013-07-25T06:56:29.401+10:002013-07-25T06:56:29.401+10:00Antony,
but it CAN support all the data you want....Antony,<br /><br />but 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).<br /><br />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.<br /><br />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:<br /><br />- 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)<br />- 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.<br />- What properties do they hold?<br />- 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...<br />- How is an element defined and what (modelling) constraints are there?<br />- And so on...<br /><br />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...Anonymoushttps://www.blogger.com/profile/06481611029926317988noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-28733672632392870362013-07-24T21:26:06.301+10:002013-07-24T21:26:06.301+10:00Martijn,
I like your metaphor of printing to PDF ...Martijn,<br /><br />I 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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. <br />Antony McPheehttps://www.blogger.com/profile/15366532205983073622noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-32816155517359552312013-07-23T06:50:22.457+10:002013-07-23T06:50:22.457+10:00Hi Anthony,
Thanks for your reply. Usually these ...Hi Anthony,<br /><br />Thanks for your reply. Usually these kind of debates end up in a flame war with no exchange of arguments whatsoever.<br /><br />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.<br /><br />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?<br />As for the modelled skirtings: they CAN be exported properly, whether you modelled them as a Wall Sweep, In Place Family or what-not. <br /><br />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?<br /><br />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.<br /><br />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.<br /><br />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). <br />The scope of your intents when sending people a BIM model is very important. IFC is only useable for a part of that range.<br /><br />6. Well, I disagree. <br />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.<br />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. <br />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.<br />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? <br />Imvho it's all about documentation...<br /><br />Anonymoushttps://www.blogger.com/profile/06481611029926317988noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-17487488512215994322013-07-23T04:05:46.929+10:002013-07-23T04:05:46.929+10:00Hi Anthony,
Just to add some of my thoughts. You...Hi Anthony,<br /><br />Just 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).<br /><br />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<br /><br />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.<br /><br />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.<br /><br />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. <br /><br />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.Jon Mirtschinhttps://www.blogger.com/profile/09698974959593709039noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-87600163358048000972013-07-20T13:52:57.723+10:002013-07-20T13:52:57.723+10:00Thanks for your considered comments Martijn, it is...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.<br /><br />1. 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.<br />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.<br />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.<br />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.<br /><br />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.<br />But I agree this doesn't kill IFC, it just needs improving to make it a more practical proposal.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.Antony McPheehttps://www.blogger.com/profile/15366532205983073622noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-69511097462375161602013-07-18T10:13:23.255+10:002013-07-18T10:13:23.255+10:00Hi Antony, I agree that it will be some time befor...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.Anonymoushttps://www.blogger.com/profile/12777597813553979490noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-46407067428740214562013-07-18T09:41:40.972+10:002013-07-18T09:41:40.972+10:003. The buildings vs components: agree on that one....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.<br />4. 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.<br /><br />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.<br />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)<br />As for differentiating between phases: as long as it's based on parametric values phases can always be retrieved.<br /><br />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.<br /><br />Anyway, that's my humble opinion. There are loads of issues with IFC but from where I stand these are not the main ones.<br />Anonymoushttps://www.blogger.com/profile/06481611029926317988noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-56498126986561192552013-07-18T09:41:09.333+10:002013-07-18T09:41:09.333+10:00I'm afraid I will have to be the one to disagr...I'm afraid I will have to be the one to disagree...<br /><br />1. 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"?<br />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.<br />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. <br />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.<br />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. <br />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. <br />Anonymoushttps://www.blogger.com/profile/06481611029926317988noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-37813956427190870902013-07-03T10:44:39.871+10:002013-07-03T10:44:39.871+10:00Carl, good to see an example of IFC success. It se...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.<br />From 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. <br />Antony McPheehttps://www.blogger.com/profile/15366532205983073622noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-23165488516847593852013-07-03T10:34:32.487+10:002013-07-03T10:34:32.487+10:00Bob, I've only been to a presentation of IFC 4...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.<br />But 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. <br />Antony McPheehttps://www.blogger.com/profile/15366532205983073622noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-33154101687076580662013-07-03T04:49:39.454+10:002013-07-03T04:49:39.454+10:00As usual a fantastic post Antony. I like your clo...As 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.<br /><br />A 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.Anonymoushttps://www.blogger.com/profile/04684129047550786134noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-62568628125368575672013-07-01T06:28:39.790+10:002013-07-01T06:28:39.790+10:00Hello Antony -
I liked your framework for evaluat...Hello Antony -<br /><br />I 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. <br /> Will you be continuing this thread in future blogs?<br /><br />As a side note, have you explored IFC 4?<br /><br />Regards,<br /><br />BobBobhttps://www.blogger.com/profile/16989161589989764000noreply@blogger.comtag:blogger.com,1999:blog-5634085675780254011.post-60974642954234065432013-06-30T13:17:33.673+10:002013-06-30T13:17:33.673+10:00Hi Antony,
I agree with you that COBie is a pain ...Hi Antony,<br /><br />I 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 Veillettehttps://www.blogger.com/profile/07360941936321305836noreply@blogger.com