Is it possible when using the relation IfcRelSpaceBoundary (2nd boundary) to know the linked spaces.
eg see figure with the wall in the middle and spaces A,B,C and D:
Is it possible to determine from IFC that space (A,C), (B,C), (B,D) are linked? Or is it only possible to know that the wall is linked with the different spaces but not possible to know for each part (1,2 or 3) of the wall to know the 2 linked spaces?
Yes, it is possible.
If you check IFC4 documentation at IfcRelSpaceBoundary2ndLevel you will see that a property CorrespondingBoundary is supposed to be filled by the authoring tool. If you want to handle also IFC 2x3 and authoring which don’t fully do their job you need to do some computation to find which boundary is on the opposite side.
Hint :
BoundedBy
ProvidesBoundaries.Yes, you can do this through following the relationships between (IfcSapce)-(IfcRelSpaceBoundary)-(IfcSpace) and inverse relationship attributes like relatingSpace, BoundedBy and further more you can include the existing doors to find all paths between spaces.
I did this through converting IFC models to Graph database (neo4j) and the graph query languge Cyhper.
Have a look at this presentation for example: https://www.slideshare.net/AliIsmail7/convert-bim-ifc-models-into-graph-database-neo4j-based-on-ifcwebserverorg ( Slides 20-25)
and for more details this conference paper:
https://www.researchgate.net/publication/318600860_Application_of_graph_databases_and_graph_theory_concepts_for_advanced_analysing_of_BIM_models_based_on_IFC_standard
Ali Ismail
Thanks both,
In my specific case I’m exporting from Revit and it looks like CorrespondingBoundary is not present in my IFC STEP file.
Here is a part of the IFC file:
Only IfcRelSpaceBoundary is available:
The first number (740) references to the space.
The second numbers (4265, 4336, 5977, …) references to the building element (IfcWall, IfcSlab, IfcWindow,…)
The thirth numbers (761,816,830, …) references to the IFCCONNECTIONSURFACEGEOMETRY (geometry of the building element)
No IfcRelSpaceBoundary2ndLevel is available in the STEP file.
So I suppose Revit doesn’t export this relation and according CorrespondingBoundary?
Yes this is a problem we have come across. A lot of our workflows start with Revit for massing and other geometry creation, so Revit seems best placed to generate the boundaries and spaces for BEM. However we have been unable to extract the correct IfcRelSpaceBoundary derived type from Revit IFC export as of yet.
It may be possible through some form of Revit IFC export customisation, but I am personally yet to see it actually spit out an IfcRelSpaceBoundary1stLevel or IfcRelSpaceBoundary2ndLevel object type. It does indicate the boundary level in the description, but inner boundary information would be absent for level 1 boundaries, and adjacency information would be absent for level 2 boundaries as these are attributes of the derived object types and not IfcRelSpaceBoundary.
In the past, I worked with some people at IES (https://www.iesve.com/) to come up with an IFC-based workflow. In the end, we found a great number of issues that I think could be addressed for IFC4.x, but definitely should be for IFC5:
Space boundaries should be explicit object classes, not just a specialized relationship. I would propose deprecating the existing IfcRelSpaceBoundary… classes and:
a. IfcSpaceBoundary, but no IfcSpaceBoundaryType - maybe use the existing https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC1/HTML/link/ifcrelspaceboundary.htm and modify it as follows;
b. An attribute/enumeration that indicates “SurfaceType”, “GROSS” or “NET”
c. An attribute that indicates “Level”, as a real number, e.g. 1, 2, 3, etc.;
d. The attachment of IfcMaterialLayerSetUsage via IfcRelAssociatesMaterial from the corresponding IfcWall or IfcSlab;
e. Attachment of IfcMaterialConstituentSet for IfcDoor or IfcWindow or IfcOpening to IfcSpaceBoundary.
Modify IfcSpace to include a “NET” vs. “GROSS” enumeration, as well.
I think this would add enough power and flexibility to allow different types of BEM analysis engines to make use of any combination of use case factors including:
What do you @cordell and others think?
Hi @jwouellette ,
I think some of those proposals would be very advantageous, certainly in regards to boundaries. If I understand you correctly, this means boundaries would not be limited in their capability or scope as they currently are, as they would have all the benefits of an explicit object type such as geometric representation and property sets?
Having property sets would allow much richer information to be associated with boundaries allowing the ability to be used with multiple calculation engines (and even different disciplines? If it may be useful?). This would certainly allow movement up and down stream for BEM’s which current seems a bit difficult as energy analysis needs to be done in it’s own ecosystem due to the lack of detail IFC can persist for it. One of the main problems (at least my understanding so far) is data needs to be repopulated for the various BEM’s at different stages/tools in the workflow, and is then subsequently lost/discarded when finished with which seems wasteful and time consuming. So this would really push IFC forward as an exchange format for energy analysis I think.
More level types, and types defined as attributes is definitely a good move to. Currently, there is a real loss of precision with the data as everything is packed into a limited/restricted data type, and detailed information (such as thermal bridges etc) is lost being lumped into a single scalar ThermalTransmittance property value (I think I’m right in saying this is L3 are thermal bridges? but please correct me here if I am wrong?).
I’m more data driven (lacking knowledge and expertise in the disciplines… I leave that for the engineers to tell me) so advocate more of a federated model approach (including holding multiple boundary types), however I can certainly see the benefit if users wish to concentrate just on subsets of the data. Decoupling something such as a BEM for usage without all the overhead of the building element geometry etc would definately be a good (I guess this would be similar to gbXML but within an IFC environment?).
Certinaly feels a step in the right direction for IFC5!
I guess this is a bit more difficult to faciliate in IFC4.x though?
I will suggest this to (engineer) collagues to see what they think. Currently they are at the mercy of the data I can provide them for the calc, and I am at the mercy of the data that I can either get from upstream or generate from IFC (the latter being the only way to really add value at the moment). It would make my life easier thats for sure 
“NET” and “GROSS” are not the same in every country. It sometime changes from a standard version to another in the same country. There is also other types of area eg. in Switzerland we have a “energy reference area” which is neither “NET” or “GROSS”. It exclude some space and has specific rules for limitation as a minimal 1 m height.
Without building element geometry ok. But you still need others building element information (Ifc class at least but I am sure some others I don’t think of).
I am afraid of information repetition. From my understanding IfcRelSpaceBoundary is here just as a specialized relationship as you said. Difference between “NET” and “GROSS” is just a different area/geometry but other information are the same. A way I could see your proposal as an advantage is for making a simplified FM or energy model to forget over-modeled details. But this subject is tough. I think it is very difficult for an authoring tool to generate a simplified model from a complex one without unwanted loss.
Yes ! We need thermal bridges 
!
@Cyril thanks for the feedback!
I think solving the issue of NET and GROSS standards can be handled with IfcClassificationReference, where the standard used for measurement is indicated. In my experience, the BIM authoring tools are able to make such adjustments and accommodate different rules. This comes from the work that the US GSA (along with the Norway Statsbygg) did over a decade ago in developing BIM guides for Spatial Program Validation and Building Energy Analysis. This is also the same methodology proposed for Quantity TakeOff and Costing workflows.
Agreed that it is a difficult topic, which is why I am trying to finish up a report on moving BEM IDMs/MVDs forward in the buildingSMART community. There are so many pieces to this issue that there needs to be some hardcore, unified, international working groups to bring some consensus-based “best common denominator” proposals forward. I’m not sure we can have a single set of universal data exchanges (MVDs) using IFC for BEM, but maybe we can get the experts, end users, and software developers to come to an agreed framework and set of principles that guide the creation of data exchange standards.
hi @jwouellette,
is this report available somewhere? I would be curious to read it. in my experience moving from a detailed BIM to energy modelling is a painful process right now with a lot of duplicated manual work and loss of result granularity, as it was also mentioned above.
Almost finished. We’re trying to schedule the Expert Panel Call for Participation (next week?). At that time, we will make the report public.
