The IFC Building Model: A Look Under the Hood

[beegee]

An Article (www.aecbytes.com/feature/IFCmodel.htm) worth the read....


What exactly is the IFC (Industry Foundation Classes)? Most professionals simply know of it as a data model developed by the IAI (International Alliance for Interoperability) to facilitate interoperability in the building industry. While technical information about the IFC building model is documented in detail and is readily available for software developers who need to work with it, there is practically no information for the average AEC practitioner who wants to have a better understanding of the IFC model. The intent of this article is to address this shortfall. It is not about interoperability or data integration per se; rather, it is focused on providing a broad overview of the IFC model without delving too deeply into its technicalities.

[Wes Macaulay]

Whenever I think about one of these platform independent schemas I imagine how much work it must take to make it work. And the file size: unless there's some sort of compression or binary (non ASCII) method of storing the IFC/STEP/whatever data, you'd think the file would have to be huge! It's still an important task that all the CAD vendors should perform; that way my Revit building can be analysed in 3D by someone's structural modelling app and someone else's energy loss app, etc.

[bclarch]

I agree Wes. It looks to be a total can of worms once you start considering all that is involved. I can't see every piece of CAD software working with the same native data format. I think that best that we can hope for is an intelligent target standard (similar to the function that DXF serves in the 2D market) which every 3D software can export to and import from. Even then, there are always going to be translation issues. It is, however, a nice goal to shoot for. I hope that all of the software players get onboard.

[Scott D Davis]

Isn't ODBC an open format? Can't any database program read an ODBC compliant file? Answered my own questions with a quick google:

From http://www.webopedia.com/TERM/O/ODBC.html


ODBC: Short for Open DataBase Connectivity, a standard database access method developed by Microsoft Corporation. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver , between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant -- that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. Since version 2.0, the standard supports SAG SQL.

With this in mind, it seems that the IFC should work towards using this as a standard, rather thatn once again creating ANOTHER file format and trying to make it a 'standard'

[aaronrumple]

XML

That get's my vote.

[GuyR]

Isn't ODBC an open format?

Don't think it's open as in Opensource. It's also just a means for extracting data from a relational database on the windows platform. It's not a storage format.

Please revit team correct me if I'm wrong but the question is, is a relational database a good way to store a building model? My nderstanding is revit isn't a relational database more an object database like IFC. For instance how would you store a spline and a line in a relational DB. A line can be stored as 4 fields (x1,y1,x2,y2), a spline? So a relational model would require 2 tables to store these 2 elements.An object DB would store each as say a lineElement with the appropriate definition subclassing this.

IFC success is very dependent on Autodesk supporting the standard. ADT development of IFC is carried out by a German company not head office now. There has been talk about Revit supporting IFC. The question much like with API's is when.


XML,That get's my vote

There is a variant of the binary IFC called ifcXML.

Guy

[Scott D Davis]

There is a variant of the binary IFC called ifcXML.

Maybe we are seeing the beginning of this with the gbXML in 6.1.

[GuyR]

Maybe we are seeing the beginning of this with the gbXML in 6.1.

Yep, I think gbXML was based on the ifcXML schema. From the gbXML schema changelog:


2/12/01
Changing from X3D elements to ifcXML elements.

So hopefully this is the start.

Guy

[hand471037]

I would love to see some level of IFCxml done in Revit, if only to shut up the ArchiCAD people about how Revit doesn't have it. :twisted:

Serously tho, it would be great, however the IFC format is kinda twisted from what I understand, there are different values (like 1.1, 2.0, 2.?) that don't talk directly with each other, and certain products (like timberline) will use one and not the others.

I see much more value in IFC Xml, for then it would be easy for non-programmers to pick through the export data and write tools for doing neat things with it. I'vee been looking at the gbXML files, and wondering what I could do with that info...

Also, on ODBC, it's not open, but it can talk to open standard databases. It's more a 'conduit' than anything, so you could choose to have it communicate with an open source database IIRC and then be 'open'.

[FK]

Please revit team correct me if I'm wrong but the question is, is a relational database a good way to store a building model?

A pure relational database, hideous. Object-relational (i.e., everything on the market), maybe. Pure object-oriented, good.

Graphics/CAD are particularly suited to object-oriented data modeling. Translating these models into relational schemas is possible, but error-prone and painful. For example, inheritance is a pain to set up in a pure relational database. Note that you can always write an ODBC driver that would take SQL queries and omit all the object-oriented complexity.

XML is actually a hierarchical model.

[brendan.mac]

I see that this post is nigh on 2 years old now...

Have there been any further developments with Revit which brings it closer to IFC format?

I ask this because I recently attended a conference given by BuildingSMART (IAI) and they painted a very glowing picture of how bright the future of was in relation to taking BIM that one step further to interoperability and the doors that it could open.

Companies like CRC Construction Innovation were talking about LCADesing - an environmental assessment tool, DesignCheck - a compliance checker for Building Code standards and the disability code (Australian), An automated estimator and scheduler for 4D issues as well as Facility Management for the life of the building.

All of these are exciting prospects, but if the software is not yet compliant to allow big picture collaboration for the whole life of the project, what is the point?

ArchiCAD was mentioned as being a cutting edge performer in places line Finland but how about the rest of the world? Is Revit software keeping pace?

I would like to take my office into the next stage of design and development but I don't want to walk away with egg on my face because the software I am currently using doesn't want to know about IFC...

[ron.sanpedro]

Whenever I think about one of these platform independent schemas I imagine how much work it must take to make it work. And the file size: unless there's some sort of compression or binary (non ASCII) method of storing the IFC/STEP/whatever data, you'd think the file would have to be huge! It's still an important task that all the CAD vendors should perform; that way my Revit building can be analysed in 3D by someone's structural modelling app and someone else's energy loss app, etc.

What I have never understood is why a single file format is so important. To me it is like a layer standard. I don't care if everyone uses my layer standard, I just need all layer standards to be rational enough that I can convert between any two standards easily. I can work in my standard, then convert once before I ship something off. Then the other person gets to work in their standard.
I imagine I would be very happy with a 4 Gb XML Revit to Software X conversion matrix on a DVD. I pop it in, and tell Revit to convert to Software X format, and it reads from the XML and does the conversion. By morning I have I file I can send off, and that file is in native Software X format. By keeping everything in native format all applications are nice and quick, only the conversion is slow. I fear that a shared IFC file format is going to be like JAVA, equally slow on all platforms, and functionality limited to only that which is common to all platforms. It makes sense and works for little web based tools, or very very small and specific tools, but I don't know that it works for huge (functionality wise) tools like Revit.

Just my $0.02 anyway.

Gordon

[brendan.mac]

I fear that a shared IFC file format is going to be like JAVA, equally slow on all platforms, and functionality limited to only that which is common to all platforms.

It's a very good point. Functionality must be a priority. However, I'm not a software programmer.

Not even close.

I use tools and if they don't work, I don't what to know WHY they don't work... I just want them to work! If that tool doesn't do what I want. I'll go find one that does. I don't get attached to my tools because they are there to serve a purpose. As soon as they don't serve that purpose, they get binned.

I would like to know if interoperability is reality. Not just a pie-in-the-sky 'what if' discussion that is being tossed around.

If I want to co-ordinate with a structural engineer who works in BIM but doesn't use an AutoDESK product, can I do it?

If companies such as CRC are heading towards software that will make the BCA and AS processes easier to apply, based on an IFC principle, then surely I would be better off going with a 'tool' that will make this possible...

Can anyone tell me if this is where AutoDESK is going with Revit? Or is Revit going to be an 'also-ran' in line with other BIM products that haven't gone past the initial design ware software opportunities.

[Scott D Davis]

I see that this post is nigh on 2 years old now...

Have there been any further developments with Revit which brings it closer to IFC format?
Revit Building 9.0 is IFC 2x2 compliant....the highest level available in any software. IFC 2x3 has been released, but no software actually uses it yet.

[patricks]

wow, this is all extremely over my head.

Here in Mississippi we're cutting-edge enough just to be using Revit! :p

[brendan.mac]

Thanks Scott,

Just what I needed to know. Strangely enough, considering where the development is going, AutoDESK makes no mention of this anywhere in their website that I can find...

cheers.

[hand471037]

Just what I needed to know. Strangely enough, considering where the development is going, AutoDESK makes no mention of this anywhere in their website that I can find...

Revit can import and export IFC files. Building, Structure, and Systems all can, and if you're IFC savvy, Revit comes with an Shared Parameters file that will let you extend your own content to work within a particular IFC standard. IFC is pretty complex, and actually a little broken IMHO. It gets a lot of lip service, but personally I don't think it's going to really be that useful anytime soon. Sadly. When you dig into what others are doing with IFC it simply doesn't match up to all the marketing talk some software vendors devote to it. Yet. Maybe someday it will, and I hope it does...

They probably have a white paper on the Autodesk site about IFC. They do mention it in the 'features' if you look under Revit Building, not Revit Series...

[david.metcalf]

Just to see what is going on these days. I suggest you go to http://adt2006.inopso.com/
and download the trail based utility. From inside ADT, use appload to load the arx file and CUI to add the menu.

Export your Revit model to IFC, and in ADT run the tool from the pulldown and select the file you created earlier.

Once you have picked yourself up off the floor after laughing yourself sick, go back to drawing with Revit as if nothing happened.

IFC interoperability has a long way to get the level of "seamless".
http://aecnews.com/news/2005/11/29/1275.aspx

[robert.manna]

If you've got the money, one solution to interoperability, at least query and do conflict checking, is Navisworks. (http://www.navisworks.com/) We've had a couple of demos, and it certainly looks nice, but.... I haven't heard a price tag yet, rumors suggest it ain't cheap. It has a plug-in for Revit that makes use of the API to convert and pull the data in.


-R

[brendan.mac]

From reading the above posts, it doesn't seem that IFC is getting a glowing report. In fact, it seems that the concept is well behind where it should be.

Considering that interoperability seems to be the natural progressive step from BIM to service the construction and facility management industry (lets face it, we don't document these things for our own enjoyment...), and the AUGI don't support the direction it is heading, what advise do you guys have for those aiming to make it a reality?

Is there anyone out there who is actively working towards interoperability in their own practice or is it solely in the hands of the software developers?

[robert.manna]

I can say that there are members of the A/E community of the highlest levels of management who are pushing for software developers to assure interoprability. Obvisouly because these people have a fair amount of power behind them they can bring some pressure to bear. However it doesn't hurt to have as many people as possible making it clear to software vendors that they need to make sure their software "plays nice" (Sketch-Up's motto BTW). While I'm a Revit user, and firm supporter of Revit, I strongly feel that at the end of the day to assure development and creativity, and flexibility, we need multiple software packages that are competing, but at the same time can share. Given the nature of "BIM" this is of the utmost importance, as you've said, because it allows us to fully deliver our value, since the value we provide is no longer in documents, but Infomration, and Information Management/Coordination.

-R

[brendan.mac]

AutoDESK seems to have accepted IAI's (now known as 'buildingSMART') push for interoperacy as only a gesture, with Revit accepting limited Industry Foundation Classes (IFC) - currently at 2x2 (2004) with v.9 and with v.10 taking on full IFC 2x3 to be but only on the export of the model; not on import.

This in itself seems pointless.

I have heard that this is because AutoDESK controls more than a lion's share of the construction industry documentation world-wide, but only a small percentage of BIM software.

Previous threads have suggested that IFC is cumbersome and inefficient. If this is so, why are companies such as Bentley and Graphisoft are pushing hard to impliment IFC, and not suggesting an alternative for ISO to take into consideration?

All I have read seems to point to interoperability as being the future and 'saviour' of the construction industry, if this is truly so, I don't understand why AutoDESK is making what appears to be only a token effort with Revit.

Have I missed something here?

[hand471037]

AutoDESK seems to have accepted IAI's (now known as 'buildingSMART') push for interoperacy as only a gesture, with Revit accepting limited Industry Foundation Classes (IFC) - currently at 2x2 (2004) with v.9 and with v.10 taking on full IFC 2x3 to be but only on the export of the model; not on import.

I don't know if it's a gesture, actually. Look at the other CAD vendors. They too only support certain versions of IFC, and even then it's spotty at best.


This in itself seems pointless.

It sure does.


I have heard that this is because AutoDESK controls more than a lion's share of the construction industry documentation world-wide, but only a small percentage of BIM software.

I thin they added IFC's to Revit to shut up the ArchiCAD Marketing guys.


Previous threads have suggested that IFC is cumbersome and inefficient. If this is so, why are companies such as Bentley and Graphisoft are pushing hard to impliment IFC, and not suggesting an alternative for ISO to take into consideration?

Software companies do stupid things all the time. Why would this be different? Bently seriously believes that Triforma is a tool that's not too complex. And Graphisoft believes that GDI isn't hard. Does this sound rational? ;-)


All I have read seems to point to interoperability as being the future and 'saviour' of the construction industry, if this is truly so, I don't understand why AutoDESK is making what appears to be only a token effort with Revit.

You keep saying 'token' when as far as I know Revit is the only BIM system that native supports IFC import and export, without a plug-in, and is up to the current standard. How's that token?


Have I missed something here?

No. The issue is that IFC is a really complex standard with serious versioning problems.

Also there is the problem that our industry can't even agree upon door and partition standards, let alone have all the BIM systems name and classify things in a consistent enough way so that something like IFC could work.

For example: Revit's curtain walls are totally different from ADT's and ArchiCAD. Revit knows the difference between Furniture and Systems Furniture (office cubes), yet ADT doesn't, so what then?

I think Mario over at HOK (who's on the IAI committee) says it best about IFC that at this point it's like the telephone system, in that I can pick up the phone, and can call Finland, and the call with always go through and the system works. That's a big success. However, I'm speaking English, they are speaking Finnish, and so in the end we're only one step closer to communicating, we still have a long ways to go.

Go read about the Blis project, or the IAI's website about how they think people will work in the future with IFC, 'model servers' and all. No one's even close. It's a pipe dream. Right now, with Revit, a Architect, Structural Engineer, and HVAC Engineer can all work together in a truly collaborative BIM environment and share information at a pretty high level. They aren't doing this via IFC, simply because I think it was probably much faster and easier for Autodesk to do it with something in-house.

The closest thing I've seen in the real world to what IFC is promising are those jobs where the contractor went out and bought a copy of Navvisworks and installed it at the job site, and either the designers submitted a BIM model or had someone else, like View-by-View, build one. And even then all they had was collision detection between the models!

So don't believe everything you hear about IFC. Not that this takes away from it one iota, or that I don't also fully support it's growth and use. I certainly hope that someday it's a useful standard, so that I can swap my Revit models today with whatever superior BIM system comes tomorrow (from Google :D )...

[brendan.mac]

For example: Revit's curtain walls are totally different from ADT's and ArchiCAD. Revit knows the difference between Furniture and Systems Furniture (office cubes), yet ADT doesn't, so what then?)...

the classes (from my thinly grasped understand) from IFC are based on the ISO standards.
For example, a door, by definition, is a door. Whether it be a rollershutter, internal slider, solid fire door, or automatic glazed shopfront door. What separates it is how it is described. This description, if adopted across the board, shouldn't interfere with the application of the software and how it is classified as an object, should it?


I think Mario over at HOK (who's on the IAI committee) says it best about IFC that at this point it's like the telephone system, in that I can pick up the phone, and can call Finland, and the call with always go through and the system works. That's a big success. However, I'm speaking English, they are speaking Finnish, and so in the end we're only one step closer to communicating, we still have a long ways to go. )...

That's a very good point. But taking that one step further, does that mean that International software, such as what we use, needs to be adapted to allow for language? I know that I'm continually frustrated by imperial and metric differences, but does language come into writing a stream for description purposes?


Go read about the Blis project, or the IAI's website about how they think people will work in the future with IFC, 'model servers' and all. No one's even close. It's a pipe dream. Right now, with Revit, a Architect, Structural Engineer, and HVAC Engineer can all work together in a truly collaborative BIM environment and share information at a pretty high level. They aren't doing this via IFC, simply because I think it was probably much faster and easier for Autodesk to do it with something in-house.

The closest thing I've seen in the real world to what IFC is promising are those jobs where the contractor went out and bought a copy of Navvisworks and installed it at the job site, and either the designers submitted a BIM model or had someone else, like View-by-View, build one. And even then all they had was collision detection between the models!

I have had discussions with a gent here in Brisbane who works for a company called 'Activefacility'. [www.activefacility.com] They have developed a building information server for managing building data. This development means that the massive information required for the lifecycle of the building can be accessed and utilised - from design development right through to facility management. The system is managed using the ISO-approved Industry Foundation Classes. I don't pretend to understand how it works (refer to earlier references) but it seems that these systems are in fact alive and kicking.

There seems to be a danger in allowing one company to take the lead and create systems that effectively isolate themselves from the rest of the construction industry, forcing other companies to take their lead (battles between Microsoft and Apple come to mind) such as the steps that AutoDESK is taking with the application of Revit and Revit Structures. I'm not saying that this shouldn't happen, just that this type of developement of software shouldn't be exclusive.

All it requires is for software developers to actively participate in trying to reach a common basis for standards and two-way communication.

Oh, and I still have hopes for a paper-less office and world peace.

[hand471037]

the classes (from my thinly grasped understand) from IFC are based on the ISO standards. For example, a door, by definition, is a door. Whether it be a rollershutter, internal slider, solid fire door, or automatic glazed shopfront door. What separates it is how it is described. This description, if adopted across the board, shouldn't interfere with the application of the software and how it is classified as an object, should it?

No, but that's only if it's 'adopted across the board'. Seeing how long it took to simply get the 'industry' to agree upon common layer standards, and even that's still kinda a mess, you begin to see the pain that the IFC folks have to deal with. Heck, just peek in sometime to the whole Masterformat/CSI classification debates that go on to how to assign CSI numbers to things. Getting everyone to agree upon something is a very, very difficult task.

Then add to that the fact that there are many different ways to model the same construction condition, each that will report in a different way, and you've got a massive problem. For example,

It's like saying that world peace could be had if we could just get everyone to stop fighting. It's an easy thing to say, and it's true, but in reality is so hard that it's never happened.

So what IFC is trying to do is very difficult, and it's made moreso by it's versioning troubles and the fact that all these BIM systems think about things in very different ways.


That's a very good point. But taking that one step further, does that mean that International software, such as what we use, needs to be adapted to allow for language? I know that I'm continually frustrated by imperial and metric differences, but does language come into writing a stream for description purposes?

I can't image that it can't. Heck, what we call an 'eyebrow dormer' is called something else on the east coast, and in an office power and signal plan a floor poke-thru vs. a Stub out vs. a... well... you get the idea. At my day job we have 24 offices around the world. Getting everyone to agree upon what to call things just within our company is a huge, sometimes time-consuming task, and we're getting paid to talk about these things and figure them out, with some heads who have final say!


I have had discussions with a gent here in Brisbane who works for a company called 'Activefacility'. [www.activefacility.com] They have developed a building information server for managing building data. This development means that the massive information required for the lifecycle of the building can be accessed and utilised - from design development right through to facility management. The system is managed using the ISO-approved Industry Foundation Classes. I don't pretend to understand how it works (refer to earlier references) but it seems that these systems are in fact alive and kicking.

I never said that no one is using IFC's. However, when you say this system uses IFC, which standard? And what information is it getting out? And what information do you need to put in?

The reality of IFC is that isn't not just a 'save as' process anymore, and probably never will be. Sure, ArchiCAD and Revit can check off the 'IFC Support' checkbox in their feature lists, but the reality of things is so much more complex than that...


There seems to be a danger in allowing one company to take the lead and create systems that effectively isolate themselves from the rest of the construction industry, forcing other companies to take their lead (battles between Microsoft and Apple come to mind) such as the steps that AutoDESK is taking with the application of Revit and Revit Structures. I'm not saying that this shouldn't happen, just that this type of developement of software shouldn't be exclusive.

Please don't get me wrong, I don't want one company to 'rule' this space, and I never said that one should. What I am saying is that, currently, Autodesk with Revit has obtained the ability to at least get Revit to talk to other versions of Revit at a high level. That's all. I do support IFC. However, until IFC is really useful, it's not going to get used. It's very much a chicken and the egg kind of problem. I'd love to be swapping models via IFC. However, today, I can swap a Revit model with a Structural Engineer and get a whole lot more value out of it than swapping IFC models with them. I have to consider the effect these things are going to have on my bottom line, after all, for it's really about the Project, and the quality and value I can deliver to my clients. Some of who are starting to ask for IFC's, by the way, which Revit can deliver so by using Revit, and swapping Revit models with others, I can get the best of both worlds really while I wait for the other vendors to catch up so that someday I can swap IFC models with them.


All it requires is for software developers to actively participate in trying to reach a common basis for standards and two-way communication.

Again, I don't see why you keep implying that this isn't the case. I see all the vendors, Autodesk included, making strides to support IFC. Just because IFC isn't yet living up to it's hype, and isn't being used as much as you might like, isn't the fault of the vendors. While you say it shouldn't be exclusive, well, then where's Graphisoft's HVAC and Structural packages?

[dbaldacchino]

This is an interesting thread and now that I had just a little exposure to IFC, I guess it would be good to add some more to it...

I had an existing building in ADT (really just a baseplan.....8' walls with doors and windows) and I wanted to get it into Revit so we can start an additions/renovations project. So I got a trial of Inopso's conversion utility, saved an IFC file and tried to import it in Revit.

Even though Revit opened the file, serious issues immediately emerged.....Revit did not distinguish between instances of the same object, so every instance was interpreted as a unique type and got its own family. So I end up with 100s of doors and about 650 wall styles. Not good.

Out of curiousity, thinking it might be a problem with the import/export utility, I opened the IFC file in ADT. Contrary to Revit, it recognised the wall and door styles, with few exceptions, but it worked much better than it did in Revit. I have yet to try exporting a Revit file to IFC and re-import it in Revit....that would be an interesting exercise.

I contacted Inopso and asked them about why Revit read the IFC file differently than ADT. The following was their reply:


the problem that you describe is a common issue, maybe not well documented. Due to the different data representation in IFC and ADT, ADT style information has to be exported duplicated in the IFC file. On importing IFC the "IFC Utility2x for ADT" analyzes all the instances in IFC (e.g. walls) and compatible objects will get a single ADT style, other importers might not do this.
This starts shedding some light about the translation barriers that users have to deal with when using IFC. On my last enquiry regarding whether I could make some changes to the IFC file prior to importing in Revit in an effort to have instances of the same type read as such, the reply was:


I don't think there is a reasonable general solution by modifying the IFC file after export without changing the appearance and without knowing how the importer works. I would suggest to ask the vendor of your import utility for support, on how you can modify the file, so that you get the desired drawing.
It would be nice if the factory could shed some light on this. It would help us a lot in this type of situation where we can take existing buildings from ADT to Revit, saving a considerable amount of re-drawing time.

At the moment, my solution was to use filters to turn on only certain kinds of elements (ex: single-leaf left swinging doors), selecting them and changing their type. I had to repeat this over and over until all object types were changed to a Revit family and then the file purged. Filters work also on the imported IFC parameters, which is great. So getting rid of those 650 wall types and 100+ door styles wasn't too awful bad. In the case of doors, I had to temporarily set my origin in the doors to match that of the imported doors so as not to cause shifting when their type was changed.

[DoTheBIM]

Out of curiousity, thinking it might be a problem with the import/export utility, I opened the IFC file in ADT.
A little off topic, but I was told by support that ADT didn't support IFC's. How does it work, that you can open an IFC in ADT. Or did you use Inopso to create the ADT file and then open? Very curious... as it would give me something new to try what I was trying to do months ago... to get walls windows and doors into ADT from Revit. I'd like to use ADT as a middle man for a translation to a completely different application.

[dbaldacchino]

Yes, the import/export utility does the work, not ADT directly.So with Inopso's plug-in, I created an IFC from a dwg to try import into Revit. With the same tool, I re-imported the same IFC into ADT to check if it was Revit's translator that was having a problem reading the multiple instances of the same type, which it did. The Inopso import translator in ADT did a much better job than Revit, although not 100% perfect.

[adrian.banegas]

Ok three years down the road from the last time this topic was revisited, and now we have native import/export in newly dubbed Revit Arch and ACAD A. Now the wrinkle that is tripping me up is need for interoperability with IFCxml hybrid format. If anyone has any recomendations on how to get this information into an Autodesk platform I'm all ears.

[pszczelina]

So I'm just scratching the surface of what IFC is all about or really even what it is? Is IFC a list of standards? if so, where can I get a copy of that list?

I'm trying to build Revit families for windows and want to make sure that the parameters I include under the family type are IFC compatible. Can I do that? How do I do that? Do i refer to this IFC list to make sure my parameters match EXACTLY to the IFC standards?

Any help on this topic would be appreciated.

[cliff collins]

Perhaps these will point you in the right direction:

http://en.wikipedia.org/wiki/Industry_Foundation_Classes

http://www.buildingsmart.com/bim

cheers...

[irati1986]

Ok three years down the road from the last time this topic was revisited, and now we have native import/export in newly dubbed Revit Arch and ACAD A. Now the wrinkle that is tripping me up is need for interoperability with IFCxml hybrid format. If anyone has any recomendations on how to get this information into an Autodesk platform I'm all ears.

Hi! I was wondering the same. Did you find any good way to do it?

[dandlf]

Ok three years down the road from the last time this topic was revisited,

Okay 4 years since any decent discussion on this topic.

Is anyone dealing with IFC?

I came to here thinking that I may find some resources on export to IFC .txt files that will help with specific export configurations. ie. I would like to export to a client who uses Tekla or ArchiCAD.

Are we any close to industry Interoperability?

[LRaiz]

It appears that the pessimism about IFC expressed by me 3.5 years ago in this thread (http://forums.augi.com/showthread.php?t=65624) was justified.

[dbaldacchino]

I'd really love to see Leonid and James Van in a debate over IFC ;) And we could also add Guy Robinson too, but then there would be a definite bias!