IfcConnectionGeometry

[hlg]

I guess this is more an IfcOpenShell feature request, but I am first posting it here, since I currently only use IfcOpenShell through the BIMserver render plugin.

Currently, geometry is only generated for instances of IfcProduct from the respective product representations . Every attempt to get triangulated geometry for other objects results in a null pointer since it is not generated. However there are other entity types with geometry associated, in particular some IfcRelationship subtypes that have connection geometry. Below is a list of types and attributes.

• IfcRelInterferesElements.InterferenceGeometry
• IfcRelSpaceBoundary.ConnectionGeometry
• IfcRelConnectsElements.ConnectionGeometry
• IfcRelConnectsWithEccentricity.ConnectionConstraint

I believe that this is a limitation of IfcOpenShell and do not know whether @aothms wants to tackle this, but before requesting it there, I want to ask whether you would consider to store triangulated versions for these connection geometries in BIMserver at all. I reckon you already made some decisions about which kind of geometry to store and which to exclude, since normalized 2D (plan) geometry seems not to be included, although IfcOpenShell can handle those.

[rubendel]

Thanks for the information. I didn't even know you could have geometry attached to non-IfcProduct types, so definitely not a design decision ;). Do you know if that's something new in IFC4, or was it possible in Ifc2x3tc1 as well?

2D sounds cool too. I'll chat with Thomas about this when I speak to him. We were planning to have IfcOpenShell generate geometry on a per RepresentationItem bases as well, to have more flexibility and reuse.

[aothms]

Once you have geometry per-representation-item, you automatically get support for connection geometry as they eventually all point to the same set of geometric types.

Complications of per-item geometries, is that not everything is defined there (most notably openings, materials, layersets, placements are linked at the product level).

What I do not like about the way connection geometry is implemented is that the relation to a placements is super obscure (I don't understand why they are not just an additional category of virtual products, but that's another storey).

In short: this is all possible in the current IfcOpenShell code base, but we'd have to figure out a way to still have openings and all in a reasonable straightforward api.

[hlg]

Only IfcRelInterferesElements is new in IFC4, supposed to relate overlapping elements (for clash detection results?). The other three have been there before.

Yes, true, connection geometry references only representation items, and switching to per-item geometry would half-solve this. Happy to hear that you are thinking about this.

After poring over this for a while now I find that the way these connection geometries are modelled actually makes sense. All those relations relate two subtypes of IfcProduct that are supposed to have their own geometric representation. Under the assumption that the relation between the two products somehow manifests in their geometry, the connection geometry attached to the relation just references those parts (i.e. representation items) of the relating and related product, that are "affected" by the relation. It becomes a bit weird though when the connection geometry representation items are not actually contained in the product representation and as far as I am aware this is perfectly legal because there is no express rule enforcing this containment.