Although IfcBuilding is of IfcSpatialElement subtypes, it has or can have a geometric representation. While the walls, storeys and roofs(subtypes of IfcElements )have their own geometric representation ,and almost always will have, I have witnessed that not always the IfcBuildings gets that representation directly but only through its elements.
Now my question is:
from the semantic point of view, what would be the correct way to add a representation to an IfcBuilding entity:
-all the geometries of walls and floors that construct the building
or
-external surfaces of external elements hence the building envelope
or
else?
1 Like
I have used it to store the building envelope of context buildings, where the full breakdown is not necessary.
1 Like
@KavehAll I would concur with @Moult regarding the use of IfcBuilding. In the past, for IFC2x3, there was a formal agreement that the Coordination View was (1) project, (1) site, (1) building, then building storeys and elements. Informally, I believe that large models with site containing extensive context could contain multiple instances of IfcBuilding, but those would be represented by simple “blocks” of extruded footprints or planar/tessellated geometry. These simple representations would NOT have door, window, wall, slab, etc. objects. There is no real restriction against multiple, fully-detailed building on a single site, nor against multiple sites. Such a decision really needs to be indicated in the MVD.
2 Likes
Another interesting use case in that regard would be to store the [domain/subdomain, topic category] envelope of buildings/infrastructure in an urban-scale modelling use case.
For other non-hierarchical IfcSpatialElement cases, the IfcSpatialZone should be the one to use, which has in this case its own shape representation, instead of subtypes of IfcSpatialStructureElement.