References, Insertion blocks, typical floors

[I-Sokolov]

99% of floors in the condo design are the same. Duplicating them

• increase file size with factor 99

• make impossible modification after Design Transfer View

STEP ed 3 is one way, but maybe we will have better solution knowing business logic... At least typical floors. Move IfcMappedItem one level up.

(Remaining 1% of floors is made from the same typical floor parts)

[Moult]

To clarify, I believe what should be proposed here to solve is to introduce a concept similar to MappedRepresentation, but instead of happening at a representation + associated type level, it should happen at an IfcGroup level.

[theoryshaw]

I think mapped ifcgroups would be a good idea as well. Surprised there's not already something like this in IFC.

[mtveerman]

1) 99% issue: isn't that an exporter problem? Building elements call already shared representations, right. So a 99% increase of a file is the result of an exporter exporting representations for each element separately.

2) modification afterwards: well.... I noticed from your other posted issues and from what I see on your Twitter account that you are working on using IFC as the main source file. I think a discussion should be held if that is the way forward or not. Personally I (currently) often compare IFC to PDF: with a PDF I know that what I see and print is always the same, but I know I need the source file (Word, Excel, Revit, whatever) to regenerate the PDF. Somehow everybody understands this in the case of standard files, but somehow people find it strange they cannot edit the IFC. In my point of view, your second issue is not an issue :) So the question is: will Next-gen IFC be more like a true editable cad format, or will it be more like a "Portable 'Domus' Format"

[Moult]

@mtveerman

1. No, it is not an exporter problem. Building elements can share representation so long as they follow the mapped representation concept, which requires the representation to be mapped to the corresponding construction type. However, if we reuse that concept here, that means that each wall needs to have a new construction type per typical floor. This is not how things are semantically described in the building industry. If you map representations without sharing a construction type, you are breaking the concept and the IFC schema needs to be revised.
2. @I-Sokolov specifically mentioned the Design Transfer MVD. Therefore, regardless of your thoughts about IFC being used as a native file format, this is still very much in scope. Even regardless of the Design Transfer MVD, we could argue that a semantic description of a typical floor is also vital for Reference View MVDs, as it can decrease coordination time.

OK, begin rant.

That said, I wish the community would stop propagating the myth that IFC = PDF file. The end goal is interoperability and collaboration. Right now, due to this myth that people treat IFC as a generated static by-product, the result is that the quality of IFCs has degraded to such a point that we cannot trust them as users. Imports and exports are highly lossy procedures, and makes OpenBIM look bad by contrast to ClosedBIM data sources. Meanwhile, the IFC spec contains things like the Design Transfer MVD, Owner Histories for the sole purposes of incrementally updating and collaborating together via BIM servers, project libraries to collaborate with IFCs, bsDD servers to ensure attributes are correct during the native authoring phase, and of course the fact that IFC is available in a variety of ASCII serialisations, none of which is important if IFC were simply "a PDF file". Apps like Augin, Tridify, BIMData, USBim, Bexel, all treat IFC as first class, because that is what we need to work together as an industry. All this is evidence that IFC is more than just a PDF file. And by goodness the AEC industry deserves better interoperability standards than a PDF file - when we were drawing by hand, that's all we got because that's all we could do. When we were using 2D CAD, we linked DWGs and DXFs, not PDFs wherever possible. Now - let's take AEC tech out of the dark ages and properly collaborate with native schemas.

IFC, and the OpenBIM umbrella of technologies (IDS, MVD, bsDD) is better compared to the early days of the web - the HTTP, HTML, CSS, JS that bring together the entire internet community. Like the rocky start that the web got with browser incompatibilities and dialects, similarly, we have AEC apps with their dialects, slowly coalescing around standards-based, native, development globally.

End rant :)

Note to self: write a longer rant to easily link to next time somebody says IFC = PDF file.

[berlotti]

@mtveerman don’t mix up the most common use case of coordination/reference view with IFC. You see one use-case but that does not mean IFC is limited to that.

It has so many more features that many have never heard of. The technical roadmap is working toward a situation where this is more visible and usable (for example by changing the whole concept of MVDs). But as @Moult said: please stop comparing it to PDF. That is a bit of an insult to IFC.

[theoryshaw]

To clarify, I believe what should be proposed here to solve is to introduce a concept similar to MappedRepresentation, but instead of happening at a representation + associated type level, it should happen at an IfcGroup level.

Would love to see this accommodated in the schema. Any ideas how we can officially implement this?

[theoryshaw]

Caught in the wild: https://community.osarch.org/discussion/807/grouping-in-blenderbim

[theoryshaw]

Seems like approaches like this would not even be necessary if mapped IfcGroups was an option.

[theoryshaw]

Took a stab... buildingSMART/IFC4.4.x-development#17