How to set an IFC element's product representation?

[Moult]

IFC in FreeCAD is already very good. For example, I can draw a rectangle and extrude it. Then I can click the "Wall" button to automatically assign that extrusion an "IfcWall" entity type. Then, I can create _another_ "IfcWall", and change the base to be the extrusion. Now I have _two_ IfcWalls, both theoretically sharing the same product representation. This is something that IFC allows, but no other BIM program apart from FreeCAD can do this trick.

... except it doesn't actually work. The resulting IFC file creates two product representations.

Can somebody else replicate this? Is there interest in mapping the "Base" field to "product representation"? (maybe even renaming Base in the process to be closer to IFC nomenclature?)

[bernd]

What benefit would we have

- a smaler file size
- it is very smart
- faster reading of our own ifc

what else? This one does not really convince me to spend time on this and we may have problems in other sofware with such ifc.

bernd

[Moult]

Yes, those three advantages are the most obvious ones. If we don't do this, there is no way to "instance" an element again and again. A simple detailed column could take up lots of filespace in a large commercial office tower project! Or for example a detailed facade panel could also take up lots of filespace in a large retail project.

But there is a fourth advantage. It is possible for IFC files to _reference_ one another - so IFC files can simply reference a surveyor's topography, or a structural model's detail, or so on. The ability to do this is by matching GUIDs of another IFC file, and BuildingSMART is already implementing this workflow where you can have multiple IFC files, and you don't need to specify the actual full details of various elements (both geometry and information) and simply reference each other. For example, the client's IFC contains IfcProject, the surveyor contains IfcProject->IfcSite, the architect contains IfcBuilding->IfcBuildingStorey(xN)->**, and various geometry and attributes are simply linked.

Fixing the product representation into a link rather than a hardcode would be a step towards allow us to implement these workflows.

The second step is to expose the GUID in the interface rather than hide it, and allow it to be set and locked.

[yorik]

This is a discussion I had with Ryan many times... It's even a close to official topic: https://github.com/IndustryFoundationCl ... s/issues/3

It is not simple, because quickly you find that such cases are billions. Ex: a profile is made from a rectangle, which is extruded, which becomes the representation of a column. There are 4 possible levels of "sharing" between two identical columns: the representation, the extrusion, the profile or the rectangle. What if a totally different object uses the same rectangle, etc..

These things are all possible in IFC. But it's very rare to see applications that use it, it's a shoot in the dark to know what they will do if they encounter such thing.

And there is the "usual" way, that most apps do, that is done in FreeCAD too at the moment: if you have two columns that are clones of each other in FreeCAD, only one representation is created, and both columns use it as an IfcMappedItem . But I agree we should be able to do much better than that..

Have a look at the IfcOpenHouse example that comes with IfcOpenShell, there are some bold experiments there, like reusing a single roof pane twice, manipulating copies of walls, etc. And it seems to work quite well.

I have started to implement a system, in the IFC exporter, which is a "recycler" system (ifcbin), each time a 3D point is created, or a polyline, etc... (several types are supported), at the same time it is created, it is "registered", so if another identical entity needs to be created, the registered one is used instead, which already reduces file sizes a great deal. Maybe that system can be extended much further...

Only, as far as I tested, most apps that read those files recreate many separate entities just the same. So it has impact on the IFC file size, but not really on how objects get constructed at the other end. So far only using IfcMappedItems seems to work (but still fails to recreate proper families in revit, for ex).