What ever happened to Anootation related classes

[adishavit]

Hi,

When trying to represent architectural drawings, I was going over the IFC docs.
In Ifc 2x3 there were various classes like: IfcDimensionCurve, IfcDraughtingCallout, IfcLinearDimension, IfcDimensionPair etc.

Where did all of these classes go in IFC 4x3?

Is there some discussion somewhere about the rationale for removing them and how to represent these elements alternatively?

My ultimate aim is to represent the drawings as typed elements, not just as drawing elements. So that a dimension is an actual element, not just a 2D line with some text box next to it.

Thanks,
Adi

[Moult]

These were removed in IFC4. My understanding was that it was because vendors were primarily focused on 3D geometry.

That said, in Bonsai we’ve found that this is one of the most popular parts of the IFC schema - people want semantic annotations. The good news is that IfcAnnotation is still there, and there is a renaissance coming with more surveying annotations and non 3D solid geometry.

Most of the existing functionality can be recreated with existing schema functions such as shape aspects and curve geometry. We’ve come up with a number of conventions around these to battle test it and … yes … believe it or not people are actually creating drawings, documentation, schedules, and so on in IFC natively and delivering real, commercial projects.

FreeCAD also shares our conventions around 2D drawings and annotations.

Recently I was approached by folks at Arup also looking at this. It would be good if all the people looking at this can join together into a working group and figure out a good resolution for smart, semantic annotations in IFC5!

[adishavit]

Thanks Dion.
Where can I find the schema and conventions that you are referring to?
Is this documented anywhere?

Of course, I would naturally be interested in the IFC 5 discussions.

[Moult]

It’s not documented, but you can experiment with it by installing Bonsai and creating a new drawing and adding annotations. It’s completely free, open source, and works on any platform so you can dig around to see how everything works. Also happy to give you a tour / screenshare

You’ll see we use IfcDocumentInformation for both drawings and sheets, and IfcDocumentReference to “place” things on sheets. We use IfcAnnotation with a userdefined predefined type - we treat the following as special:

"TEXT_LEADER"
"STAIR_ARROW"
"DIMENSION"
"ANGLE"
"RADIUS"
"DIAMETER"
"ELEVATION"
"SECTION"
"BREAKLINE"
"PLAN_LEVEL"
"SECTION_LEVEL"
"TEXT"
"FALL"
"SLOPE_ANGLE"
"SLOPE_FRACTION"
"SLOPE_PERCENT"

We still use IfcTextLiteral for text with support for alignment and font styles, and use IfcRelAssignsToProduct to associate annotation to an IFC product. The IfcTextLiteral is allowed to use a templating language to reference data of the associated product (so you can have smart tags).

Dimensions, angles, radius, e.g. are just simple 2D lines. We do not currently store explicit visual curve and text styles in IFC, but instead rely on the viewer to interpret it (e.g. the viewer places an arrowhead symbol and measurement in the midpoint of each curve).

Drawing orthogonal section boxes or perspective fustrums are recorded as predefined type DRAWING (still IfcAnnotation). Annotations associated with that drawing are all in the same IfcGroup with object type of DRAWING.

We also support an SVG (and optional DXF conversion) scale generation of these drawings. CSS is used to perform client-side styling. We’ve found this combo of strength of IFC semantics + CSS styling to be very powerful.

We use a custom Pset to store other metadata like drawing scale, drawing size, and target view. The target view tells the viewer what geometric context to display. It prioritises the target view, and falls back to things like model.

Here is an example of a drawing produced natively in IFC, with all the annotation completely stored in IFC. The styling is performed using CSS.

Here’s another example. Examples are by open source architecture studio OpeningDesign.

Here’s how a viewer might visualise this IFC data:

[adishavit]

Hi,

This is great. It clears up some things but brings up a lot of followup questions…
Is the bonsai export-import lossless - i.e. the imported model is indistinguishable from the exported source?

Can you upload the sample project + the exported IFC files?
In my tests I could not manage to generate all the richness you mention (I am not an architect/designer).

I have lots more questions, and wondering if we should take them offline or keep them here for future reference and for others. Maybe also as a base for a proper document?
Some of my questions:

• IIUC, IfcDocumentation seems to be meant for holding URIs of external documents. Not so much for representing “in-project” data. I want to avoid other formats (for my own usage) like SVG/CSS.
• I am unclear of what IfcDocumentReference is used for;
• What do you use to relate the various IfcAnnotations to other products?
• How do you represent a view? Is it an IfcGroup of some kind or an IfcAnnotation+ DRAWING?
• Since IfcTextLiteral is deprecated, what do you think should be used instead?
• What do you mean by “The IfcTextLiteral is allowed to use a templating language to reference data of the associated product (so you can have smart tags).”? Do you have any links?

I have several more much more technical questions but some would be answered if I saw the sample project + exported IFCs.

Thanks for the prompt replies!

[Moult]

Bonsai does not import or export IFC. It works with IFC as a native object model - so it is lossless indeed no data loss, no “mapping”, full “Design Transfer” support for almost everything in the schema - no MVD limitations.

This is perhaps easiest explained over a voice call as there are many more details - feel free to drop by Live chat – OSArch

Short answers:

• Correct, we store URIs of external SVG-based layouts. There is nothing in the IFC schema for paperspace to my knowledge.
• Document reference allows you to reference a document, similar to IfcClassification + IfcClassificationReference.
• IfcRelAssignsToProduct
• An IfcGroup. Within that group, an IfcAnnotation of ObjectType DRAWING defines the spatial boundary if relevant, along with metadata like target view.
• IfcTextLiteralWithExtent is used, and is not deprecated.
• We’ve designed a query syntax to reference and traverse most common relationships in IFC. We use Mustache templating.

You can see various open source native IFC projects that use this methodology here: OpeningDesign · GitLab

[adishavit]

Thanks. I’ll drop by the chat room you suggested.
Are the IFC files for the model/sheets in the screenshot available anywhere online?

[Theoryshaw]

this one is located here: Restaurant_MPM/Open/Models/BlenderBIM at main - OpeningDesign/Restaurant_MPM - OpeningDesign Gitea

and this one is located here: Highland_Haven/Open/Models_and_CAD/BlenderBIM at main - OpeningDesign/Highland_Haven - OpeningDesign Gitea