Overview over a page

When opening the page for e.g. IfcSlab this is the following view:

I have highlighted two things in this screenshot. On the top there is the section list for all entities, enumerations and types of IFC. In the content frame I have marked one section heading. These are clickable and fold/expand the content of their section when doing so. For me this behaviour wasn’t obvious, because the headings give absolutely no hint that they react to clicks (no highlighting or anything). For example the “Attribute inheritance” section is always folded by default, clicking it reveals a table with all (inherited and added) attributes for the current entity.

The bulk content of IFC is divided into the following sections:

1. Core: These entities form the base for every project. The building definition, abstract classes for objects and products, various relations, properties and tasks are in this group. Entities in this group usually change rarely between IFC versions, resulting in high compatibility for those entities.

2. Shared Elements: Basic architecture components. Walls, Doors, Windows, element parts (e.g. fasteners), stairs, slabs, pipes and cables are in this group. Entities in this may change between versions, but usually not much. Compatibilty is usually still good.

3. Domain specific elements. Entities for specific occupations: Details for doors and windows, electrical installation, HVAC, fire protection and structural analysis. Elements in this group are not expected to be compatible between versions.

4. Resource defitions. These entities are usually referenced by other entities to provide descriptions and details. In this group are actors, contract details, date and time, geometric components, material and appearance definitions, measurements and quantities, structural load and utility entities. Entities in this group are usually compatible between versions.

Reading attribute lists

Each entity usually has several attributes. An entity can be seen as a class in an object oriented programming model. The IFC standard also builds entities in a hierarchy which corresponds to class inheritance in OOP. An attribute can be seen as a member variable. In addition there are so called inverse attributes. They result from references between instances of entities and can be seen as back reference. Inverse attributes are not written into IFC files, they are maintained by the IFC library. They can usually be used like normal attributes when programming scripts.

Let’s have a look at the attribute inheritance list for IfcSlab:

The meaning for each column is as follows:

1. Index (#): Position of the attribute. This is the position of the attribute in the entity when written into a file. Inverse attributes don’t have an index, as they are not written to file.

2. Attribute name. Inverse attributes have an italic name. The name is used by IfcOpenShell as member variable name.

3. Type. The type is the entity you will get when accessing the attribute. For inverse attributes the text following ‘@’ is the attribute name affecting the inverse attribute in this entity. So for example “IfcRelAssigns @RelatedObjects” means when adding an IfcSlab to the attribute “RelatedObjects” in IfcRelAssigns will add that “IfcRelAssigns” to the inverse attribute if the IfcSlab.

4. Cardinality. How many elements this attribute holds. Note that there be might malformed files with invalid cardinalities.

   • If no cardinality is given it means exactly one element

   • A single question mark means one or zero

   • A single S followed by brackets with a number, a colon and another number or a question mark (e.g. “S[0:?]”): A set of entities. Each entity instance may only occure once. The first number is the minimum number of elements in this set, the second is the maximum number. A question mark may occur as maximum count to denote no limit.

   • A single L followed by brackets (analogous to S). A list of entities. The difference to the set is that entities might have multiple occurences.

   These cardinalities can also be combined. Each one further down the list is to be understood as a single element in the previous cardinality. For example attribute “Normals” of IfcTriangulatedFaceSet: “? L[1:?] L[3:3]”: This attribute is optional (the first ‘?’). If it is set is contains a list with at least 1 element, but no limit. Each element in this list is itself a list of exactly 3 values of type IfcParameterValue.

5. Description. Supplementary description. Changes between versions are written in red.

6. G/R/D: Usage in current schema. G is used for the complete IFC4 schema, R for reference view and D for Design Transfer View. There might be attributes and entities which are not used in every view. This column has an x if the attribute is used in the current schema.

If an attribute doesn’t exist (for example because it is optional and not set) then IfcOpenShell won’t create a member variable in the class for it. Accessing it will result in an exception.