Must MappedRepresentations come from the corresponding IFC Type?

Developers
1

There are a number of quotes in the IFC docs that suggest that if an IfcTypeObject (e.g. IfcFurnitureType) have a MappedRepresentation, then all corresponding IfcObject occurrences (e.g. IfcFurniture) must have the exact same mapped geometry. If the IfcTypeObject (e.g. IfcWallType) does not have a MappedRepresentation, then the inverse is true, all corresponding IfcObject occurrences (e.g. IfcWall) must not have mapped geometry.

Supporting evidence (emphasis mine):

4.8.2.13 Mapped Geometry
Elements may have a ‘Mapped Geometry’ representation that reuses the concept Product Type Shape at the corresponding product type, as defined by the concept Object Typing.

(note the ambiguity of the word “may” in the sentence above)

5.1.3.49 IfcTypeProduct
An IfcTypeProduct may have a list of property set attached and an optional set of product representations. Values of these properties and the representation maps are common to all occurrences of that product type. The type-occurrence relationship is realized using the objectified relationship IfcRelDefinesByType.
NOTE The product representations are defined as representation maps, which may be assigned by a product instance through the representation item(s) being an IfcShapeRepresentation and having Items of type IfcMappedItem.

(note again the ambiguity of the word “may” in the sentence above)

In addition to this, the code examples provided in 8.9.3.49 IfcRepresentationMap all demonstrate this map + type relationship.

The following two diagrams also depict this seemingly mandatory relationship:

image
image1384×488 32.5 KB

image

… from reading this, I would conclude there is the intention for this to be mandatory. However, I have not seen any where rules or codified constraints in the EXPRESS that reflect this. Therefore, I have seen applications such as Revit, the BlenderBIM Add-on, FreeCAD and I suspect others too, that actually allow the following scenarios, which supposedly are invalid:

  1. Creating one or more IfcObjects which share a mapped representation, but do not have a relating type.
  2. Creating a relating type with a mapped representation, but the corresponding occurrences do not use this mapped representation.
  3. Creating a relating type with a mapped representation, but the corresponding occurrences only use some, but not all of the representations (e.g. they will map the body, but not a footprint)

… and other various permutations of this.

Can somebody I guess firstly confirm the intention (which from the words seem pretty clear, but it would be good to get a second pair of eyes), and secondly point out where this is defined in EXPRESS, or confirm that it is missing?

2

I have come across files from Allplan which seem to disobey this rule. Can anybody clarify?

3

Good question, clarification would be great.

I’ve always thought about MappedItem as a sort of caching type erasure tool that is completely decoupled from the actual building domain (Products, TypeProducts, etc.) :thinking: . That would, for example, allow authoring software to reuse mapped items from across various product types.

Why not reuse common body parts from some IfcRailings & IfcWalls if the system is smart enough to know that? Constraints (in the form of supposedly invalid scenarios in your post) for RepresentationMap & IfcTypeProduct just feel weird in my head.

4

Slightly tricky as it is non-rooted.

But yes, I have seen it treated as a decoupled thing. I myself used it as such.

However, the more and more I implement IFC as a native authoring tool, I find that this suggested constraint of Type MappedRepresentation + Product must have that same type is actually a very good constraint - and in this case, the less flexibility, the better. It makes life much easier for scripting, deciding default behaviours in product / type deletion, product / type copying or duplication … it is not something I realised prior to trying this out on an actual native authoring workflow.

So, if anybody who has the power to clarify this is reading, I want to suggest that I am heavily in favour of this constraint.