Skip to content

Filter the ifcJSON Model

Filter the IfcJSON

The capability which is demonstrated here is key: we can filter an IFC model and keep only the information that is relevant to a use case, while ensuring the filtered model remain consistent. The filtering approach will obviously need to be fitted to the specific use case at hand.

Filtering the content of an IFC is a key element of providing a focused information set that is relevant for a specific administrative use case.

A Digital Building Permit will e.g., not need the information for all illustrative furnitures placed in the IfcSpaces. Details on ventilation systems may be relevant or not. Connectedness of walls may be superfluous or not.

There are 876 IfcEntities in the spec IFC 4.3.2 Annex B Alphabetical listings - Entities. Which is a lot!

There a two ways to filter:

  • Extraction: select the Elements that we want to keep. This can be done directly on the IFC model with IfcPatch by applying an 'ExtractElements' recipe. This is both efficient and convenient if the list of elements that we want to keep is limited. Extraction with IfcPatch is illutrated in a separate section (Extract Elements from the IFC model).
  • Filtering out elements that are not needed: this is relatively complex and is the object of this section.

We propose a two-fold approach:

  1. Association of categories (such as 'construction', 'system', ...) to individual entities. This is defined in the csv under /db/csv/ifc-types-ref.csv. The filter will give the categories that are retained
  2. With a given category, some IfcEntities might be superfluous for the use case, so they can be excluded.

The filtering is done by loading the ifcJSON in pandas Dataframes and/or Series, as they provide convenient capabilities.

Filtering the elements is not enough. It is critial to ensure that there are no references left to elements that have been filtered out.

There are also the relationships that link a relating element (the ''parent'') to a list of related elements (the ''children''). If a ''child'' is removed, it needs to be pruned from the list of related elements. If a ''parent'' loses all its ''children'', it needs to be removed.

The relating and related elements are named differently for the many types of relationships. Therefore, there is a csv (in /db/csv/ifc-relationships-ref.csv) that documents, for each relationship type, the names that must be used for the ''relating'' and the ''related'' elements.

The processing is then straightforward:

  1. Filter the model
  2. Split de list of entities is 4 groups (following the proposed Physical Table Model):
    • Representations
    • PropertySets
    • Relationships
    • Objects: all entities that are not in one of the 3 others
  3. Drop representations that are not related to objects retained in the model
  4. Prune the related members in the relationships; if there is no related left, then:
    • if the relating is a property_set: drop the property_set
    • in all cases: drop the relationship

At the end, the filtered model is saved as an ifcJSON.

Update the bundle and the bundleJournal

flowchart TB
    bundle
    bundleJournal
    bundle --o bundleJournal
  • update the bundle row
  • add an entry in the bundleJournal