Originally coming from automotive electronics industries, I am trained in creating efficient embedded solutions (small electronic circuitry, small code, small data, …). It is painful to see resource-hungry solutions beeing a matter of course in software-industry.
The time has come to release the parking brake instead of installing more and more powerful engines.
After this general statement I step directly into technical details:
WHY do you destroy my IFC?
Testcase: IFC model with 1 project > 1 site > 1 building > 4 storeys > 16 walls > 64 windows of same type
Testcase IFC model and file have been generated by PostgreSQL functions
Round-tripping on three important authoring software tools resulted in similar disillusioning outcomes:
- The round-tripped model looks almost identical to the original model (in Xbim Xplorer)
- The round-tripped model is differently structured based on different representation paradigms, de-normalized (64 windowtypes instead of 1) resulting in bloated IFC files.
Sounds like “issues with particular proprietary products”? Yes and no.
Here I would like to discuss and sketch future goals and ways towards conservative IFC processing.
Conservative IFC processing is an enabler for BIM-Level 3-CDEs and shall be addressed to ALL software vendors.
With conservative IFC processing there is NO CHANGE in the IFC model on a round-trip “L3-CDE > IFC > authoring software > IFC > L3-CDE” if there is no explicit planning step. (e.g. IFC eport immediately after IFC import).
Before bothering you with too many details, I will step back and await your valued comments.