Extract IFC

Industry Foundation Classes (IFC) is the format designed to exchange Building Information Model (BIM) data between contract entities in the building industry. AIM with access to both the models and their engineering data allows the impacts between building and plant to be assessed directly, both for planning new work and for maintaining existing facilities.

BIM is a process standard to manage complex projects where project, engineering and 3D geometry data are shared between various entities involved in defining project scope, delivery, handover verification and subsequent operations facilities management. BIM is being recognized generally as a more efficient way to manage projects that rely on 3D models. While not every BIM project mandates the use of IFC as the data transfer format, it is the format most widely associated with BIM. It is therefore a common assumption or requirement that products in a BIM project support the IFC format.

IFC (Industry Foundation Classes):

• Definition: IFC is an open, non-proprietary file format used for exchanging and sharing data in the field of Building Information Modeling (BIM).

• Purpose: It facilitates data exchange between professionals involved in design, construction, management, and maintenance of assets, regardless of the software they use.

• Format: IFC files are XML-based and contain information about spatial elements, materials, shapes, and more.

• Standardization: IFC is an international standard (ISO 16739) and promotes interoperability across various BIM tools.

The Gateway can extract data either from IFC input files located in a local File System or from files stored in Amazon Web Services (AWS) in an S3 Bucket. This is defined in the extract configuration in the <input> element, via the source parameter, for example, <Input source="FileSystem">.

Note: The values of the source attribute can be a case-insensitive representation of either "FileSystem" or "S3".

To specify how to extract the data:

1. Click Extract to display the Extract page.

2. Select the type of Input Source from the drop-down box.

   For File System:

3. From the File System section, type the location of the input files (IFC files) from the Input Path box. Alternatively, you can use the Browse IFC File and Browse Path options to enter the input file location.

   Note: The Input Path value must point to a valid folder location having one or more valid input (.ifc) files.

   

   For S3:

   To configure the extractor for S3 Bucket as input source:

4. Follow the procedures mentioned in Accessing an AWS S3 Bucket to use the S3 Credential Details. If you want to test connection to S3 Bucket, click Test Connection. The result of the test is displayed in bottom left status bar.

   

   Other Settings:

5. Select either Error or Warning to continue the processing of the project, which do not comply with schema definitions in the Treat Schema violations as section. For more information about treating these schema violations, see Treat Schema violations as Error or Warning. You can configure the same using apply attribute of the element <treatSchemaViolationAsWarning apply="1" /> in the Extractor configuration file.

   Note: The "apply" value must be an xsd schema supported Boolean value. The valid values for xsd:boolean are true, false, 0 and 1. Attribute values that are capitalized (for example, TRUE) or abbreviated (for example, T) are not valid.

6. Select FastExtractionMode option for better performance while extracting objects. See FastExtractionMode.

7. Click Save Settings.

8. Click Generate Summary to get a configurable summary of each IFC file.

   Note: An IFC Summary report provides the statistics and statuses from specific IFC fields. Based on this report, you can decide if any specific file should be imported into AIM. This Summary report is usually in the form of a CSV file containing a section summarizing IFC file names, view definition, creation date, import date and IFC schema version. It also contains counts for each entity types present in the IFC file. This report can be used to troubleshoot any extraction error, if any file fails to be extracted.

Treat Schema violations as Error or Warning

The Gateway uses the relevant IFC schema (2x3 or 4) to generate the property names for the property values of each entity in an IFC file. Normally an Error is logged if the number of properties in the entity is different to the schema definition. An option is available on the Extract tab to treat such schema violations as warnings, so that the issue can be logged but subsequent entities will be processed.

You must check the log file for any such warnings and decide whether to correct the IFC file and re-process or allow the schema violation:

• If Error is selected (default), the Gateway stops processing any file which violates the schema definition and logs the Error.

• If Warning is selected, the Gateway proceeds with processing all entities in the file, and logs the Warning for any schema violations. For example, if N is the number of attributes (IFC properties) for an entity in the file and M is the number of attributes defined in the IFC schema, then the following two scenarios occur:

  • If N > M, the Gateway reads the first M attributes and logs a warning.

  • If N < M, the Gateway assumes that the first N attributes are correct and the missing M-N attributes have a value of $ and logs a warning.

    If an attribute has a relationship with another (target) entity but the class of the target entity violates the schema definition, the Gateway processes the target entity based on the class defined in the IFC file and logs a warning.

    If the above assumptions result in a processing error, the Gateway ignores that entity and its dependent entities, logs a warning and processes the next entity.

    Note: The optional 'annotations' feature allows you to store additional data about how each object, attribute or association has been changed due to a transformation step. These tracking attributes store data about creation, modification and deletion operations and can be inspected via CSV reporting. This can be achieved by adding XML <annotations> node to the module configuration. Available annotations level values are 'None' and 'Basic'. For example:

    <configuration ...>

    ...

    <annotations level = "Basic" />

    </configuration>

For more information, see Appendix B: CSV Reporting.

Note: The Gateway can identify some attributes as key attributes, as these attributes will be exported into EIWM file even without mapping in configuration. For example, ObjectID, ObjectName, Revision and so on. For more information about these key reserved attributes, see Appendix E: Reserved Attributes Used in the Gateway.

FastExtractionMode

Normally relationships between IFC objects are determined by querying the source object for all of its inverse and direct relationships, which is time-consuming. If FastExtractionMode is enabled, then inverse relationships are created after all objects have been extracted via a separate process, which is a lot faster. It does however result in different association types as they are then derived from the inverse attribute name, rather than the inverse relationship type name from the source object's schema definition.

For example, if part of the input IFC file is defined as:

#380= IFCDOOR('3$pEhtFpv31QFndkpGikoC',#41,'M_Single-Flush:0915 x 2134mm:197506',$,'0915 x 2134mm',#698,#374,'197506',2134.,915.);

#385= IFCPROPERTYSINGLEVALUE('Reference',$,IFCIDENTIFIER('0915 x 2134mm'),$);

#386= IFCPROPERTYSET('3$pEhtFpv31QFnbHpGikoC',#41,'Pset_DoorCommon',$,(#247,#385));

#388= IFCRELDEFINESBYPROPERTIES('10D4T6dArDZePbheZhDXiI',#41,$,$,(#380),#386);

Then the normal method for creating relationships uses the IFC schema definition of IFCDOOR which contains an inverse attribute called 'IsDefinedBy' and its type is 'IfcRelDefines'.

Note: IfcRelDefines is a base type having subtypes like IfcRelDefinesByProperties, IfcRelDefinesByType. If FastExtractionMode is enabled, then the association type is derived from the IFC file as "IfcRelDefinesByProperties", that is, it takes whatever the inverse relationship entity is defined as in the input file.

Without any association transformation, the EIWM will be:

<Object>

<ID>3$pEhtFpv31QFndkpGikoC</ID>

<Context>

<ID>IPE</ID>

</Context>

<ClassID>IFCDOOR</ClassID>

<Association type="IFCRELDEFINESBYPROPERTIES">

<Object>

<ID>3$pEhtFpv31QFnbHpGikoC</ID>

<Context>

<ID>IPE</ID>

</Context>

<ClassID>IFCPROPERTYSET</ClassID>

</Object>

</Association>

</Object>

If you disable the FastExtractionMode, then the same IFCDOOR object will have an association type 'IsDefinedBy' in EIWM.

EIWM:

<Object>

<ID>3$pEhtFpv31QFndkpGikoC</ID>

<Context>

<ID>IPE</ID>

</Context>

<ClassID>IFCDOOR</ClassID>

<Association type="IsDefinedBy">

<Object>

<ID>3$pEhtFpv31QFnbHpGikoC</ID>

<Context>

<ID>IPE</ID>

</Context>

<ClassID>IFCPROPERTYSET</ClassID>

</Object>

</Association>

</Object>

Limitations:

The following related types in certain inverse relationships cannot be processed:

• IfcRelConnectsPathElements:

  • RelatingPriorities: Priorities for connection. It refers to the layers of the RelatingObject.

  • RelatedPriorities: Priorities for connection. It refers to the layers of the RelatedObject.

  • RelatedConnectionType: Indication of the connection type in relation to the path of the RelatingObject.

  • RelatingConnectionType: Indication of the connection type in relation to the path of the RelatingObject.

• IfcRelConnectsWithRealizingElements:

  • RealizingElements: Defines the elements that realize a connection relationship.

• IfcRelSpaceBoundary:

  • PhysicalOrVirtualBoundary: Defines, whether the Space Boundary is physical (Physical) or virtual (Virtual).

  • InternalOrExternalBoundary: Defines, whether the Space Boundary is internal (Internal), or external, that is, adjacent to open space (that can be a partially enclosed space, such as terrace (External).