Does the use of IfcMappedItem always have to be through a IfcTypeObject?

Does the use of IfcMappedItem always have to be through a IfcTypeObject?

Or can a non-typed IfcProduct also use IfcMappedItem in its shape representation?

Last time we discussed something about that. It’d be nice to clarify.
Must MappedRepresentations come from the corresponding IFC Type? - Developers - buildingSMART Forums

I do not know any formal schema restrictions but CV2.0 and RV certification test-cases require type object for mapped representation.

@igor.sokolov there is a “formal” schema restriction in the form of the concept template diagram in IFC4 docs (linked in the original question @claimred referenced).

Informally, however, the word “may” is used in certain texts.

Also see pending issue where portions of the concept diagram were erroneously lost in IFC4X3: Mapped geometry concept diagram is missing the reldefinesbytype · Issue #382 · buildingSMART/IFC4.3.x-development · GitHub

I think, given the formality of the concept diagram and in certification test cases, and confidence provided in IFC authoring (i.e. the user can confidently and safely assume that all typed instances share the geometry of the type) we should make the answer “Yes”.

1 Like

As @Moult wrote “However, I have not seen any where rules or codified constraints in the EXPRESS that reflect this.”
This is exactly what I mean - diagram is only illustration how can it be used but it does not marked as “required”

Anyway, there should not be a problem for exporter to create type object reference and I do not see any reasons preventing this, so I would say exported has to create.
Other hand, for importer I would assume type object may be missed and it should work robust without this.

Isn’t this two different points:

  • Does TypeObject require the usage of MappedItem?
  • Does MappedItem require the usage of TypeObject?

For the second questions, we have to keep in mind that not all elements have associated typeobjects (but perhaps it’s not crazy to suggest they shouldn’t use mapped representations).

But also, MappedItems do not necessary have to point to another product. One could also use mapped items to instantiate multiple items within the same representation.

MappedItems can also result in geometric transformations that would (in my view) require a different type object to be supplied (such as mirroring and scaling)

Since IFC4 possible to assign a IfcProductDefinitionShape to multiple Products. This is my view is a much simpler way of establishing how Type-Product geometries are related.

For IFC5 it’s seriously being discussed to move the geometry to the type object.

Therefore, my view on all of this is: We can’t really restrict these kind of things too much without introducing backwards incompatibility. MappedItems are, in my opinion, the wrong abstraction to describe Type-Product geometries, anyway.

I’d propose to clarify wording and recommendation in the docs where needed, but not making any schema changes, and come up with proper, easily understood mechanisms for IFC5.


Just to share, there are a lot of examples out there of peeps using IfcMappedItem without a type.

1 Like


1 Like