Is it valid to have a single IFC object, where the representation for a single context, say Model/Body/MODEL_VIEW (context/subcontext/target_view), to have geometry that is partially defined as an extruded profile, partially defined as a faceted brep, partially defined as a 2D curve, and partially defined as a point cloud, for example?
The wording the documentation suggests that it is not possible. The wording suggests that each representation must correspond to a single context, and there is a formal proposition that each item in the shape representation must correlate to the nominated RepresentationType.
Note, however, I believe that it is legal to mix representation item types so long as they all fall within the same RepresentationType category. For example, you can mix an IfcExtrudedAreaSolid and an IfcRevolvedAreaSolid. However, my question is particularly for cases where the items beyond a single RepresentationType category.
Can somebody confirm this?
If it is indeed not possible, I think that this is a good thing. There is a little too much freedom sometimes in the geometry possibilities of IFC in my opinion.
Correct, that function is part of the formal proposition. There is no ambiguity there.
I believe, there might be ambiguity in IfcProductDefinitionShape. I see this text for Representations.
Contained list of representations (including shape representations). Each member defines a valid representation of a particular type within a particular representation context.
Perhaps I missed something, but what prevents storage of two representations, both belonging to Model/Body/MODEL_VIEW, and having different representation types (e.g. one is a point cloud, another is an extrusion). How is the consuming software meant to parse it?
I think no, nothing prevents that. To my understanding this would be perfectly in line with the specification, though the representations should be assigned to different contexts. Be aware that contexts can have sub context and apart from the type also have an identifier. Thus you can indeed have multiple contexts with same type, but different identifier. If I’m not mistaken, possible values for these used to live outside the standards document, in implementer’s agreements, e.g. CV-2x3-106.
AFAIK there is no formal proposition to prevent multiple representations with the same context for the same product, even though as I read the underlying standard, it is not allowed. I remember seeing such problematic files, but don’t exactly remember how they were produced. I can look it up, IYI.
As a side note, it had always bothered me how the “type” and “identifier” definitions appear inconsistent for contexts and representations. I will put that in a Github issue if there isn’t one already.