buildingSMART Forums

Spatial Composition restraints

#1

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.

Thanks,

Jon

#2

@jonm, apologies if I misunderstand.

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 :slight_smile: 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.

#3

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.

2 Likes
#4

@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.

1 Like