Is IfcProductDefinitionShape a 1:1 relationship?

The documentation states:

The IfcProductDefinitionShape shall be used to provide a representation for a single instance of IfcProduct.

However, it also states the ShapeOfProduct attribute has a cardinality of S[1:?].

Why is there a conflict?

In 2x3 this was SET [1:1] https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/ifcrepresentationresource/lexical/ifcproductdefinitionshape.htm

So while the schema was updated, the attribute description wasn’t. PR would be appreciated :slight_smile: https://github.com/buildingSMART/IFC/blob/master/Sections/Resource%20definition%20data%20schemas/Schemas/IfcRepresentationResource/Entities/IfcProductDefinitionShape/DocEntity.xml#L10

So it is possible to reuse shapes by reusing the IfcProductDefinitionShape? (As opposed to going through the whole mapped geometry tree)

If so, that adds to the list of possible ways to reuse a shape:

  • Through reusing the IfcRepresentationItem
  • Through mapping the IfcShapeRepresentation
  • Through reusing the IfcProductDefinitionShape

… is this a few too many ways? I haven’t yet come across a BIM authoring vendor which has been able to preserve the full fidelity of the shape representation reuse tree.

How do other implementers feel? @jonm? @angel.velez?

My gut feel is that buildingSMART could simplify the representation assignment and transformation procedure to be more similar to tried and proven scenegraph paradigms without much loss of functionality.

I would support an official (IFC5) method of simplifying how we reuse geometry, and have 1 way that works for all cases. I don’t want to add another way of doing it in existing schemas, even if it is "nicer’, because in practice that just adds more complexity, as you have to support existing ways and a new way.

As far as “I haven’t yet come across a BIM authoring vendor which has been able to preserve the full fidelity of the shape representation reuse tree.” - that’s a huge philosophical can of worms. There is no current IFC4 MVD that actually even supports that workflow. Almost everything that’s been done to promote preserving parametric information has been over and above what IFC officially supports. Again, I’d rather see extending IFC5 in a meaningful way that supports design transfer for the cases that need design transfer, instead of bespoke solutions.

2 Likes