buildingSMART / buildingSMART/IFC4.x-development
Documentation to clarify if MappedRepresentations must come from the corresponding IFC Type?
- Dominant language
- Python
- Stars
- 234
- Forks
- 123
- Avg merge
- 15h 4m
- Merged PRs (30d)
- 5
Description
Originally posted https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361 and quoted below.
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](http://localhost:8000/schema/templates/product-type-shape.htm)** at the **corresponding product type,** as **defined by the concept [Object Typing](http://localhost:8000/schema/templates/object-typing.htm)**.
(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](http://localhost:8000/schema/ifckernel/lexical/ifcreldefinesbytype.htm).
> 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](http://localhost:8000/schema/ifcrepresentationresource/lexical/ifcshaperepresentation.htm) and having Items of type [IfcMappedItem](http://localhost:8000/schema/ifcgeometryresource/lexical/ifcmappeditem.htm).
(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:


... 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?
Contributor guide
Research direction
Start with IFC documentation sections 4.8.2.13, 5.1.3.49, and 8.9.3.49, then inspect the related Object Typing and Product Type Shape concepts, diagrams, examples, and EXPRESS rules. Compare the three listed scenarios with the documented constraints; done means the intended requirement and any missing or non-codified rule are stated unambiguously.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100