Building envelopes in IFC

Activities & Projects IFC4.3 Building Room - Building Domain Review
1

Description of the issue

Many glass panes today have spectrally selective coatings. This means that architects/planners/engineers need the transmittance and reflectance of each glass pane spectrally resolved to calculate the optical properties of the window. Shading like a venetian blind or a screen is in general angle-dependent. This means that the direction of the incident radiation and the emergent radiation needs to be quantified. When there is a risk of glare, the angle-dependent optical properties need to be available in high resolution.

The approach of the buildingSMART Data Dictionary and of the Universal Types is to define properties as key-value pairs. For the optical data of building envelopes, this is not feasible because it would result in a countless number of properties like transmittance_incidence_direction_polar_8_azimuth_0_wavelength_415_polarization_s_1_p_0_emergence_direction_polar_8_azimuth_0 . Such properties are difficult to understand and difficult to parse and to process in an automated way.

The JSON Schema opticalData.json has been developed on GitHub in order to exchange optical data about building envelopes in a way which is easy to understand for software developers and easy to parse and to process in an automated way, because there are powerful open-source software packages available. As an example, the transmittance and reflectance for nearnormal incidence can look like

{
  "dataPoints": [
    {
      "incidence": {
        "direction": {
          "polar": 8,
          "azimuth": 0
        },
        "wavelengths": {
          "wavelength": 415
        },
        "polarization": {
          "s": 1,
          "p": 0
        }
      },
      "emergence": {
        "direction": {
          "polar": 8,
          "azimuth": 0
        }
      },
      "results": {
        "transmittance": 0.81,
        "reflectance": 0.08
      }
    }
  ]
}

Options

There seem to be two main options.

Option 1: Offer additional detailed data via an application programming interface (API)

Each entity in IfcElement receives an additional entity like “IfcEndpoint”. IfcEndpoint has two properties: One property to store the URL of one or more API endpoints and one property to store the unique identifier of the IfcElement for these endpoint(s). In this way, detailed data about a component can be accessed and processed in an automated way and IFC does not need to be extended by many additional entities and properties.

Option 2: Extend IFC with detailed data about building envelopes

The structure of the JSON Schema opticalData.json (on GitHub) can be used to extend IFC 4.3 to include all relevant optical data of building envelopes. This results in many new entities and properties in IFC. It has the advantage that all data about a building project including detailed optical data of the building envelope can be exchanged in one file. This option has the disadvantage that the resulting IFC file can be very large, depending on the resolution of the optical data.

2

Maybe I’m missing something, but isn’t this a perfect use case example of the bSDD for extended data? Not sure why you couldn’t use the bSDD to add a domain (e.g., Building Glazing Performance… or use ASTM/IBC xxxx, etc.) for glazing properties that adds new Psets and properties beyond what Pset_MaterialOptical does for the actual glazing material and Pset_DoorWindowGlazingType does for the general definition of the door/window performance parameters.

I would say you could more easily create an appropriate custom property set(s) and then have your key value pairs (properties). In the bSDD you would declare that it is a custom property set of the IfcMaterial, where some type of glazing material is declared. It’s just a matter of setting it up and establishing the owner/authority (e.g., NGA or FGIA) of such a domain. Where would the optical standards come from?

You could still use JSON as an alternative to transmit the data (where it is supported), but the key is to have a single, authoritative, standard IFC mapping to tell people how it relates to the building model… otherwise, wouldn’t the receiving app (and user) have all the burden figuring out where the optical data goes (which specific semantic objects/concepts [door/window or material] the data is attached to)?

Also, not sure why I would worry about the size of the IFC file, at this point. How many bytes could such data possibly add to a 2, 3, or 4 GB building file?

3

From my understanding you seek to attach custom data to IFC entities where the data has a more complex structure rather than a flat set of key-value pairs. You want to specify a data structure with nested semantic grouping of values. In theory this could be achieved with complex properties, a particular type of property which does not hold a single value (contrary to a simple property) , but another set of properties which could in turn be complex or simple properties.

In IFC4 Add2 TC1, there where few such properties, namely for example in property set Pset_MaterialWoodBasedBeam: InPlane, InPlaneNegative, OutOfPlane are all complex properties, of the same complex type CP_MaterialMechanicalBeam. Your example lends itself to a complex property type “direction” among others.

However, in IFC4X3, these complex property definitions within one property set have been replaced with a flattened structure of multiple property sets, namely Pset_MechanicalBeamInPlane, Pset_MechanicalBeamInPlaneNegative, Pset_MechanicalBeamOutOfPlane. This has the drawback of the same attributes having to be repeatedly defined (and there are more similar - scroll down to the bottom of the IfcMaterial class property sets). Also, the former data structure is practically kind of “encoded” in the pset name - not so very nice.

On the advantage side, a flat structure without complex structures is much easier to manage in a dictionary with massive amounts of user-defined properties, less error-prone to specify, easier to verify and more suitable for users with good domain knowledge and only basic data modelling skills. I am not sure about the latest status of discussion. I believe that beyond removal of the (few) complex properties from the official property sets, bSDD does not support complex properties anyway, tool support is poor and the use of complex properties is in general discouraged. Yet, they are still there in IFC4X3 and not deprecated.

As an alternative to flat property sets, you may want to consider using an external schema and data set which you link to certain entities by external reference. This is possible with the current entitiy types and attribute definitions in IFC. Ideally, for such a solution you build on existing standards instead of rolling your own. Maybe this is what you subsume under the term API. The term is a bit misleading since IFC is not an application with an interface to program against.

4

Thank you Helga and Jeffrey!

How many bytes could such data possibly add to a 2, 3, or 4 GB building file?

When a planner needs to calculate the Daylight Glare Probability, bidirectional optical data is needed for the shading with a size of about 5 GB. The total size depends on the number of different types of shading.

Not sure why you couldn’t use the bSDD to add a domain

I think it is not possible to model optical data sets well with the current bSDD. There seems to be no key oneOf.

It seems like I’m not allowed to add links or images to this topic which is inconvenient. A schematic drawing of the structure of an optical data set is available at github.com_building-envelope-data/api/blob/develop/docs/diagrams/out/opticalData/opticalDataPointSchema/opticalDataPointSchema.png .

The direction of the incidence radiation can be defined either by two angles or by the string “hemispherical”. Hemispherical is needed for example for diffuse radiation from the sky and ground without the direct radiation from the sun.

oneOf is also required to define the wavelengths of the incident radiation. An integral value like visible and solar can often be used for a window. When an optical layer of a fenestration system has spectrally selective properties, then planners need optical data for all relevant wavelengths. For example, glass panes with a low-emissivity coating have spectrally selective properties. oneOf is also needed for polarization and the direction of the emergent radiation and for the definition of colors.

On the advantage side, a flat structure without complex structures is much easier to manage in a dictionary with massive amounts of user-defined properties, less error-prone to specify, easier to verify and more suitable for users with good domain knowledge and only basic data modelling skills.

Does IFC aim at experts in Architecture, Engineering and Construction (AEC) or at software developers? I thought software developers should implement IFC and bSDD in their software applications and AEC experts shall use the applications. Dictionaries with massive amounts of user-defined properties do not seem error-prone to me and difficult to verify. Software developers are used to read and understand a JSON Schema like opticalData.json on GitHub. The schema can easily be used to validate an optical data set.

you may want to consider using an external schema and data set which you link to certain entities by external reference. This is possible with the current entitiy types and attribute definitions in IFC.

Thank you for mentioning IfcExternalReference ! This is pretty close to what we need for Option 1. Unfortunately, the entities which inherit from IfcExternalReference (IfcClassificationReference, IfcDocumentReference, IfcExternallyDefinedHatchStyle, IfcExternallyDefinedSurfaceStyle, IfcExternallyDefinedTextFont, IfcLibraryReference) do not really fit.

Therefore, I propose to add an entity IfcApiReference to IFC 4.4. IfcApiReference should inherit from IfcExternalReference and the inherited attributes Location and Identification should be mandatory, for the URL of the API and the identifier of the component in the API.

IfcApiReference should receive the optional attributes ApiSpecification of Type IfcURIReference and ApiRequest of Type IfcURIReference. The URL of ApiSpecification guides software developers to the specification of the API and helps them to understand how to use the API. The URL of ApiRequest combines the URL of the API with the Identifier of the component. The URL of ApiRequest can easily be used to request the data of the component from the API.

How can we proceed with such a proposal?

Where would the optical standards come from?

Ideally, for such a solution you build on existing standards instead of rolling your own.

We have developed the JSON Schema for optical data sets in cooperation with Berkeley Lab, National Fenestration Rating Council, Attachment Energy Rating Council and European Solar Shading Organisation. It is based on several standards for certain aspects of optical data and goes beyond them being able to represent all currently relevant optical data in one JSON format.