When is a door not a door . . . . choosing the correct entity classification for quantity take off.

Developers
1

When is a door not a door . . . . choosing the correct entity classification for quantity take off.

The old joke goes “When is a door not a door, when it’s ajar”. My dad used to get constant amusement from this joke and I perhaps now truely understand why it can be so funny but perhaps in more of a desolate manner.

Recently I upgraded my export process out of Archicad 23 from IFC2x3 TC1 to IFC4. Rather than relying on an out of the box translator I had spent the time to create a Archicad classification system for IFC2x3 and IFC4 allowing a one to one type mapping on export.

Map IFC Types for Export
Map IFC Types for Export1452×1740 501 KB

This I am finding is more and more important the further I get immeshed in the workings of IFC. Going back to my father’s often repeated joke, I now find myself asking this question over and over again for each element in my BIM model. The latest anomaly I have found is when is an IfcCovering CLADDING not an IfcCovering CLADDING but an IfcCurtainWall and conversely when is an IfcCurtainWall not an IfcCurtainWall but an IfcCovering CLADDING.

At this point because from my limited experience in estimating, it comes down to what facade is being modelled and what shape the panels take.

The cladding layout shown was originally classified as IfcCovering CLADDING.

Pasted Graphic 2
Pasted Graphic 2988×882 1.74 KB

However on closer inspection of the IfcCovering only the thickness of the cladding material is given and only when this material is ‘prismatic’, as shown in property Width, Q_Length. (My own opinion some clarification of language use here needs to be done because a lot of people are at first glance going to get this wrong).

This classification is not the appropriate one for the FC cladding shown above. A take off cannot be achieved because no width nor length is available. Note here width actually means width not thickness. Just to make it more confusing than it already is.

Pasted Graphic 4
Pasted Graphic 42068×646 101 KB

So I went hunting through the IFC Schema for the appropriate classification. IfcCurtainWall has the correct quantity values for take off.

Pasted Graphic 5
Pasted Graphic 51920×1042 261 KB

Again note here width actually means width not thickness. I know lockdowns are hard but I really do we really need to make it this hard? If I wasn’t crazy already . . . . .

So the lesson I have learned is that you cannot have a predefined classification system that associates a BIM modelling tool with a specific classification in IFC because you will end up making it much more difficult to get the correct quantities you need for your take off.

So when is a door not a door . . . . .

2

I was recently implementing some functions that “guess” these quantity values… it would be really good if buildingSMART could write somewhere in the documentation what the assumed terminology refers to: for example “Width” vs “Height” vs “Length” vs “Thickness”.

A wall has a “height”, but a column has a … “length”? Funky. Clearly consistency is needed.

Here’s a proposal to get the discussion started (sorry @CodeArchitecture I’m ignoring your issue about classes and nitpicking on a single comment you made on inconsistent quantity properties):

  • The XY plane is horizontal, and the Z axis is vertical.
  • The “Height” shall refer to a dimension in the global Z axis where possible.
  • “Width”, “Length”, and “Thickness” are always references to dimensions in the XY plane.
  • “Length” and “Width” may be specified together in the same quantity set. If the X and Y dimensions are unequal, “Length” refers to the greater dimension, and “Width” refers to the smaller dimension.
  • “Width” and “Thickness” may be specified together, usually used for thinner/flatter objects. If the X and Y dimensions are unequal, “Width” refers to the greater dimension, and “Thickness” refers to the smaller dimension.
  • All four, “Height”, “Length”, “Width”, and “Thickness” shall not be specified in the same quantity set, as this creates confusion.
  • All exceptions to the rules above shall be clearly noted in the specification.
1 Like
3

Dion,
Not a problem, the post was not just about classes but also about quantities. I am noticing quite a few irregularities when it comes to describing quantities as well. I was going to cover that issue in my next post but glad you have brought up exactly what I was going to talk about.

We not only need to clarify what dimensions are called ie width, height, length or thickness and when this should occur but we also need to clarify like the Danish are doing (@jan.karlshoej ) with their CCS BIM standards and create visual tables to show the extent to where items are measured. I can have the height and width of a door but is this of the opening in the wall at the outside edge of the jamb or is it the clear opening of the door itself. I would like to see and English version of the Danish CCS Measuring Rules to be incorporated into the IFC4 schema to ensure everyone is measuring the same items the same way.

1 Like
4

A good visual example is in the Archicad documentation for their quantities. Recommended inspiration.

About length or height of columns and others: don’t invent something before you check construction standards at ISO and/or CEN level. It would be a huge missed opportunity to use something that others define differently.

1 Like
5

@stefkeB can you refer me to the particular Archicad documentation you are referring to?

6

Here is the example for Door parameters.

This is documented for all model objects. Something that would be nice to elaborate for all IFC Base Quantities.

In Belgium we discussed measurement codes and had to realize that the normative codes are not widely known, although some of them are still commonly applied from habit/experience.

7

@stefkeB thanks very much. I have been relating my measurements from what I could understand to the measurements from Archicad. This reference is awesome as it finally depicts graphically what each measurement means. Long overdue.

1 Like
8

Is there a buildingSMART project currently tackling this? Perhaps the folks from Graphisoft could help provide a good starting point?