What does IFC2x4 mean for us?

[Christiaan]

So can anyone explain in layman terms what IFC2x4 means for Vectorworks and the future of IFC?

http://www.iai-tech.org/ifc/IFC2x4/beta1/html/change/IFC2x4-beta1_whats_new.htm

[islandmon]

Christiaan , is that a rhetorical question ?

Gotta luv this IFC2x4 statement :

Product types can now be decomposed into parts and these declaring parts can be used to inform the parts of a decomposed occurrence, hence the concept of a deep copy of a type with decomposed part structure is supported.

my eye-balls are spinning around with the new control entity for proximity (relative distance between objects), for the capturing requirement (related constraint) or the actual situation (as designed or built).

However, my brain is still using the same external reference mechanism as the other resource objects.

Thanx for the heads-up ... : )

[VincentCuclair]

Does this mean that VW will/can translate door/window objects from the IFC to VW window/door PIOs?

[Christiaan]

Christiaan , is that a rhetorical question ?

Nope, it's all too abstract for my brain.

Does this mean that VW will/can translate door/window objects from the IFC to VW window/door PIOs?

That's what I was wondering.

[VincentCuclair]

That's what I was wondering.

...and hoping!

[Christiaan]

Only problem being Bentley and Solidworks aren't exactly looking to submit their formats to ISO now are they.

[Jeffrey W Ouellette]

What does it mean? Practically, not much, for now. But it does offer some more robust data sharing potential in the future.

Right now, IFC2x3 is the current standard. All vendors are still currently working to support this version of IFC.

While IFC2x4 provides a number of wide-reaching improvements, implementation of this will take time, as it means changing the way automatic translation is done of native objects, and interface changes for custom objects (and not just in VW).

The current focus of buildingSMART and developers is to nail down the interoperability based on IFC2x3, before moving to 2x4. This may take at least another year or two, before you get a majority of apps rolling out stable, reliable IFC2x4 export and import support, thus making a market-wide impact.

We will always work hard to try and support the latest official standard in the subsequent version of VW. The current buildingSMART timelime has the IFC2x4 specification finalized by the end of 2009 Q4 and available for development uses Q1 of 2010. However, until the testing and certification process for IFC2x4 is complete, it is hard to give you a timeline, or indicate what version of VW will support it.

[Jeffrey W Ouellette]

Vincent,

Some recent testing on my part shows that nobody consistently and reliably supports this kind of interoperability. However, most of the current versions of competitive software support the import of the instances of doors and windows without translating them into native objects pretty well.

I don't think this is a bad thing, but it is a part of the workflow that everyone will need to be aware of.

IFC isn't intended to be the "universal" parametric file format. That is, it isn't meant to be the shuttle file from one apps native data structure to another. Instead, it is a capture of the resulting data, the description, itself.

IFC only specifies how the geometry and data should appear, regardless of the native apps data structures, not how the app should treat the data when it is imported. This is left up to the application developers.

Windows and doors are tough because every competitive app has a unique way of creating the geometry for their particular format. Some provide a very high degree of detail that can't be supported, or directly mapped, by the parametric data structure of another.

Right now, I'll be happy when we can all see the same window/door, the same way, in the same place, with the same data, even if it isn't translated into a native object.

Edited June 17, 2009 by Jeffrey W Ouellette

[RubenH]

I see IFC 2x4 will support NURBS geometry. IFC doesn't suppurt it now. I think this is a big step forward.

[Christiaan]

IFC isn't intended to be the "universal" parametric file format. That is, it isn't meant to be the shuttle file from one apps native data structure to another. Instead, it is a capture of the resulting data, the description, itself.

Do you see the client/server approach (e.g. BIMserver) as a way to bypass this limitation?

Edited June 17, 2009 by Christiaan

[VincentCuclair]

IFC isn't intended to be the "universal" parametric file format. That is, it isn't meant to be the shuttle file from one apps native data structure to another. Instead, it is a capture of the resulting data, the description, itself.

OK J, i didn't know that.

Having said this I tried importing an IFC2x3 from VW to ArchiCAD and the doors and windows show up as Symbols which can simply be translated into ArchiCAD PIOs (similar to the replace function we know in VW symbols/PIOs), unfortunately simple parameters such as width and height are not automatically transfered, which is a shame. So I think that even if it is not meant to be it has already started to be a universal parametric file format (walls already translate into walls).

Looking at the companies I have worked for, the majority of parametric objects used i.e. 75% are walls, basic doors and windows, followed by stairs and more complicated doors/windows 20%.

If the next generation IFCs allow these PIOs info (i.e. width height) to be recognized cross platform, then I think for most 'normal' offices this will make IFCs effective enough to use as a universal file format i.e. 75% of PIOs already are in place and ready to use.

I hope VWs developers take the time to develop this compatibility (i.e. wall/simple doors/simple windows height and width) I think that would be a great big step in the right direction for many people!!!

Edited June 17, 2009 by Vincent C

[Jeffrey W Ouellette]

Do you see the client/server approach (e.g. BIMserver) as a way to bypass this limitation?

Nope. The BIMserver has nothing to do with it. On one end, it's all about the actual file format and what it holds. On the other end, it's about what an app is able to do with that file format information and translate it into native data formats and subsequent objects.

Not all native app data structures, from all different apps, can be directly accommodated by the IFC schema. Conversely, the IFC schema is relatively simple, with very direct geometric representations tied to very direct data sets, including semantics (what does my geometry represent or is an analogy of), specifics (what are the static parameters at the moment and current configuration), and relationships to other model objects (if I'm a Column, what am I connected to above and below and in what Space am I located).

But this "snapshot" of the building's representation/data is also meant to be universal, open, vendor-neutral. Thus, one could argue that it provides the data in the "lowest common denominator". While this may limit the ability to move/exchange parametric objects around, at will, it also provides a relatively low threshold for entry into reading and writing the file format.

[Christiaan]

Nope. The BIMserver has nothing to do with it. On one end, it's all about the actual file format and what it holds. On the other end, it's about what an app is able to do with that file format information and translate it into native data formats and subsequent objects.

I guess I was thinking along the lines that in a client/server approach you're not necessarily importing and exporting so therefore not losing extended data specific to a vendor. Then again I'm assuming there is such a thing as extended data specific to a vendor (and that importing and exporting from another app destroys that data).

While this may limit the ability to move/exchange parametric objects around, at will, it also provides a relatively low threshold for entry into reading and writing the file format.

Well, I hope this changes soon, otherwise it's going to disappoint a lot of people. It's all very well to have interoperability but losing fidelity through the loss of parametric objects is too higher price.

So I assume many parametric objects will need to be reworked in order to play nicely with IFC. But are you also saying IFC doesn't yet provide enough complexity and hooks, or worse that it's not the intention of IFC to provide this complexity?

Now, BIM/CAD apps that read and write IFC natively would be interesting. Maybe more akin to the web than the isolated boxes we currently put ourselves in.

[Christiaan]

I guess I was thinking along the lines that in a client/server approach you're not necessarily importing and exporting so therefore not losing extended data specific to a vendor.

Not necessarily, but that's exactly the approach they've taken with the Revit plugin:

http://www.bimserver.org/2009/05/25/revit-plugin-to-connect-to-bimserver/