Extract a Storey from the Database

Data and Spatial visualization

Extractions are twofold: the invisible part is the set of data that pertain to the spatial unit at hand. On these data, processes can be run to provide metrics / indicators (surfaces and volumes, space types and usage, energy transfer, life cycle, reuse, ...).

The visible part is there to help understand the structure of the spatial unit, but also to identify issues, such as components that exibit misclassification and other anomalies.

Extraction of a Storey from the Database

Here, we work with the database and extract all the elements that are somehow part of a Spatial Unit, referred to in the code as a container. For the container, we start with a building storey.

Initially, we work with Duplex_A_20110907_optimized.ifc, which has been filtered (no furnitures) and has several storeys.

The target is an IFC(STEP file) that we can visualize with a standard IFC Viewer.

Submit the processing request

The extract Import is started by sending a POST with a Json Body as defined in pydantic

class ExtractSpatialUnitInstruction(BaseModel):
    bundleId: str | None = "1"
    elementType: Literal['IfcBuildingStorey', 'IfcZone', 'IfcSpatialZone', 'IfcSpace', 'IfcGroup'] | None = 'IfcBuildingStorey'
    elementId: str | None = '7b7032cc-b822-417b-9aea-6429f95d6512'

    @computed_field()
    def includeRelationshipTypes(self) -> str:
        if self.elementType == 'IfcBuildingStorey':
            return ['IfcRelAggregates','IfcRelContainedInSpatialStructure','IfcRelFillsElement','IfcRelVoidsElement']
        elif self.elementType == 'IfcSpatialZone' or self.elementType == 'IfcSpace':
            return ['IfcRelAggregates','IfcRelContainedInSpatialStructure','IfcRelFillsElement','IfcRelVoidsElement','IfcRelSpaceBoundary','IfcRelReferencedInSpatialStructure']
        elif self.elementType == 'IfcZone' or self.elementType == 'IfcGroup':
            return ['IfcRelAggregates','IfcRelContainedInSpatialStructure','IfcRelFillsElement','IfcRelVoidsElement','IfcRelSpaceBoundary','IfcRelReferencedInSpatialStructure']
        else:
            return ['IfcRelAggregates','IfcRelContainedInSpatialStructure','IfcRelFillsElement','IfcRelVoidsElement']   

What needs to be included into includeRelationshipTypes may be tuned to the source model data and the elementType, - here an IfcBuildingStorey

Processing

We will use standard features of a database

• temporary table creation populated by the result of a query
• recursive query to find all 'descendants' of the Storey.

The processing is outlined hereunder:

1. Get the header of the bundle (all ifc's have a header); but we could also create a new one from scratch
2. Get the container, i.e. 'Spatial Unit', e.g. the storey
3. Get the parents of the container with respect to the IfcRelAggregates hierarchy (if the container is e.g., a storey, the parent is usually the building, then the site, then the project). We could possibly attach the selected Storey to the projet, but it's safer to have the hierarchy if relative positioning of elements is the default in the model
4. Get all 'children elements' of the container, and their own 'children', etc. where the 'children' are the elements that are in a graph where 'parents' are the relating elements and the 'children' are the related element in a relationship and 'descent' from the container. For those, we will not get the propertySets, as they are not descendent of the container in the graph. This will be addressed later on.
5. For each element that is a product, we need to get all representations if any
6. Now that we have all elements (except propertySets), we need to look at the elements that are referenced in one of the elements that we have but are NOT already part of the elements that we have. We need to include these elements.
7. We need to get all propertysets which are related to the container or to the elements in the container; there, the properties are the relating elements and we only need to look at properties that have a related element in the previous list of elements. The attention point is that the IfcRelDefinesByProperties will list entities that are not related to the container. We will need to prune these extra references.
8. Now that we have all that is needed for a model, we build an ifcJSON
9. And convert it to an IFC(Step file).

View with BIMcollab of extracted Level 1 of Duplex_A_20110907_optimized

We have the elements that we had in IfcPatch (above), but now we also have the stairs.

Additionally, with the misconfigured walls in the source IFC we also gained the doors of those walls under 'Unreferenced items' .

View with OpenIFCViewer of extracted Level 1 of Duplex_A_20110907_optimized

Compared with BIMcollab, we don't see 'Unregistered items', hence, the erroneously registered walls don't get their doors.

View with That Open of extracted Level 1 of Duplex_A_20110907_optimized

The screen capture hereunder has been obtained by selecting the Level 1 storey. In that case we miss the display of the stairs.

Remarks and to do

We can notice the difference in rendering. That Open does not show the stairs in the view of Level 1 although the stairs are present in the IFC(STEP file). That Open displays the spaces representation as such. With the opacity, it's not possible to see through. But eventually, a stair can be viewed by entering into the space that contain it (with a tricky and uneasy navigation).

That Open display without selecting Level 1. The spaces are visible

That Open display without selecting Level 1. Toggling the dipslay of the space A105

That Open display without selecting Level 1. Getting into A105 to see the Stairs