Skip to main content

IFC Properties: When dimensions are not delivered in a standardized format

Dimensions such as areas or volumes are often not stored uniformly in the IFC model – we show you how you can use this information.

Written by specter automation
Updated over 5 months ago

Specter provides you with various geometric measurements such as surface areas and volumes. These can either be calculated automatically or transferred from the IFC model. In this series of articles, we explain how these values are generated, what you should pay attention to, and why the same “surface area” is not always to be understood in the same way.

In this article, we will show you:

  • How to find IFC properties when dimensions are not available as base quantities

  • How to interpret custom dimensions correctly

  • What to look out for in order to understand the differences between properties and base quantities


1. What are IFC Properties?

IFC properties are user-defined properties that modelers can attach to objects manually or semi-automatically in CAD software. They usually consist of key-value pairs, e.g., ‘height’ = 2.5m. Unlike base quantities (Qto), these properties are not standardized, which means that anyone can use their own terminology for them.

2. Example of an IFC Property

A property could look like this, for example:

IFCPROPERTYSINGLEVALUE(‘Height’,$,IFCLENGTHMEASURE(1.95),$)

specter recognizes such entries by their keys and extracts them if they match known patterns.

3. Challenges with IFC Properties

Since the names can be freely chosen, inconsistencies or misunderstandings can easily arise:

  • ‘Height’ can refer to the actual object height – or to the height above ground level.

  • ‘Width’, ‘length’, ‘depth’ – are assigned differently depending on the modeler.

  • There is no validation by the IFC format itself.

  • Dimensions may be specified in different units or formats.

The properties that Specter currently filters out and can use are listed below.

4. How does specter handle these properties?

specter attempts to extract values from IFC properties if they are not available via Qto. To do this, it analyzes known keywords (e.g., ‘height’, ‘width’, ‘depth’). However, since these fields are inconsistent, this is done with caution—and only as a supplement.

The extraction of these dimension properties can be activated by selecting the appropriate dropdown menu when starting the model pipeline.

5. Recommendations for modelers

  • Avoid ambiguities in keys (e.g., ‘height above ground’ instead of just ‘height’).

  • If possible, use base quantities for reliable measurements.

  • Document properties used in a separate mapping or export schema. (This does not mean that specter can integrate this by default, but it helps you with documentation in general.)

  • Use consistent units. Preferably meters, as specter specifies dimensions in “m” and not in millimeters [“mm”].

6. Summary

  • IFC Properties are free measurement entries that are not standardized.

  • They are potentially prone to errors, as keys can be chosen arbitrarily.

  • specter only uses them as a supplement when QTO or internal calculations are not available or when the checkbox is activated. Order of dimensions: 1. Official QTO quantities -> 2. From properties (if activated) -> 3. Specter quantities.

  • For consistent dimensions, we recommend using base quantities.

  • Only use quantities from individual properties in emergencies when absolutely necessary.

Specter's properties

Key – Important information in advance:

STRING_EQUALITY = must be written exactly as shown, including upper/lower case

REGEX_MATCH = here we use Regex, e.g. .*Volume means that we take everything that ends with “Volume” (including upper/lower case)

REGEX_MATCH_IGNORE_CASE as above, but EXCLUDING upper/lower case

STRING_CONTAINS_IGNORE_CASE here, the text simply has to be contained somewhere, excluding upper/lower case

Dimension Properties:

pattern: “AV_Volumen”

type: STRING_EQUALITY

pattern: ".*Volumen",

type: REGEX_MATCH

pattern: "^(?=.*volume)(?=.*net).*$"

type: REGEX_MATCH_IGNORE_CASE

pattern: "\\b(?!(?:\\w*höhen|\\w*höher))\\w*höhe\\w*\\b(?!\\w+)",

type: REGEX_MATCH_IGNORE_CASE

pattern: "Height",

type: STRING_CONTAINS_IGNORE_CASE

pattern: "AV_Dicke",

type: STRING_EQUALITY

pattern: "\\b(?!(?:\\w*breiten|\\w*breiter))\\w*breite\\w*\\b(?!\\w+)",

type: REGEX_MATCH_IGNORE_CASE

pattern: "\\b(?!(?:\\w*dicken|\\w*dicker))\\w*dicke\\w*\\b(?!\\w+)",

type: REGEX_MATCH_IGNORE_CASE

pattern: "Thickness",

type: STRING_CONTAINS_IGNORE_CASE

pattern: "AV_Laenge",

type: STRING_EQUALITY

pattern: "\\b(?!(?:\\w*längen|\\w*länger))\\w*länge\\w*\\b(?!\\w+)",

type: REGEX_MATCH_IGNORE_CASE

pattern: "Length",

type: STRING_CONTAINS_IGNORE_CASE

pattern: ".*Fläche",

type: REGEX_MATCH

pattern: "^(?=.*area)(?=.*net)(?=.*side).*$"

type: REGEX_MATCH_IGNORE_CASE

pattern: "^(?=.*area)(?=.*gross)(?=.*side).*$"

type: REGEX_MATCH_IGNORE_CASE

pattern: "AV_Flaeche"

type: STRING_EQUALITY

pattern: "perimeter",

type: STRING_CONTAINS_IGNORE_CASE

Did this answer your question?