# Must MappedRepresentations come from the corresponding IFC Type? **URL:** \ **Category:** Developers\ **Created:** [February 18, 2021, 12:44am UTC](https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361 "2021-02-18T00:44:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [February 18, 2021, 12:44am UTC](https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361/1 "2021-02-18T00:44:57Z")
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: ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/d/d04dbf11c501c7b15a4429d1b0a8020cfcb8528c.png) ![image](https://us1.discourse-cdn.com/flex016/uploads/buildingsmart1/original/2X/4/44e41e5cf0e6ef16e399078ea184899be1c9def3.png) … 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? ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [March 17, 2021, 7:27am UTC](https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361/2 "2021-03-17T07:27:08Z")
I have come across files from Allplan which seem to disobey this rule. Can anybody clarify? ---
**Author:** ![claimred](https://avatars.discourse-cdn.com/v4/letter/c/e47c2d/32.png) [@claimred](https://forums.buildingsmart.org/u/claimred)\ **Post date:** [March 17, 2021, 2:10pm UTC](https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361/3 "2021-03-17T14:10:48Z")
Good question, clarification would be great. > [@Moult](#): > > 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. 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.) 🤔 . That would, for example, allow authoring software to reuse mapped items from across various product types. Why not reuse common body parts from some `IfcRailing`s & `IfcWall`s 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. ---
**Author:** ![Moult](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/moult/32/196_2.png) [@Moult](https://forums.buildingsmart.org/u/Moult)\ **Post date:** [March 24, 2021, 2:04am UTC](https://forums.buildingsmart.org/t/must-mappedrepresentations-come-from-the-corresponding-ifc-type/3361/4 "2021-03-24T02:04:56Z")
> [@claimred](#): > > That would, for example, allow authoring software to reuse mapped items from across various product types. 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.