Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation to clarify if MappedRepresentations must come from the corresponding IFC Type? #5

Open
Moult opened this issue Feb 22, 2022 · 5 comments

Comments

@Moult
Copy link
Collaborator

Moult commented Feb 22, 2022

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 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|690x243

image|500x480

... 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?

@TLiebich
Copy link
Contributor

actually such a must was not intended. The specification is meant to be flexible. It also allows e.g. to have types with no corresponding occurrence in an exchange. Such a strict interpretation may be in conflict with current implementations and should rather be postponed to a more general rework allowing for less flexibility in IFC5.

So my proposal is to more this issue to the IFC5 log.
There is a related issue about allowing direct use of IfcShapeRepresentation by multiple IfcObject without going via IfcMappedItem/IfcRepresentationMap - this should be considered together with this issue. So I propose to label it als IFC5 issue

@Moult
Copy link
Collaborator Author

Moult commented Feb 23, 2022

Having types with no corresponding occurrence wasn't the issue, the issue is can I have an object that has a type with a mapped representation, but not use it?

@aothms
Copy link
Collaborator

aothms commented Feb 23, 2022

The general (explicit) agreement is also that non-rooted entities don't have a strong identity. So it would not be entirely inline with this to require explicit reuse. It may also negatively impact partial exchanges.

Creating one or more IfcObjects which share a mapped representation

This is definitely allowed I think. Maybe then more for efficiency but not semantic. Like a railing with repeated bars for example.

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)

It may also be necessary for openings. We can associate a 3d opening element, but for 2d representations this doesn't really exist, so then maybe it would make sense to reuse the 3d rep but for the 2d rep bake the opening into the curve footprint.

I don't see an issue with the wording. "May" is maybe not ambiguous, just non-normative? Or did I miss a deeper meaning?

@TLiebich
Copy link
Contributor

Having types with no corresponding occurrence wasn't the issue, the issue is can I have an object that has a type with a mapped representation, but not use it?

definitely yes (not saying that it is the best solution, but current practise)

@Moult Moult added onhold and removed onhold labels Feb 23, 2022
@berlotti berlotti transferred this issue from buildingSMART/IFC4.3.x-development Mar 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants