I noticed something related to spaces' properties export to IFC 4 that doesn't make much sense in my opinion. Maybe someone can explain why it is like this.
The IFC element type "ifcSpace" has some attributes related to space naming:
When exporting from OBD it looks like the properties "Space Number", "Label" and "Label2" are used to populate those ifc attributes. However it's not a 1-to-1 mapping:
It appears to be very confusing at first glance. I fail to see the logic for "Description" and "LongName". I'd expect the LongName to look at "Label" first, and description to use "Label2". Or is this just me?
When creating spaces from the Program Manager only the value for "Label" is populated. I'd expect the space number to be equally important (or even more important) since it's the unique identifier, right? Is there a way to number them chronologically based on the program manager? Maybe for each "group" in the program manager set a prefix, for example "0." for ground floor, ...?
Hi Johan,
The logic of this is driven by the IFC specification, we will look for further explanation to post here.
Marc
Hi Marc, any updates?
Hello Johan,
The IFCSpace attributes are driven by a .set file. The .set file is "C:\ProgramData\Bentley\OpenBuildings CONNECT Edition\Configuration\Datasets\Dataset_NM\Setting\IFC_PropertyMapping.ifc4.set".
Regards,Alifur
Thank you Alifur!
This indeed let's me control which OBD properties are mapped to which IFC properties.
Still, I'd be curious to hear the reasoning why it has been implemented this way in the NM dataset?
I can see the same thing for all the other datasets too. Will try to get an Explanation from the dev team.