Difference between revisions of "IFC - Industry Foundation Classes/Representation Context"
Theoryshaw (talk | contribs) |
Theoryshaw (talk | contribs) |
||
Line 8: | Line 8: | ||
By using representation contexts, software can decide which shapes to show in different views (like 3D models, plans, or sections) and how to interpret them correctly. | By using representation contexts, software can decide which shapes to show in different views (like 3D models, plans, or sections) and how to interpret them correctly. | ||
+ | == ContextType, ContextIdentifier & TargetView == | ||
+ | <small>''the following excerpt is from [https://community.osarch.org/discussion/comment/15044/#Comment_15044 here].''</small> | ||
A context (or specifically, a subcontext, you never use contexts directly) is made of 3 major categories: | A context (or specifically, a subcontext, you never use contexts directly) is made of 3 major categories: |
Latest revision as of 15:55, 16 April 2025
A representation context in IFC is a way of organizing how geometry and drawings are grouped and understood within a building model. It defines where and how a shape or graphic is meant to be used—whether it's part of a 3D model, a 2D plan, or even a special kind of view like a section or elevation.
At a basic level, the representation context answers questions like:
- Is this geometry part of the model or just a drawing?
- Is it meant to be seen in 3D or 2D?
- What kind of geometry is it—like a full body, a centerline, or just a note?
By using representation contexts, software can decide which shapes to show in different views (like 3D models, plans, or sections) and how to interpret them correctly.
ContextType, ContextIdentifier & TargetView[edit]
the following excerpt is from here.
A context (or specifically, a subcontext, you never use contexts directly) is made of 3 major categories:
- ContextType (Model/Plan): Model indicates it stores 3D geometry using XYZ coordinates. Plan indicates it stores 2D geometry using XY coordinates only.
Note that these are not global XYZ, these are local XYZ coordinates relative to the orientation of the object (i.e. the orange dot). So if the object is rotated, 2D XY may not be pointing exactly up.
- ContextIdentifier (Body/Annotation/Axis/Box/etc): we'll focus on 2 here.
The Body says that the geometry represents the body of the object. The Annotation says that the geometry further annotates (e.g. highlights/labels/directs attention to a particular aspect of the element) the element. So if you are drawing a plan view of a door where the door panel is wide open, that is part of the Body. However, the door swing arc in theory is an Annotation, as it merely annotates the clear extents of the swing and directionality. Similarly, the triangle symbol / arrows used for awning and sliding windows are Annotations. In your example, your geometry is of the roof tiles, which is the Body.
- TargetView (MODEL_VIEW/PLAN_VIEW/SECTION_VIEW/etc):
This indicates that the geometry is suited towards this particular type of view and should take priority.
In drafting, we always draw the body of the object, and then draw the annotation in addition to the body. (e.g. first you draw the window, then you draw the arrow indicating the sliding direction of the window). There are additional rules that certain values are special in that they often use particular 2D symbology that is unique to those views that you won't typically find elsewhere (e.g. fire extinguishers have a symbol on a plan, but you'll never use that symbol in a section).
Rules for Drawing Contexts[edit]
So for a given drawing, here are the rules followed:
- First the Body ContextIdentifier is drawn. Then, the Annotation ContextIdentifier is drawn in addition.
- If there are multiple Bodies and Annotations to choose from, the one with a TargetView that matches the drawing is prioritised. The MODEL_VIEW TargetView is the fallback.
- In addition, we have a special rule that if the drawing has a PLAN_VIEW or REFLECTED_PLAN_VIEW, the Plan ContextType is prioritised over Model.
Example: PLAN_VIEW[edit]
Let’s imagine we are doing a regular floor plan drawing (i.e. PLAN_VIEW). If we had all possible Body permutations in theory, this is the priority list:
- Plan/Body/PLAN_VIEW (top priority, as you'd expect)
- Plan/Body/MODEL_VIEW (fallback)
- Model/Body/PLAN_VIEW (fallback again)
- Model/Body/MODEL_VIEW (final fallback)
Same goes for Annotations — just replace Body with Annotation.
Example: SECTION_VIEW[edit]
Here’s another example for a section (i.e. SECTION_VIEW):
- Model/Body/SECTION_VIEW (top priority)
- Model/Body/MODEL_VIEW (final fallback)
Notice we never consider 2D things in a section view. There are a number of problems with 2D in sections and elevations that has led to this special third rule.
A Few Example Contexts[edit]
ContextType | ContextIdentifier | TargetView | Example |
---|---|---|---|
Model | Body | MODEL_VIEW | Full 3D shape of an object - the 3D geometry of a door or window |
Plan | Axis | GRAPH_VIEW | An axis of a wall or beam |
Model | Axis | GRAPH_VIEW | The axis of a column or member |
Model | Box | MODEL_VIEW | The overall bounding box of the 3D geometry |
Model | Annotation | SECTION_VIEW | An up/down arrow on how window sashes work |
Model | Annotation | ELEVATION_VIEW | A door swing indicator in elevation |
Model | Annotation | MODEL_VIEW | Text or symbols in an Orthographic view |
Model | Profile | ELEVATION_VIEW | Can use a profile, instead a void, to create a void for door or window for example |
Plan | Annotation | PLAN_VIEW | Text or symbols on a floor plan |
Model | Annotation | PLAN_VIEW | ? |
Plan | Annotation | REFLECTED_PLAN_VIEW | Text or symbols on a reflected ceiling plan |
Plan | Body | PLAN_VIEW | An door swing (arc) in plan |
Model | Body | PLAN_VIEW | 3D objects you only want to see in plan view |