SpaceBoundaries - change IfcRelSpaceBoundary to IfcSpaceBoundary

Activities & Projects IFC4.3 Building Room - Building Domain Review
1

Although the topic of space boundaries has unfortunately not made it into the new IFC4.3 release (see old thread), I would like to place it here as an issue for the next release:

The entity for space boundaries IfcRelSpaceBoundary is defined as a subclass of IfcRelationship in the IFC schema and is therefore NOT an IfcObjectDefinition. However, the relations IfcRelDefinesByType and IfcRelDefinesByProperties required for the assignment of information to instances can only be assigned to IfcObjectDefinitions - this also applies to weaker relations such as IfcRelAssociates.
It is therefore not possible to use the IfcRelSpaceBoundary entity to assign information to parts of elements (such as walls, slabs, …), although this would be very helpful in the context of building physics calculations e.g. building energy modeling and simulation.
Therefore, my suggestion would be to change the definition as follows:

ENTITY IfcRelSpaceBoundary IfcSpaceBoundary
SUPERTYPE OF(IfcRelSpaceBoundary1stLevel)
SUBTYPE OF (IfcRelConnects IfcProduct);
...
END_ENTITY;

Matching adjustment will be necessary for the subclasses IfcRelSpaceBoundary1stLevel and IfcRelSpaceBoundary2ndLevel

2 Likes
2

@ElisEck I mostly agree.

The only adjustment I might make to your specific proposal is:

So that the 1st and 2nd level space boundaries are read as direct instantiated subtypes. Or you make 1st and 2nd level as enumerations of IfcSpaceBoundary and it is no longer an abstract, but a direct instantiation.

The problem is, the Spaces Boundaries are really analytical surfaces and not “elements” or “products” themselves… although some have argued using SBs for the depiction of finishes. But IfcStructuralItem (a superclass of IfcStructuralMember and IfcStructuralConnection) is considered a subclass of IfcProduct and IfcStructuralAnalysisModel is a subclass of IfcSystem. So, your proposal would be consistent.

What I’d like to consider is a revamping of the analytical concepts of the schema, mainly used for structural purposes to include BEM and other potential analytical concepts (like Fire Safety, pedestrian movement, traffic movement, geotechnical hydraulics, etc.). Maybe, in the current paradigm, all analytical concepts should be subclasses of IfcResource (e.g., IfcStructuralSystem, IfcStructuralItem, IfcSpaceBoundary, IfcThermalSystem, IfcOccupancy, etc.). Then the abstract geometries could have their own geometric representation and have corresponding IfcRelConnects to their “physical” counterparts. But this proposal is most likely way out of scope for any IFC4.x proposal.

Sadly, I just don’t think any of this will be addressed any time soon. Maybe it is an opportunity to look at the proposed ECS concept for IFC5 and figure out standardized analytical Entities, Components, and Systems for such use cases.

3

Sadly, I just don’t think any of this will be addressed any time soon. Maybe it is an opportunity to look at the proposed ECS concept for IFC5 and figure out standardized analytical Entities, Components, and Systems for such use cases.

+1

I think there is more or less already consensus on the direction sketched by @ElisEck. It’s just not really feasible to fit this in given compatibility requirements and effort on implementations to do make this switch once for IFC4.x and yet again change to a different encoding in IFC5. We should focus our efforts on IFC5.

In fact, @gschleusner is working on an IFC ECS encoding for the thermal analysis use case. I advise to get in touch.

4

Even if this change is perhaps not realistic in IFC 4.3, I hope even more that it will be considered in IFC 5. I trust that these forum posts will then be reviewed again… @mirbek.bekboliev

1 Like