No documentation to prohibit multiple shape representations of the same context with different representation types

[Moult]

Originally brought up here

It is legal for an IFC product to have a product definition shape that has two shape representations that both belong to the exact same geometric context, but have different representation types (e.g. one as a point cloud, one as a brep).

Even though it is legal, is it intended to allow mixing of representation types per context?

If not, propose to write documentation and / or where rule to prohibit.

[TLiebich]

it should not be allowed. If a product has different shape representations, those have to be assigned to different contexts. +1 for proposing a change - either as formal where rule (or at least as informal proposition).

[Moult]

Upgrading to proposal then. Here's a proposed documentation to add to IfcProductDefinitionShape. I've also added some human descriptions to make it easier for people to understand - since this is one of the first classes implementers read when they try to understand geometry.

Replace this sentence:

The IfcProductDefinitionShape defines all shape relevant information about an IfcProduct. It allows for multiple geometric shape representations of the same product.

... with ...

The IfcProductDefinitionShape defines all the geometric shape representations of an IfcProduct. There may be multiple representations for each product, where each representation must belong to a different representation context. For example, a door product may have one 3D representation which represents the 3D body of the product, which belongs to a 3D body context. The door product may also additionally have a 2D representation which represents the door swing symbol, which belongs to a 2D plan context.

The bolded sentence is the key sentence that restricts the usage.

If someone wants to propose a where rule that might be even better as well :)

[Moult]

@TLiebich to clarify, this change now also explicitly forbids having multiple IfcShapeRepresentations sharing the same context regardless of their geometry type. This makes sense to me, but just thought I'd clarify.

For example:

• Illegal: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context X of Point Cloud)
• Allowed: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context Y of Point Cloud)
• Illegal: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context X of Brep as well)
• Allowed: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep with multiple Items)

[aothms]

We might have to quickly review how that would work with tesselations with may or may not be supplementary provided for example in the case of advanced breps or adv sweeps. Is that an issue or are we not expecting those kind of situations yet in 4.3?

[TLiebich]

how does a viewer then decide, which representation to display? it would have to rely on each IfcShapeRepresentation.RepresentationIdentifier to distinguish (I recall another issue to make it obsolete). Or the semantic definition of IfcGeometricRepresentationSubContext should be enhanced to not only deal with projection and scale dependent sub contexts, but also other differentiations for 3D context.

[TLiebich]

@TLiebich to clarify, this change now also explicitly forbids having multiple IfcShapeRepresentations sharing the same context regardless of their geometry type. This makes sense to me, but just thought I'd clarify.

For example:

* Illegal: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context X of Point Cloud)

* Allowed: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context Y of Point Cloud)

* Illegal: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep, IfcShapeRepresentation with Context X of Brep as well)

* Allowed: ProductDefinitionShape.Representations = (IfcShapeRepresentation with Context X of Brep with multiple Items)

yes, this is my view and interpretation. In the past we also discussed a so called "fall-back" representation, e.g. having in addition to a complex CSG also a lightweight tesselation, in case the receiver cannot resolve the CSG. It however was never fully thought through

[aothms]

yes, this is my view and interpretation. In the past we also discussed a so called "fall-back" representation ... It however was never fully thought through

But it is present in the docs https://github.com/buildingSMART/IFC4.3.x-development/blob/master/docs/schemas/resource/IfcRepresentationResource/Entities/IfcShapeRepresentation.md

Body-FallBack: 3D Body representation, e.g. as tessellation, or other surface, or boundary representation, added in addition to the solid model (potentially involving Boolean operations) of an element

[TLiebich]

yes, it was never fully developed and also depends on the MVD - e.g. for RV, AbRV it should be excluded. More work has to be done here to make it trustable.