Bonsai not having IfcFacilityPart, only IfcFacilityPartCommon

MahshidMotie

Hey people :)
Is there a reason why Bonsai doesnt let IfcFacilityPart creation?

theoryshaw

Because it's an 'abstract supertype'. An abstract supertype is a class (or entity) that cannot be instantiated directly in a model...it exists to define common attributes and relationships that are shared by its subtypes
https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcFacilityPart.htm

All the following are a subtypes of the IfcFacilityPart supertype...

jwouellette

One issue:
While IfcFacilityPart is an abstract, like many others (e.g., IfcRoot, IfcObject, IfcTypeObject, etc.), there is still a need to be able to edit/apply values to attributes (e.g., IfcSpatialStructureElement.CompositionType) from which the instantiated object/container (e.g., IfcFacilityPartCommon) must inherit.

How is that best handled in Bonsai?

Moult

You should be able to edit all attributes including inherited ones. Is it not showing up in your attributes panel?

steverugi

@jwouellette

While IfcFacilityPart is an abstract, like many others (e.g., IfcRoot, IfcObject, IfcTypeObject, etc.), there is still a need to be able to edit/apply values to attributes (e.g., IfcSpatialStructureElement.CompositionType) from which the instantiated object/container (e.g., IfcFacilityPartCommon) must inherit.

How is that best handled in Bonsai?

maybe like this? I'm too trying to figure out infraworks spatial breakdown with IFC4x3..

more info on IfcFacilityPart can be viewed by expanding the part:

steverugi

I take this opportunity to highlight that, my interpretation of what indicated in the IfcBridgePart page, an IfcBridgePart can be embedded in another IfcBridgePart, seemingly not available in Bonsai atm
the condition for such decomposition is that the parent one must have "COMPLEX" -> with child = "ELEMENT" as CompositionType, or "ELEMENT" -> "PARTIAL"

please see the following:

@Moult kindly advise, should I report it as an issue? thanks

jwouellette

In the US, we're revisiting how Bridges and all their parts are best represented. Our latest proposals:


We are clear, and have verified with bSI, that the "Optional" scenario works, but we're more interested in the new "Primary" and the use of IfcFacilityPartCommon... which doesn't have a parent IfcFacility.

Moult

@steverugi The rules of what is allowed to be contained in what is taken from 4.1.4.1.4 Spatial Composition of the IFC documentation. According to that document, indeed IfcBridgePart is not allowed to be in another IfcBridgePart. This contradicts what's in the IfcBridgePart documentation. So it's either a bug in the IFC documentation, or a bug on our end, or both. I suspect it's both, as historically CompositionType has always allowed decomposition of the same class. I'll file a bug with buildingSMART, and please also file a bug on our end to support it.

https://github.com/buildingSMART/IFC4.3.x-development/issues/956

@jwouellette your issue is similar to what @steverugi mentioned - the buildingSMART specification 4.1.4.1.4 does not allow a IfcFacilityPartCommon to be inside an IfcSite, and therefore Bonsai doesn't allow it either. The entire interface in Bonsai is built to follow the spec quite strictly, so if you'd like to deviate here the best thing to do is to run a script in the built-in Blender Python console which can override the constraints of the interface. Let me know if you'd like to go this route.

steverugi

Hi @Moult thanks for your feedback, much appreciated

so if you'd like to deviate here the best thing to do is to run a script in the built-in Blender Python console which can override the constraints of the interface.

I did share something similar in my post here

issues/6709

cheers