Suggestions on how to improve clarity of representation context usage in documentation?

Developers
1

Representation items need to belong to a context, and often, more specifically, a subcontext. This means that each representation needs to have a ContextType (99% of the time is Model/Plan), ContextIdentifier (Body, Axis, etc) and TargetView (PLAN_VIEW, etc).

However, I have noticed many applications seemingly getting this wrong or storing things in inconsistent contexts. I believe this is because the documentation is not clear enough.

Here is some description which hopefully I think can clear it up when deciding which context to use. It might seem basic to some, but here is an example of a problem which has persisted for years.

  1. The first thing to determine is a ContextType (Model/Plan). You must always choose one of these two, unless you’re doing something special. Which you choose depends on the coordinate space dimension. If you’re doing 3D shapes, you use Model. If you’re doing 2D shapes, you use Plan. So you should never put a Curve3D in a Plan, and a Curve2D in a Model.
  2. Then, you choose a ContextIdentifier. Most of these people get correct, except for Annotation vs Footprint. If you’re using an annotation (e.g. dimension line, polygonal fill, etc), use Annotation. If you’re using a symbol (i.e. the 2D shape is symbolic and does not match the projection of the object, (e.g. emergency light symbols in reflected ceiling plans), then use Annotation as well. Only if you’re projecting the actual shape, and the object is something that “fills a boundary”, use a Footprint (e.g. slab outlines, building outlines, space outlines).
  3. Finally, choose a target view. Is it a line? Use a GRAPH_VIEW. Is it a 3D shape? Use MODEL_VIEW. Finally, if it is neither a line nor a 3D shape, it is a polygon. If it is not for viewing in a particular drawing type, use a SKETCH_VIEW, otherwise, use PLAN/RCP/SECTION/ELEVATION as necessary. If you are using a drawing type, consider TargetScale.

Things which are still ambiguous:

  1. I propose that Footprint geometry must only be valid in a Plan context.

4.8.2.5.1 FootPrint GeomSet Geometry

The ‘FootPrint GeomSet Geometry’ is the standard representation for the floor plan projection of the geometric representation of elements, comprising of mainly 2D curves

We may assume that Footprint is only valid in the Plan ContextType for 99% of cases (unless you’re doing something special).

  1. I propose that clarity is provided by the docs on annotation vs footprint.

Furniture should be annotation from my interpretation, as it is symbolic (i.e. a simplified representation of the full 3D object), and furniture (e.g. a chair) is not an element that “fills a boundary”.

Notice that this confusion arises when the docs never talk about how furniture symbols are used.

  1. Clarity should be provided on the ContextType for axis.

Reading of the docs suggest that wall Axis is Curve2D (assuming material layer set usage), so it should be in something like Plan/Axis/GRAPH_VIEW. However, a beam axis is Curve3D (assuming material profile alignment), so it should be in Model/Axis/GRAPH_VIEW. However, I have very rarely seen people actually implement this in two separate contexts.

  1. Clarity should be provided on when it is valid to forego a subcontext and assign directly to a context.

I have seen some IFCs do this - where no subcontexts exist at all, and everything is just assigned to a single Model context. What is the purpose of a context with no subcontext? Are we allowed to assign to it?

  1. Clarity should be provided on other lesser seen permutations of ContextType and ContextIdentifier and TargetView.

Is there such a thing as a Plan/Body/*? Is this more valid than Plan/Annotation/* for things like furniture symbols?

Is there such as thing as Plan/Profile/*? The docs only mention Curve3D.

Is there such a thing as Plan/Lighting/*?

What about target views. What target views are valid for Plan/Axis/*? Only GRAPH_VIEW? I assume so. What about SKETCH_VIEW? Can someone give an example of SKETCH_VIEW? I have no idea.

  1. Why is ContextType and ContextIdentifier optional? Under what circumstances is this acceptable?

I mention this because this is the Revit bug which was impacting users for a long time so we have a lot of files with this problem. What does it mean when these labels are missing?

To demonstrate that this is a problem, here is a case study for some of these issues of a simple door, wall, and slab exported from the certified Revit 2021 IFC export. Ping @angel.velez (the reason I pick Revit here is because it is the most prevalent in the industry - let’s get real) But also ping @jonm @claimred @stephen-l and other implementers who have to deal with this inconsistency.

Project1.ifc (87.6 KB)

Problems:

  1. Model/Footprint/MODEL_VIEW combo exists. It should not.
  2. Wall axis is Curve3D. It should be Curve2D according to the docs.
  3. Slab footprint is Curve2D, but belongs to Model. It should be Plan for the coordinate dimensionality to be correct, but there is no Plan context.
  4. Door has no annotations representations out of the box. What did I miss?

Can get get some clarity and consistency across implementations for this? Is my interpretation correct?

2 Likes
2

A heads up that consistencies may also be found in many buildingSMART example files in the documentation. Suggest that once this is clarified, methodically all of the example files should be reviewed.

3

Hi @Moult , thanks for your analysis. It is precisely these little inconsistencies that make for a thousand flavors of IFC that everyone interprets slightly differently. I’ll file an internal item to look at these.
To point 4: We purposefully don’t export annotations unless you choose to export them (as an option in the exporter). This is consistent with the fact that most applications didn’t use them. i don’t fully know if that’s the case now, and the default could be flipped. But given that we get a lot of complaints about axes showing up (some due to old bugs where they were in the wrong place, but some just cause), I don’t know if that’s the default sentiment.

4

Thanks @angel.velez - hopefully implementers can get together and sort these things out.

Thanks for the tip for exporting annotations. I have enabled the option and this is the updated file:
Project1-annotation.ifc (132.8 KB)

In this updated file, the annotation is part of a subcontext… but with an invalid ContextType and NULL ContextIdentifier… so I guess the issue is still unsolved. In addition, I’ve added a curtain wall, and you can see a curtain wall panel has a footprint. Should it be an annotation? Also, it is in a MODEL_VIEW, whereas Footprint is clearly 2D. It uses a Curve2D, but is in the Model ContextType. Hope this analysis helps.

But speaking agnostic of Revit, I think we can all agree that everybody is struggling with this, so hopefully clarification and explicit examples in the docs can sort it out.

I’m not sure what buildingSMART certification covers, but I’m testing with the certified version I think (latest Revit IFC 2021), so perhaps the certification programme needs to be revised too.

5

On the topic of the docs, for this statement:

SKETCH_VIEW Geometric display representation that shows an abstract, often 2D element representation, e.g. representing a wall by its two foot print edges, surpressing any inner layer representation.

Any thoughts what “two foot print edges” means? A wall’s 2D representation is a rectangle, which to me has 4 edges.

6

@angel.velez btw I noticed an IFC file with this coming from Revit:

#4140= IFCSHAPEREPRESENTATION(#101,'Facetation','SurfaceModel',(#4129,#5136,#5413,#6947,#7893,#8851,#9896,#12049,#12676,#13845));

I don’t know which version of the exporter they used so maybe it’s already been fixed, but if not, can you check why Facetation is being used? I don’t think it is valid, can you change it to Body instead?

7

Can you check the header of the IFC file? It will say the IFC version.

8

It’s a pretty old file so perhaps already fixed, but just in case, here it is:

ISO-10303-21;
HEADER;

/******************************************************************************************
* STEP Physical File produced by: The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013
* Module:                         EDMstepFileFactory/EDMstandAlone
* Creation date:                  Wed May 22 09:34:30 2019
* Host:                           CONVIMOR1
* Database:                       C:\Users\Convimor\AppData\Local\Temp\{A9C93411-5031-455D-98CD-9A8A2A527055}\ifc
* Database version:               5507
* Database creation date:         Wed May 22 09:34:26 2019
* Schema:                         IFC2X3
* Model:                          DataRepository.ifc
* Model creation date:            Wed May 22 09:34:28 2019
* Header model:                   DataRepository.ifc_HeaderModel
* Header model creation date:     Wed May 22 09:34:28 2019
* EDMuser:                        sdai-user
* EDMgroup:                       sdai-group
* License ID and type:            5605 : Permanent license. Expiry date: 
* EDMstepFileFactory options:     020000
******************************************************************************************/
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('Numero','2019-05-22T09:34:30',(''),(''),'The EXPRESS Data Manager Version 5.02.0100.07 : 28 Aug 2013','20180806_1515(x64) - Exporter 19.1.0.112 - Alternate UI 19.1.0.112','');
FILE_SCHEMA(('IFC2X3'));
ENDSEC;

DATA;
#1= IFCORGANIZATION($,'Autodesk Revit 2019 (ENU)',$,$,$);
#5= IFCAPPLICATION(#1,'2019','Autodesk Revit 2019 (ENU)','Revit');