Although the composition attribute was made optional in IFC4 for IfcSpatialStructureElement, the description within the derived classes suggests this isn’t advised when nesting instances of a common type. Ie a complex site decomposed into element sites. http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/link/ifcsite.htm
I don’t see where rules enforcing this, and I’m questioning whether the documentation needs revision.
I’ve been discussing with government agencies the three level restriction imposed by forcing parent sites (or facilities) to have a different and higher CompositionType. We’d prefer that this restriction wasn’t in place for representing a network.
I’d like to understand the reasoning for imposing the restriction, and whether this might be relaxed for IFC5 or newer versions of IFC4.
From the IFC4Add2 spec, I see that a project can contain multiple sites.
A project may span over several connected or disconnected sites. Therefore site complex provides for a collection of sites included in a project. A site can also be decomposed in parts, where each part defines a site section. This is defined by the composition type attribute of the supertype IfcSpatialStructureElements which is interpreted as follow:
COMPLEX = site complex
ELEMENT = site
PARTIAL = site section
This allows a project to have multiple direct child sites, all of which are at whatever CompositionType level you choose - this is an “equal” network of sites. I only mention this as a temporary workaround because “if you can’t go deeper, go flatter!” might be something to consider if BSI has some special reasoning behind only having 3 levels deep of site decomposition.
But yes, that sites are restricted to 3-levels with some arbitrary hierarchy of enums doesn’t sound right to me. +1 to have the restriction removed.
As for the documentation, you are correct, there there is no where rule, and so the documentation looks incomplete / incorrect.
This is also mainly legacy - when it was mainly for buildings with many building domain specific BIM authoring tools, that have limitations in supporting deeper project breakdown structures. In my view:
such restrictions should be lifted on the general level of IFC (including a deprecation for the attribute itself)
if needed, such restrictions are to be added at the level of an MVD (and for an MVD certification process), and it could be done specific for each subtype of IfcSpatialStructure
n.b. we need to establish a place where such schema change requests are collected.
@TLiebich I think the intent was to start such discussions of issues here and then create a formal “issue” in GitHub once a consensus was reached on 1) what the problem really is and 2) what the best possible solution may be.
We need to follow up on getting the appropriate GitHub repositories set up and then eventually we can implement a link between the Discourse topic and the GitHub issue.
This was discussed a lot in IFC Bridge with no final resolution. It is being further discussed in IFC Road.
My opinion, the restriction is not necessary. But, modelling everything as an ownership does not make sense either. Site - Facility - FacilityPart - (Space) is already with 3 levels per node 12 levels deep. Where is such a deep tree needed? Also, not every relationship is an ownership/aggregation e.g. road passing a bridge. I was proposing a less strict relationship where the nature of the relationship can be determined individually. LandInfra does it like this:
7.3.1.4 Facility Part Relationship
Facility parts may be related to each other, such as a road connecting into a roundabout or a road being supported by a bridge.
relationship : the relationship between one part and another (e.g., “connected-to”, “supported-by”) description : supplemental information describing the relationship facilityPart : the FacilityPart that this FacilityPart is related to
I an internal discussion last week with my colleagues, we were discussion the need of large inheritance trees, but on the level of aggregation implementation can often be rather trivial and generic: a “parent-child” relation is all you need for an infinitely deep aggregation tree. E.g. look at SceneGraphs in 3D software systems. You just attach elements to their parents and you have immediately the possibility for aggregation, grouping and decomposition.
if BSI has some special reasoning behind only having 3 levels deep of site decomposition.