IfcProject Project Representation Context usage

[SergejMuhic]

Shall be fixed (switched) to reflect the actual requirements. Allowed values:

ContextType	ContextIdentifier	Description
Model	3D	Context for all 3D geometry.
Plan	2D	Context for all 2D annotations.

I am sorry not to post a PR but I am unsure of the relationships between usages and templates. Templates seem to feature some documentation that should be on usages and is unmodifiable on Github.

[Moult]

What's the issue?

[SergejMuhic]

ContextType and ContextIdentifier values should be switched according to the table above. As I am not sure where these values are encoded in the new documentation, what a template is and what a usage I cannot do the edit myself.

See https://github.com/bSI-InfraRoom/IFC-Tunnel-Deployment/issues/25 for more details.

[Moult]

It's also not correct, there is no "ContextIdentifier" of 3D or 2D. I'd like to propose to remove the ContextIdentifier altogether, or change the header to "CoordinateSpaceDimension" and make it "3" and "2".

In addition, the description is wrong, for plan it is not just "Context for all 2D annotations" but should be renamed to "Context for all 2D geometry", since 2D can include footprints, profiles, box, body, etc which are not "annotations".

ContextType	CoordinateSpaceDimension	Description
Model	3	Context for all 3D geometry.
Plan	2	Context for all 2D geometry.

[SergejMuhic]

It's also not correct, there is no "ContextIdentifier" of 3D or 2D.

Sure there is: https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcProject.htm#Table-5.1.3.11.Y

I do agree on CoordinateSpaceDimension though. It is already mandatory, just value restrictions related to ContextType are required.

I also agree on 2D annotations. Probably "2D geometry" is a bit too generic but better than just annotations. Question though, what is a 2D body or box? 😕

[Moult]

Yeah I'd say that table is incorrect and is what needs to change. If I see a model come in with a ContextType == "3D" instead of "Model", I'd say that's an invalid model.

In the BlenderBIM Add-on we've been really pushing the usage of contexts to the limits, including using 3D profiles to dynamically generate openings, and various annotations for drawings. I'm of the opinion that it is really unexplored territory and there are many things which could be improved in the context usage definitions, and not to mention very inconsistent usage by all vendors. One of them is the use of 2D bodies. In my opinion, based on how I and others have been using IFC for 2D drawings, I feel that the 2D body should actually .... well ... represent the body of the shape in 2D. So if you have a 2D door symbol, it should belong in Plan/Body/PLAN_VIEW. (I use a ContextType/ContextIdentifier/TargetView syntax as a complete way of identifying context) This is instead of what many other people would say, which is Plan/Annotation/PLAN_VIEW. However a full justification of how I have come to these conclusions is out of scope of this Github issue, but if you're interested I could give you a tour of the problems we've had with contexts and the solutions we've come up with.

[aothms]

This would also invalidate Figure 8.18.3.4.B https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcGeometricRepresentationContext.htm which doesn't mention and 2d/3d (assuming I understand the normative implications of a template like this and how inheritance works).

I took an arbitrary 10k rep contexts I have on disk just to get a sense of what's happening (grep -R IFCGEOMETRICREPRESENTATIONCONTEXT . | cut -d = -f 2 | tr -d ' ' | cut -d , -f 1-2 | head -n 10000 | sort | uniq -c to reproduce)

These are the findings (doesn't add up to 10k due to filtering out the garbage):

   8013 IFCGEOMETRICREPRESENTATIONCONTEXT('3D','Model'
   1642 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model'
     97 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Plan'
     44 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Annotation'
     16 IFCGEOMETRICREPRESENTATIONCONTEXT('Body','Model'
     16 IFCGEOMETRICREPRESENTATIONCONTEXT('Model','Model'
     15 IFCGEOMETRICREPRESENTATIONCONTEXT('BuildingModel','Model'
     15 IFCGEOMETRICREPRESENTATIONCONTEXT('BuildingPlanView','Plan'
      7 IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Model'
      6 IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Design'
      4 IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Sketch'
      3 IFCGEOMETRICREPRESENTATIONCONTEXT($,'MODEL'
      3 IFCGEOMETRICREPRESENTATIONCONTEXT($,'PLAN'
      2 IFCGEOMETRICREPRESENTATIONCONTEXT('ProjectWorld','Model'
      2 IFCGEOMETRICREPRESENTATIONCONTEXT($,'model'
      2 IFCGEOMETRICREPRESENTATIONCONTEXT($,$

So actually 3D is pretty widely used (although it's heavily biased to a certain application being used the most).

I'd say we just shouldn't require redundant data like that.

[TLiebich]

obviously the combined use of RepresentationIdentifyer, RepresentationType and CoordinateSpaceDimension is not well defined in detail. The intended use however is best described in the figure I created a long time ago, when we had the request to also enable 2D model space representations (plan, section, etc.).

It is best decribed in the figure Figure 454 here. ContextIdentifyer is used to differentiate different sub contexts within one "master" representation context. They should correspond with the RepresentationIdentifyer of the geometric representation items, associated to a context.

for Model e.g. "Body" for all 3D shape representations, or "CoG" for all "center of gravity" points (used to validate the correct representation of complext shapes (like CSG).

The other idea was, that the IfcGeometricRepresentationContext should not be used directly by RepresentationsInContext, only the sub contexts. So the ContextIdentifier should best left blank here. Meaning that these two would fit:

IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model' IFCGEOMETRICREPRESENTATIONCONTEXT($,'Plan'

and

IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Body','Model' IFCGEOMETRICREPRESENTATIONSUBCONTEXT('Annotation','Plan'

[Moult]

As someone who's only ever read the docs to determine how to implement this aspect and never tried to copy from sample files, I came to the exact same conclusion described by @TLiebich (therefore that's how it's implemented in Blender). So I guess I'm really surprised to see how many models have this "3D" context.

I've got 198 test IFCs floating around in a directory and these are my results ... I guess what we can conclude is that vendors generally get many interpretations of this, and some completely miss the original intention. Now is a good chance to try to strengthen the consistency by reiterating the original intention, or else challenge it and change it, but still make it clear in the docs exactly how it's used consistently.

     14 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Annotation'
    180 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model'
     41 IFCGEOMETRICREPRESENTATIONCONTEXT($,'Plan'
      9 IFCGEOMETRICREPRESENTATIONCONTEXT('2D','Plan'
      9 IFCGEOMETRICREPRESENTATIONCONTEXT('3D','Model'
      1 IFCGEOMETRICREPRESENTATIONCONTEXT('Body','Model'
      1 IFCGEOMETRICREPRESENTATIONCONTEXT('','Model'
      1 IFCGEOMETRICREPRESENTATIONCONTEXT('Model','Model'
      5 IFCGEOMETRICREPRESENTATIONCONTEXT('Plan','Model'

Out of curiosity was this "3D" usage by a popular vendor? Did they change over time? I simply mention that because I expect Revit to be a big source of IFCs, and they don't use this "3D" thing now at least (perhaps they did in the past?

[aothms]

Tbh I don't see a consistent well-established tool generating these (I guess my models on disk are bit biased for obscure academic stuff or sth):

What about on your end?

find . -name "*.ifc" -type f -exec sh -c 'grep IFCGEOMETRICREPRESENTATIONCONTEXT $0 | grep 3D && echo $0 && grep IFCAPPLICATION $0' {} \;