Hello all, I have seen some files that have multiple IfcShapeRepresentations of type “Body”. It seems to me that this is ambiguous - should import have those are alternate body representations, or should they be combined into one “Body” representation? Is there any documentation on this? I haven’t been able to find any.
good point - I recall, that a product can have multiple shape representations, but each shape representation shall have a different RepresentationIdentifier. But I could not find an equivalent note in the documentation.
N.B. when looking into it, we should also clarify the potential overlap of the meaning of RepresentationIdentifier and the link to a proper IfcGeometricRepresentationSubContext. See e.g. Figure 454 — Example of using geometric representation contexts at IfcGeometricRepresentationContext.
Right - I think there is some ambiguity at the moment as to whether this is allowed or not, and if it is allowed (since there doesn’t seem to be any documentation to the contrary), if it is intended to represent two different Body representations or if they are intended to be combined into one, as I mentioned in the original post.
On the issue tracker we have this highly related item about for a product not to have multiple reps in the same context.
And also this one, which talks about the relationship between IfcShapeRepresentation.RepresentationIdentifier and IfcShapeRepresentation.ContextOfItems.ContextIdentifier
It would be great if we can review these two with renewed energy, because indeed this is something quite elementary yet vital and I think we all agree on the direction.
My proposal would be to add two where rules (and adapt wording of text accordingly):
- On (Shape)Rep: RepresentationIdentifier equal to ContextOfItems.ContextIdentifier
- On ProductDefShape: No duplicate RepresentationIdentifier in Representations
Thoughts?
I would agree with this.
For the second rule I’d propose
unique r.ContextOfItems for r in ProductDefShape.Representations
instead of
unique r.RepresentationIdentifier ...
This would be in line with what is stated in ISO 10303-43 informally, see this discussion about a file with representation items pertaining to the same identifier, type and context split across different representations. Requiring unique context would still allow for multiple representations assigned to different sub contexts that differ in scale or target view, but have the same identifier.
1 Like
Excellent point.
My guess is that quite a bit of implementations will still run into issues when they have multiple plan/body representations for contexts with different scales. But since this aspect is hardly used anyway, I guess it’s safe to still make this schema restriction useful. And I think it’s indeed a better interpretation of how contexts were envisioned.
Off the top of my head this would be (one of) the first where rules where we compare complete entity instances as opposed to single attribute values so we need to carefully look up the semantics to see if we’re not doing something wrong.
Curious to hear what the others say
In my perception Box, Axis and Body representations may by in one 3D Model geometric context.
Similar, I may want to have some representations of an element with different levels of detailing but show them in the same type of view.
1 Like
While that’s nice to have functionality, I don’t see a clear way how the current schema supports that. How would a consuming application be able to select the appropriate LOD for example? Without having to first evaluate all LOD representations to come to that conclusion and hence increasing file size and load time. Wouldn’t it be better to make this an export setting and not at runtime (and to use the Box if you want a low LOD at import at all costs).
In my perception Box, Axis and Body representations may by in one 3D Model geometric context.
That does appear to be the case in some files I checked at least for Axis and Body, so this does not appear to be a practical backwards compatible change. Unless we stick to only:
- On ProductDefShape: No duplicate RepresentationIdentifier in Representations
Which would still address @angel.velez original concern and be an improvement of the clarity of the standard if you ask me.
We are using RepresentationId to specify intention of representation: “Box” and “Body”.
We may use more. “Box”, “Body low details”, “Body high details”.
This is subject of MVD, not schema
About Axis: You have geometric context. Axis can share context with Body or be in another context.
Example: physical and principal axis representation for electrical wires.
A wire can have 2 axis in 2 different contexts.
I’m not too convinced that this is the intended use of RepresentationIdentifier. But I don’t have hard arguments. Identifiers are supposed to be computer readable (so not suffixes like low/high detail). But the type is IfcLabel and not IfcIdentifier. So the intention there is a bit vague.
Multiple representations of different views on an element is a recurring theme. A space geometry could have a Body volume from the viewpoint of Gross area, Net area, Thermal interfaces. Etc.
It could be we decide that Representation Context is the way to deal with that, but that probably would mean that it needs to be a higher level more visible construct (e.g psets, rooted, etc.).
We can also decide to handle this kind of detail like some special form of element to element decomposition in which case the information is already more readily comprehensible by the end user.